About SharePoint and Alcohol (or what is claims based authentication)

13 בינואר 2010

תגיות: , ,
2 תגובות

אחד מהשינויים הפחות פופולאריים, אך היותר משמעותיים, ב SharePoint2010 הוא כל הנושא של Claims Based Authentication. עדיין אין יותר מידי תיעוד על הנושא, אך יש ברשת המון דוגמאות והסברים קונספטואלים ל-מה זה בעצם, ואיך זה עובד.

הדוגמא הרווחת היא הדוגמא של מכירת אלכוהול ובאמת היא חוזרת על עצמה המון בכל מיני וריאציות, אז חשבתי להציג את הדוגמא גם בעברית, כי באמת זאת דרך טובה להבין את הטרמינולוגיה של Claims Based Auth.

נניח ואנחנו נמצאים במקום שבו אין מכירת אלכוהול לאנשים מתחת לגיל 18. אדם ניגש לחנות משקאות ומבקש לקנות משקה. המוכר צריך איזושהי דרך לברר ולוודא את גילו של הקונה. כמובן שהוא יכול לשאול את הקונה מה גילו, אך שיטה זו לא אמינה במיוחד, ואנחנו צריכים איזשהו גוף מוסמך שיאשר את גילו את הקונה.

ובכן, יש לנו את הגופים הממשלתיים שמנפיקים לנו תעודות שמאשרות את גילנו. לדוגמא, משרד התחבורה מנפיק לנו רישיון נהיגה, ובו מצוין הגיל.

כעת, הקונה יכול להציג למוכר את רישיון הנהיגה, והמוכר יכול להאמין לקונה שהוא מעל גיל 18 (בתנאי שהמוכר בוטח באמינות משרד התחבורה), ולמכור לו את המשקה.

אם נתבונן לרגע בעולם המונחים של Claims Auth, נוכל למצוא את ההקבלה לדוגמא שנתתי:

Claim – הטענה אודות המשתמש. במקרה שלנו, הטענה כי הקונה מעל גיל 18.

Token – האמצעי שמוכיח את נכונות הטענה. במקרה שלנו, רישיון הנהיגה.

STS (Security Token Service) – השירות שמנפיק Tokens, במקרה שלנו משרד התחבורה (שמנפיק רישיונות נהיגה).

Relaying Party – הגוף שמקבל את ה Ticket. במקרה שלנו, המוכר בחנות המשקאות.

Trust – קשר אמון בין שתי גורמים. במקרה שלנו, המוכר בחנות סומך על משרד התחבורה שיספק נתונים אמינים.

נעזר בדיאגרמה הבאה המתארת את התהליך (לחץ להגדלה):

clip_image001

גם כאן נתרגם את השלבים בתהליך (לפי המספור שלהם בתרשים)

  1. אדם נכנס לחנות ומבקש לקנות משקה אלכוהולי.
  2. מוכר: סליחה אבל אנחנו מוכרים אלכוהול רק לבני 18 ומעלה, יש לך הוכחה שאתה בן 18 ומעלה?
  3. המשתמש פונה למשרד התחבורה, ומוציא רישיון נהיגה (בפועל שלב זה התבצע מבעוד מועד)
  4. משרד התחבורה מאשר גילו של הפונה מול מאגר הנתונים של משרד הפנים, ומחזיר לפונה רישיון נהיגה.
  5. הקונה מציג את רישיון הנהיגה בפני המוכר.
  6. המוכר מוכר לקונה משקה.

היתרון המרכזי בשיטת עבודה כזו, היא שאנו לא מוגבלים לעבוד מול ספק אימות אחד (AD). כלומר אם נחליט שלא לבטוח יותר במשרד התחבורה, נוכל לעבור לעבוד מול גורם אחר. בנוסף, יכולים לשלב מערכות שונות המשתמשות בשיטות אימות שונות.

שימו לב שבשיטה זו, אנו מקבלים יתרון נוסף והוא של שמירה על פרטיות המשתמש. נניח ובנוסף לחוק האוסר מכירת אלכוהול מתחת לגיל 18, היה חוק נוסף שאוסר על חשיפה ושמירה של פרטים אישיים אודות אנשים. במקרה כזה אסור למוכר לשאול את המשתמש את גילו. במצב זה ה STS יכול לספק פשוט אישור שאומר "המשתמש מעל גיל 18" מבלי לחשוף את גילו האמיתי, ומבלי לשאול את המשתמש מה גילו.

נרחיב לרגע את הנקדה הזו עם דוגמא נוספת. אנחנו רוצים להרשם לאתר אינטרנט אקסלוסיבי שתנאי קבלה אליו הוא הכנסה חודשית של 20000 ש”ח ומעלה. טופס הרשמה לאתר היה עלול לשאול אותנו על מצבנו הכלכלי, נתון שאנחנו כנראה לא נרצה לשתף. אך במקום לשאול את המשתמש על הכנסתו – ניתן לבקש אישור משירות האימות של הבנק המציין האם המשתמש מאושר לשירות.

שיקולים מסוג זה של הגנה ושמירה על פרטיות תופסים מקום גדול יותר בתודעה הציבורית עם התפתחות האינטרנט.

מאמר זה עוזר להבין ולהמחיש את עולם המושגים של Claims Based Auth ואת דרך הפעולה שלו.

אין ספק שזה תחום מאוד מעניין וכיוון מעניין עבור SharePoint, ואני מחכה לראות איך הוא יתפתח בעתיד ובגרסת ה RTM.

–שמי איתי שקורי ואני יועץ SharePoint–

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

2 תגובות

  1. Lior Zamir14 בינואר 2010 ב 1:37

    אהבתי את הדוגמאות הפשוטות להמחשה של הנושא המורכב…כל הכבוד!

    הגב
  2. Som19 בינואר 2013 ב 5:20

    It's always a relief when someone with oobvuis expertise answers. Thanks!

    הגב