ניהול זהויות והרשאות בסביבת.Web Services

Transcription

1 האוניברסיטה הפתוחה המחלקה למדעי המחשב עבודה מסכמת לתואר שני ניהול זהויות והרשאות בסביבת.Web Services ) מנחה: מגיש: פרופ' אהוד גודס אלירז אביב )ת.ז.

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

3 תוכן עניינים תקציר...4 מבוא...5 סקירת ספרות... 7 מהי טכנולוגית? Web Services 7... מהו שירות Service? 7... ארכיטקטורה מבוססת שירותים - Architecture 8...Service Oriented מבוא ל SOA 8... הצורך המניע את התפתחותה של פרדיגמת השירותים...9 הארכיטקטורה של מנגנון מבוסס 9...SOA מבוא ל Security... WS - 14 הגדרת המושגים "זהות" "והרשאה" זהות דיגיטאלית Identity...Digital 16 הזדהות הגדרת המושג... Authentication 16 מנגנונים קיימים לניהול זהויות והזדהות הזדהות באמצעות... Kerberos Ticket 17 הזדהות באמצעות 509.X Certificate )מנגנון מבוסס...)PKI 18 הזדהות באמצעות...NET Passport 20 ניהול הרשאות גישה...Authorization 22 הגדרת המושגים Identity.Federation and Federated ניהול זהויות בסביבת Web באמצעות... SAML 23 ניהול הרשאות באמצעות מאפיינים Security... Attribute-Based 24 ארכיטקטורת מנגנון לניהול זהויות המבוסס...SAML 24 מהו הערך המוסף של SAML לעומת מנגנוני הזדהות קיימים הגדרת מדיניות אבטחה וניהול בקרת הגישה באמצעות...XACML 28 מבוא ל XACML ארכיטקטורת מנגנון בקרת גישה מבוסס... XACML 29 טכנולוגיות קיימות המשתמשות ב...SAML 36 פרויקט )Project Liberty( Liberty Alliance טכנולוגית... CardSpace מערכת... Shibboleth 38 סיכום סקר הספרות שיטות העבודה מימוש מנגנון מבוסס SAML ו...XACML 39 מטרת הפרויקט תיאור השחקנים השונים במערכת...)Actors( 41 תיאור ה Cases Use השונים במערכת ארכיטקטורה

4 סיכום רשימת מקורות נספח מושגים וקיצורים רשימת טבלאות ואיורים איור 1 איור 2 : שלושת המנגנונים המרכזיים בפרדיגמת השירותים... 8 : ארכיטקטורת טכנולוגית... Web Service 10 איור : 3 מבנה הודעת...SOAP 11 איור 4 : העברת הודעות בין משתתפים שונים בתהליך עסקי איור :5 מבנה מסמך... WSDL 13 : הסטנדרטים המטפלים באבטחת מידע בסביבת... Web Services 14 : תהליך הזדהות מבוסס...Kerberos 18 : קבוצת משתמשים המממשים... PKI 19 : תהליך הזדהות מבוסס...Public Key 20 : ארכיטקטורת מנגנון המבוסס...Net Passport 21 איור 6 איור 7 איור 8 איור 9 איור 10 איור : 11 השחקנים המשתתפים במערכת מבוססת...SAML 24 איור : 12 המבנה של הכרזת... SAML Attribute Assertion 25 : מבנה ההודעה לבקשת הכרזה מה - Provider... Assertion 26 : מודל זרימת הנתונים )DFD( במנגנון... XACML 30 : מודל UML של האוביקטים המרכיבים מנגנון... XACML 31 איור 13 איור 14 איור 15 איור : 16 הגדרת Policy בשפת...XACML 33 איור 17 : בקשה לבדיקת הרשאת גישה במנגנון...XACML 34 איור : 18 התגובה המתקבלת מה -...PDP 34 : תהליך ההזדהות באמצעות... CardSpace 37 : ה Cases Use השונים המרכיבים את המערכת איור 19 איור 20 איור 21 איור 22 איור 23 איור 24 : חבילות התוכנה המרכיבות את החלק המעשי בפרויקט : ממשק המשתמש להגדרת משתמש חדש בצד ה - Provider... Assertion 49 : ממשק המשתמש להגדרת הכרזת מאפיינים )שלב ראשון( : ממשק המשתמש להגדרת הכרזת מאפיינים )שלב שני( : ממשק המשתמש להגדרת ה - Provider Assertion בצד ה -...client 51 : ממשק המשתמש להגדרת... XACML Policies 52 איור 25 איור 26 איור 27 : המחלקות הממשות את התשתית לשלושת הכלים המרכזיים

5 1 תקציר בעולם בו קישוריות הינה דרישה מרכזית וחשובה ביותר מכל מערכת מידע, מערכות אלו הפכו גדולות ומורכבות, המבוזרות על פני מספר מחשבים הנמצאים בארגונים שונים, לעיתים אף בחלקים שונים בעולם. המורכבות הרבה של המערכות הללו, ביחד עם התפתחותה של רשת האינטרנט כתשתית המספקת קישוריות, הביאו להולדתה של פרדיגמת התכנות מבוססת השירותים Architecture(,)Service Oriented ולטכנולוגית Web Services כמימוש של פרדיגמת תכנות זו. טכנולוגית Web services מציבה אתגרים רבים בתחומים שונים ומגוונים. בעבודתי זו אתמקד בנושא אבטחת המידע, ובפרט בנושא ניהול הזהויות והרשאות הגישה בסביבה של ארגונים המקיימים ביניהם מערכת יחסים באמצעות סט של שירותים אשר ארגון אחד מספק לארגון אחר )ולהיפך(. שירותים אלו ממומשים באמצעות טכנולוגית.Web Services כדוגמה לקבוצה כזו של ארגונים המקימים סוג מסוים של מערכת יחסים ניתן להסתכל על בתי החולים בארץ, האוניברסיטאות, קבוצה של גופים פיננסיים כגון בנקים ובתי השקעות, וכדומה. בעבודתי זו אתאר סוג של מערכת יחסים פיקטיבית בין הבנקים השונים בארץ אשר אם תמומש תאפשר שיפור השירות ללקוח. על מנת לממש את הקישוריות הנ"ל אציג גישה לניהול הזהויות ( )Authentication וההרשאות )Authorization( בסביבת מערכות מבוזרות המשתמשות ב Services Web כתשתית למימוש הקישוריות בין מספר ארגונים המעוניינים לקיים ביניהם קשר עסקי כלשהו. תחום זה, המכונה,)Federated Identity Management( FIM מציג גישה לניהול הזהויות וההרשאות המבוססת על המאפיינים של המשתמשים השונים ברשת. גישה זו מכונה,Attribute based security וניתן לראות בה כמעיין הרחבה של.)Role-Based Access Control( RBAC 4

6 2 מבוא במערכות מבוזרות, המקשרות מספר רב של ארגונים דרך רשת האינטרנט, מנגנוני ההזדהות הקיימים כיום )אותם אתאר בהמשך( אינם מספקים מענה מתאים היות והם מבוססים על ישות מרכזית אחת המכירה את כל המשתמשים במערכת. התלות בישות מרכזית כזו אינה אפשרית במערכות אלו שכן המשתמשים שייכים למספר ארגונים שונים וכל ארגון מכיר את המשתמשים השייכים לו )לדוגמה לקוחות של בנק מסוים, סטודנטים של אוניברסיטה מסוימת וכדומה(. מטרת המערכת לספק קישוריות בין הארגונים השונים הללו כך שמשתמש השייך לארגון אחד יוכל לקבל שירותים מארגון אחר. בעבודתי זו אתאר את האופן באמצעותו מבצעים קישור מאובטח בין לקוחות ושירותים בקבוצה של ארגונים,Federation( ]6[(. פרק 3.1 פותח את החלק התיאורטי של פרויקט הגמר בתיאור של טכנולוגית Web Services ופרדיגמת השירותים Architecture(.)Service Oriented בנוסף, הפרק מתאר את הסטנדרט.Web Services המטפל בנושא האבטחה בסביבת WS-Security פרק 3.2 מגדיר את המושגים זהות והרשאה במטרה לבדוק מהם המנגנונים הקיימים כיום לניהול זהויות והרשאות גישה Authorization(,)Authentication and ומדוע מנגנונים אילו אינם מספקים מענה הולם לניהול זהויות והרשאות בסביבת.Federations פרק 3.3 מתאר את הסטנדרט )Security Assertion Markup Language( ]1[,SAML ואת האופן שבאמצעותו מנהלים זהויות בסביבת.Federations סטנדרט זה פותח ע"י גוף המכונה.)Organization for the Advancement of Structured Information Standards( OASIS פרק 3.4 מתאר את )extensible Access Control Markup Language( ]2[,XACML כמנגנון לניהול הרשאות גישה )Authorization( אשר פותח גם הוא ע"י.OASIS בפרק 3.5 אתאר טכנולוגיות קיימות המשתמשות ב SAML לניהול זהויות, כגון: Card Space של ]22[ Microsoft המממשת את SAML באופן חלקי, ו Liberty ]21[ Project המגדיר מיהם המוצרים המממשים את SAML בצורה מלאה. חשוב לציין כי בעולם של אינטרנט התאימות המלאה לסטנדרטים אוניברסאליים כדוגמת SAML חשובה ביותר להתפתחותו של עולם זה כמרכז שבו מתקשרות ביניהן טכנולוגיות רבות ומגוונות במטרה לממש קישוריות של מערכות מידע. פרק 4 מתאר את החלק המעשי של פרויקט הגמר. בפרק 4.1 אתאר את מטרת הפרויקט. סעיף זה יהווה קישור בין החלק התאורתי )סקירת הספרות בפרק 3( וחלק במעשי )המתואר בפרק 4(. החלק המעשי הינו מימוש מלא שלי )בטכנולוגית.Net של מיקרוסופט בשפת #C( של מערכת לניהול הרשאות גישה בסביבת Web Services המבוססת על הסטנדרטים SAML ו.XACML בפרק זה אשתמש במודל,UML ובפרט בדיאגרמת Use Cases אשר מתארת את אוסף היחידות הפונקציונאליות והתהליכים הלוגיים המרכיבים את הפתרון והשחקנים השונים המשתמשים במערכת. 5

7 מימוש המערכת אותה פיתחתי בפרויקט זה מחייב לימוד והבנה מעמיקה של הסטנדרטים SAML ו XACML באמצעות המסמכים המשוחררים ע"י )]1[, OASIS ]2[(. מסמכים אלו מתארים באופן מלא ומפורט את התקנים הללו. כמו כן על מנת לשלב את הרעיונות העומדים מאחורי סטנדרטים אלו בטכנולוגית Web Services יש להכיר ולהבין את הבסיס לטכנולוגיה זו ואת הרעיונות העומדים מאחורי פרדיגמת התכנות המכונה Service Oriented Architecture.)SOA( כלומר הבנתם של התקנים SOAP ו WSDL ]19[, ואת האתגרים, מנקודת מבט של אבטחת מידע, אשר מציבה פרדיגמת תכנות זו. כל זאת במטרה ליצור מוצר המשלב ומשתמש ברעיונות העומדים מאחורי התקנים SAML ו XACML ומספק מענה הולם לנושא ניהול הזהויות והרשאות הגישה בסביבת.Web Services המוצר אותו פיתחתי הינו פיתוח מלא שלי )בטכנולוגית.Net של,Microsoft בשפת #C( של אוסף כלים המהווים מימוש של הסטנדרטים הנ"ל, ומשמשים לניהול הזהויות והרשאות הגישה לשירותים בקבוצה של ארגונים. אוסף הכלים אותם פיתחתי, מאפשר יצירת מערכת של "אמון הדדי" )Trust( בין הארגונים השונים בקבוצה. 6

8 סקירת ספרות מהי טכנולוגית? Web Services טכנולוגית Web Services הינה מימוש של פרדיגמת תכנות רחבה יותר המכונה Service Oriented Architecture )פרדיגמת תכנות מבוססת שירותים, ובקיצור.)SOA על מנת להבין מה עומד מאחורי טכנולוגית Web Services נתחיל בהגדרת המושג.Service משם נמשיך ונסקור את הארכיטקטורה של מנגנון המממש SOA )ובפרט,)Web Services ונסיים בהצגת נושא האבטחה בסביבת Web Services )הצגת הסטנדרט.)WS Security מהו שירות Service? שירות )Service( הינו יחידה לוגית סגורה המספקת פונקציונאליות המוגדרת היטב. המשתמש המפעיל יחידה זו פונה אליה דרך ממשק מוסכם ואין זה מעניינו כיצד מומש השירות אליו פנה. ואולם, אם נתבונן על עולם הנדסת התוכנה ניתן ליראות כי גם את המושגים "פונקציה" ו - "מחלקה" ניתן להגדיר באמצעות הגדרה דומה. הרציונל העומד מאחורי הרעיון של פיתוח מערכות באמצעות שירותים אינו שונה מהרעיונות שיצרו את התכנות הפרוצדוראל י ו/או התכנות מונחה העצמים. שלושת פרדיגמות התכנות הנ"ל נוצרו עקב הרצון ליצור מארזי תוכנה )"קופסאות שחורות"( באמצעותם נרכיב מערכות גדולות יותר. הצורך ביצירת צמידות חלשה Coupling( )Loose בין הרכיבים השונים המרכיבים מערכות גדולות הוא שהניע את פיתוחן של פרדיגמות התכנות הנ"ל. השימוש בשירותים מהווה התקדמות משמעותית בדרך בה מפתחים כיום מערכות מבוזרות. האפשרות לשלב מספר טכנולוגיות שונות בתהליך עסקי אחד הינו אחד היתרונות הבולטים של פרדיגמת השירותים על פני התכנות הפרוצדוראלי והתכנות מונחה העצמים. שירות ממוקם על גבי הרשת בכתובת מסוימת. לדוגמה, כאשר משתמשים ברשת האינטרנט, ומקבלים פניות אל השירות באמצעות בקשות HTTP )בטכנולוגית )Web Services אזי ניתן לפנות אל השירות באמצעות כתובת ה URL בה הוא ממוקם. בשונה מ "פונקציה" או "מחלקה" אשר נטענים אל מרחב הזיכרון של התוכנית אשר משתמשת בהן, לשירות ישנו תהליך המארח אותו ( Host )Process ועל מנת לפנות אליו יש לשלוח לו מסר )Message( באמצעות פרוטוקול תקשורת כלשהו, ובפורמט אשר השירות יודע לקבל ולעבד. הפורמט המשמש כיום למימוש הקישור בין לקוחות ושירותים בסביבת Web Services הינו.XML מעל XML הוגדרו תבניות המגדירות את המבנה של הודעה בעת הפנייה לשירות. פרוטוקול )Simple Object Access Protocol( SOAP מגדיר את התבנית של הודעת XML שמטרתה קריאה למתודה על גבי שירות מרוחק. כלומר כיצד לייצג קריאה למתודה באמצעות,XML במטרה לשלוח את ההודעה אל השירות ולבצע קריאה מרוחקת RPC(.)Remote Procedure Call 7

9 עד כה דיברנו על שירותים באופן כללי, והגדרנו מהו שירות. ואולם הטכנולוגיה המובילה כיום למימוש מערכות המבוססות על שירותים הינה.Web Services טכנולוגיה זו מבוססת על פרוטוקול HTTP ע. "פ ]20[ מנגנון של שירותים המבוסס על Web Services מורכב משלושת המרכיבים המרכזיים הבאים:.1 פרוטוקול המקשר בין לקוחות ושרתים : SOAP.Simple Object Access Protocol.2 סטנדרטים לתיאור שירותים : WSDL.Web Services Description Language.3 פרסום וחיפוש של שירותים : UDDI Universal Description, Discovery and.integration חשוב לציין כי פרדיגמת השירותים אינה מחייבת שימוש ב HTTP או בפרוטוקול אחר כלשהו. ואולם השימוש הנרחב ברשת האינטרנט הביא לכך שטכנולוגית Web Services מהווה כיום בסיס מרכזי וחזק למימוש ארכיטקטורה של שירותים. ארכיטקטורה מבוססת שירותים - Architecture Service Oriented מבוא ל SOA פרדיגמת השירותים,)SOA( כפי שתוארה בסעיף הקודם, הינה פרדיגמת תכנות אשר מטרתה לאפשר את פיתוחן של מערכות מידע מבוזרות בעולם הטרוגני בו קיימות טכנולוגיות רבות ומגוונות )ישנות וחדשות( המעוניינות לתקשר ביניהן. פרדיגמת תכנות זו לוקחת את המושג "צמידות חלשה" Coupling( )Loose צעד נוסף קדימה בהמשך למה שעשו התכנות הפרוצדוראלי והתכנות מונחה העצמים וזאת באמצעות הגדרת מושג חדש המכונה Interoperability אשר משמעותו אי תלות בטכנולוגיה, והיכולת לבצע אינטגרציה בין טכנולוגיות שונות ומגוונות. Bind Requestor צרכן שירותים Find Service Publish Discovery Facility איתור שירותים שירות : שלושת המנגנונים המרכזיים בפרדיגמת השירותים איור 1 פרדיגמת השירותים מציגה שלוש דרישות מרכזיות ליצירת "עולם" של שירותים : יכולת לתאר שירותים במטרה לבצע קישור ( Bind ) בין צרכן השירות לספק השירות. 1. מנגנון לפרסום שירותים ( Publish ) על מנת לייצר מנגנון הדומה ל "דפי זהב". 2. מנגנון חיפוש ( Find ) המאפשר לצרכני שירותים למצוא ולהגיע אל ספקי השירותים. 3. 8

10 הקשר בין שלושת הדרישות הנ"ל מתואר באיור. 1 ספק השירות מפרסם עצמו במאגר השירותים באמצעות פעולת.Publish לעומתו צרכן השירות מחפש אחר שירות מסוים במאגר השירותים באמצעות ביצוע פעולת.Find לאחר מציאת השירות במאגר השירותים יקבל הצרכן מהמאגר את ה WSDL של השירות )הקובץ המתאר את השירות ואת אופן ההתקשרות עימו( ובאמצעותו יבצע Bind ה. WSDL יגדיר לצרכן: 1. מהו מבנה הודעת ה SOAP אשר השירות מצפה לקבל 2. באיזו כתובת ניתן לקבל את השירות.3 ומהו פרוטוקול ההתקשרות,HTTP(... SMTP ) הצורך המניע את התפתחותה של פרדיגמת השירותים מהפיכת האינטרנט חשפה את משתמשי המחשב למקורות מידע רבים ומגוונים בצורה פשוטה ובלתי תלויה בסוג החומרה או התוכנה המותקנים בצד הלקוח או בצד השרת, וזאת בזכות פרוטוקול )Hypertext Transfer Protocol( HTTP פרוטוקול סטנדרטי שאינו תלוי בפלטפורמה מסוימת. בשלבים הראשונים היה האינטרנט אוסף של דפי HTML סטאטיים, אליהם ניתן היה לפנות באמצעות הפרוטוקול הנ"ל. בשלב מאוחר יותר הופרד התוכן של דפים אלו ואוחסן בבסיסי נתונים. דפי ה HTML הפכו לדינאמיים, ובנייתם התאפשרה בזמן אמת בזכות טכנולוגיות שרת כגון )Active Server Pages( Asp של מיקרוסופט, והמקבילה שלה : Jsp Pages( )Java Server המבוססת,Java אשר אפשרו שליפת המידע מתוך בסיסי נתונים ושילובו בתוך דפי ה HTML בזמן בקשת הדף. ואולם הטכנולוגיות הללו עדיין לא סיפקו מענה עבור הצורך באינטראקציה בין אפליקציות )קשר מסוג.)Application To Application ]20[ מתאר דוגמה של סוכנות נסיעות אלקטרונית בה ניתן להזמין חופשות. התהליך העסקי להזמנת חופשה יפנה אל שלושה שירותים שונים )חברת תעופה, מאגר בתי מלון, והזמנת רכב שכור( במטרה לייצר את חבילת הנופש האופטימאלית. טכנולוגית Web Services משתמשת בפרוטוקול HTTP על מנת להעביר בקשות SOAP בין שירותים. השילוב בין HTTP כתשתית ופרוטוקול SOAP אפשרו את יצירת הקשרים מסוג Application To Application ללא תלות בחומרה או התוכנה המצויים בכל אחד מן הצדדים המשתתפים בתהליך הארכיטקטורה של מנגנון מבוסס SOA עד כה תיארנו את הרעיון הכללי העומד מאחורי פרדיגמת התכנות מבוססת השירותים. בסעיף זה נציג בהרחבה את התשתית למימוש פרדיגמה של שירותים ללא תלות בטכנולוגיה או פרוטוקול מסוים. בהמשך נמצא את מקומם המדויק של מנגנוני האבטחה בעולם בו הישות המרכזית הינה ההודעה )ה )Message העוברת בין שחקנים רבים המשתתפים בתהליך עסקי מסוים. 9

11 Discovery (UDDI, Metadata Exchange ) הארכיטקטורה הכללית של מנגנון המממש את הרעיון העומד מאחורי פרדיגמת השירותים מורכבת מחמש שכבות של תוכנה וסט של סטנדרטים, כמתואר באיור 2. חמש השכבות הללו ממשות את הרעיון שהוצג בסעיף Publish/Find/Bind Composite Atomic Components Reliable Messaging Security Transactions Quality of Service WSDL WS-Policy Description XML (SOAP, WS-Addressing) Non XML Messaging HTTP, SMTP, TCP/IP, RMI Transport : ארכיטקטורת טכנולוגית Web Service איור 2 Transport Services שכבת התובלה השכבה הבסיסית ביותר בעולם של שירותים הינה שכבת התובלה שתפקידה להעביר את ההודעות בין השחקנים השונים המשתתפים בתהליך עסקי מסוים. כפי שראינו בסעיפים הקודמים השחקנים השונים יודעים לטפל בהודעות בפורמט XML מסוג.SOAP על כן צורת העברת המידע בין הצדדים השונים לא רלוונטית לנושא עבודה זו, שכן כל התייחסות לנושא האבטחה ברמה זו קושר אותנו לפרוטוקול העברה מסוים. Messaging Services פורמט לתיאור הודעות בסביבת שירותים שכבה זו של הגדרות וסטנדרטים מגדירה את מבנה ההודעות )ה - )messages המועברות בין הגורמים השונים המשתתפים בתהליכים העסקיים והיא זו אשר מאפשרת את מימוש הקישור בין טכנולוגיות שונות ללא תלות בחומרה או תוכנה.)Interoperability( עולם האינטרנט הינו סביבה הטרוגנית בו חיות טכנולוגיות שונות ומגוונות המעוניינות לתקשר ביניהן במטרה לממש תהליכים עסקיים מורכבים ומגוונים. על מנת לממש פרדיגמה של שירותים נולד הצורך בפרוטוקול מקשר שאינו תלוי בטכנולוגיה מסוימת,)Platform-Independent( דבר אשר הצביע בצורה חד משמעית על XML כברירה הטבעית למימוש פרוטוקול כזה. 10

12 ,)Simple Object Access Protocol( SOAP הינו פרוטוקול המבוסס על XML להעברת מסרים בין שירותים,)Messaging( ולביצוע - SOAP.)Remote Procedure Call( RPC לא פותח כפרוטוקול עצמאי ולא בא במטרה להחליף פרוטוקולים קיימים )כגון,SMTP,HTTP וכדומה( אלא הוא משתמש בפרוטוקולים אלו להעברת ההודעות, והערך המוסף של SOAP הוא הגדרת פורמט סטנדרטי להודעות אלו. הודעת SOAP מורכבת משני חלקים : כותרת ההודעה,)Header( וגוף ההודעה )Body( כמתואר באיור 3. <SOAP: Envelop xmlns: SOAP = " <SOAP: Header> <wsse: Security> <ds: Signature> <ds:signaturevalue>bl8jdf </ds:signaturevalue> </ds: Signature> <wsse: Security> </SOAP: Header> <SOAP: Body> <GetFlightInfo> <AirlineName type = "string">el-al</airlinename> <FlightNumber type = "int">506</ FlightNumber > </GetFlightInfo> </SOAP: Body> </SOAP: Envelope> איור : 3 מבנה הודעת SOAP על מנת להשתמש ב SOAP לביצוע קריאה למתודה מרוחקת,)RPC( הוגדרו סטנדרטים המגדירים כיצד לייצג טיפוסי נתונים )כגון string,integer ואף טיפוסים מורכבים יותר( באמצעות,XML כיצד להגדיר מהי המתודה אשר מעוניינים להפעיל, ומהם הפרמטרים הפורמאליים )טיפוסי הנתונים( והאקטואליים )ערכים ספציפיים בזמן קריאה( הנשלחים למתודה זו. הודעות מועברות בין גורם אחד לאחר על גבי שכבת התובלה Services(.)Transport חשוב לציין כי הודעה אשר חוצה מספר גורמים המשתתפים בתהליך עסקי מסוים יכולה לנוע על גבי שכבות תובלה שונות,HTTP(...TCP/IP,SMTP ) במעבר בין הגורמים השונים. באיור 4 ניתן לראות כי הלקוח אשר פונה אל שרת מספר 1 שולח אליו הודעת SOAP על גבי פרוטוקול.HTTP לעומת זאת שרת מספר 1 מתקשר עם שרת מספר 2 באמצעות פרוטוקול.SMTP ואולם לאורך כל הדרך למרות השינוי בפרוטוקול התובלה, הודעת ה SOAP אינה משתנה. העברת ההודעות בין לקוחות ושירותים יכולה להיות סינכרונית בצורה של בקשה ותגובה )Request/Response( או א-סינכרונית. כאשר מדובר בצורה א-סינכרונית יש לטפל בהתאמה בין הודעת הבקשה להודעת התגובה המתקבלת מאוחר יותר. 11

13 בעבודתי זו אתייחס בעיקר ל Header של הודעת ה SOAP שכן באמצעותו ניתן להעביר פרטים המזהים את שולח ההודעה )token( וכך לממש מנגנוני אבטחה ברמת ההודעה )כפי שנתאר בהמשך(. תיאור מפורט של מבנה הודעת SOAP מוגדר ב ]19[, ]20[. : העברת הודעות בין משתתפים שונים בתהליך עסקי איור 4 Service Description מנגנונים לתיאור שירותים שכבה זו מגדירה את האופן שבו מתארים שירותים. Web Services Description ( WSDL,)Language הינו מסמך XML לתיאור הממשק אשר חושף שירות מסוים. מסמך זה מגדיר את החוזה אליו מחויב השירות כלפי המשתמשים שלו. מסמך WSDL מורכב משני חלקים : 1. האחד מתאר את השירות מנקודת מבט אפליקטיבית ללא תלות בפרוטוקול המקשר בין השרת והלקוח, כלומר מגדיר את המתודות וטיפוסי הנתונים אשר חושף השירות. 2. לעומתו השני מגדיר את אופן ההתקשרות אל השירות :.)HTTP מעל SOAP הפרוטוקול המקשר )למשל אופן ההתקשרות קריאה מרוחקת למתודה )RPC( או העברת הודעה לעיבוד.)Messaging(.)URL הכתובת בה "ממתין" השירות לטיפול בקריאות )למשל כתובת באיור 5 ניתן לראות את החלקים המרכיבים מסמך.WSDL 12

14 <Definitions> <types/> <message name = " " /> <porttype name = " " /> <binding name = " " /> <service name = " " /> </ Definitions> איור 5: מבנה מסמך WSDL התגים,<types> <message> ו <porttype> מתארים את השירות מנקודת מבט אפליקטיבית, כלומר מה השירות חושף )לדוגמה אילו טיפוסי נתונים, הודעות וכדומה(. התגים <binding> ו <service> מתארים היכן וכיצד ניתן לפנות אל השירות מנקודת מבט של הכתובת ברשת ופרוטוקול ההתקשרות. מסמך ה WSDL מתאר את השירות מנקודת מבט פונקציונאלית, כלומר מה הפונקציונאליות שהשירות חושף. ואולם, בעולם של שירותים קיים הצורך בתיאור דרישות שאינן פונקציונאליו ת אשר השירות מבקש במטרה לתקשר עימו. דרישות אלו מתוארות באמצעות הסטנדרט WS-.]19[ Policy Quality of Service איכות השירות איכות של שירות מוגדרת באמצעות שלושה סטנדרטים : אבטחת מידע,)WS-Security( מהימנות הערוץ דרכו עוברות ההודעות בדרך אל השירות,)WS-ReliableMessaging( מימוש טרנזקציות,WS-AtomicTransaction( )WS-BusinessActivity.]20[ Service Components הרכבת תהליכים עסקיים רובד זה של הגדרות וסטנדרטים עוסק בהרכבתם של שירותים ליצירת תהליכים עסקיים. ]20[ מתאר בהרחבה את )Business Process Execution Language( BPEL כשפה סטנדרטית להגדרת תהליכים עסקיים. 13

15 3.1.3 מבוא ל Security WS - נושא האבטחה בסביבת טכנולוגית Web Services מתואר ומטופל באמצעות הסטנדרט WS-,)web services security( Security ובקיצור,WSS המתואר בהרחבה ב,]11[.]12[ סטנדרט זה מטפל בשלושה נושאים מרכזיים הקשורים באבטחה בעולם של :Web Services SOAP כיצד לחתום בצורה סטנדרטית את הודעת ה XML Digital Signature המועברת בין הצדדים המשתתפים בתהליך עסקי מסוים. הסטנדרט מגדיר בדיוק כיצד לשלב את החתימה בכותרת ההודעה )ה -,)Header ראה איור 3. XML Encryption כיצד להצפין את הודעת ה SOAP או חלקים ממנה. בדומה לחתימה הדיגיטאלית, גם כאן משתמשים בכותרת ההודעה על מנת לספק אינפורמציה בקשר לאופן שבו הצד אליו מגיעה ההודעה יממש את תהליך הפענוח. security כיצד לשלב בכותרת ההודעה Authenticity (Security token binding) SAML,X.509 certificate,kerberos ticket,user-name/password )כגון token assertion וכדומה(. הטיפול בסטנדרט WS-Security הינו מחוץ לתחום של עבודתי זו. אולם בחלק המעשי, כאשר אדרש להעביר SAML Assertion )סוג של token בעולם של SAML אותו נתאר בהרחבה בהמשך( בין הישויות המשתתפות בתהליך עסקי מסוים, אשתמש ברעיונות המרכזיים המתוארים ב WS-Security )השימוש בכותרת ההודעה להעברת ה token.)security שלושת הנושאים שהזכרנו קודם לכן, אותם מגדיר,WS-Security הביאו ליצירתם של סטנדרטים נוספים הנגזרים מ,WS-Security כמתואר באיור. 6 WS - Secure Conversation WS - Federation WS - Authorization WS - Policy WS - Trust WS - Privacy WS - Security SOAP : הסטנדרטים המטפלים באבטחת מידע בסביבת Web Services איור 6 סטנדרטים אלו ]19[ מטפלים בנושאים ספציפיים יותר, מהווים הרחבה של,WS- Security וביחד יוצרים משפחה של סטנדרטים המטפלת בנושאי אבטחת מידע בסביבת.Web Services הסטנדרט WS-Policy מגדיר כיצד ניתן לתאר באמצעות XML את מדיניות האבטחה של שירות מסוים. באמצעות סטנדרט זה ניתן להגדיר האם וכיצד לחתום דיגיטאלית את ההודעה המיועדת 14

16 לשירות מסוים, מהו גודל המפתח המינימאלי באמצעות ניתן להצפין הודעה לשירות, לאיזה security token מצפה השירות ועוד. הסטנדרט WS-Trust מגדיר כיצד לממש מנגנון של "אמון הדדי" בסביבת WS- ו WS-Security באמצעות הרכבה של הסטנדרטים Web Services.Policy לדוגמה, ניתן להגדיר באמצעות WS-Policy מהם המאפיינים הנדרשים על מנת לקבל שירות, ועל אילו Assertion Provider השירות סומך. הסטנדרט WS-Federation מגדיר כיצד לממש Federation בסביבת.Web Services סטנדרט זה מגדיר כיצד לבצע אינטראקציה בין הגורמים השונים בקבוצה על מנת לממש תהליכי התקשרות מאובטחים. הרכבה של הרעיונות המתוארים בסטנדרטים הללו יכולה להביא ליצירתו של עולם אינטרנט מאובטח יותר ומתאים יותר לדרישות השוק, המעוניין להשתמש בתשתית זו ליצירת התקשרויות עסקיות מאובטחות בין גופים שונים. 15

17 הגדרת המושגים "זהות" "והרשאה" זהות דיגיטאלית Identity Digital זהות דיגיטאלית הינה יחידת מידע המייצגת בצורה חד ערכית משתמש ברשתות מחשבים. המשתמש מציג את זהותו הדיגיטאלית בפני ישות כלשהי עימה הוא מעוניין לתקשר באמצעות אסימון )Token( מעיין "תעודת זהות" של המשתמש בעולם הדיגיטאלי/בעולם רשתות המחשבים. קיימות טכנולוגיות רבות ומגוונות )חלק קטן מהן אתאר בהמשך( לניהול תהליך ההזדהות בעולם הדיגיטאלי כאשר כל טכנולוגיה כזו מגדירה את הפורמט של Token כזה ואת הדרך להעברתו על גבי הרשת,User-Name/Password( 509.X, certificate,kerberos ticket SAML Attribute Assertion מסוג token וכדומה(. בעבודתי זו אתמקד ב SPKI certificate אותו אתאר בהרחבה בהמשך. המיוחד בסוג זה של,token בשונה מהסוגים האחרים, הוא בכך שהוא לא מזהה בצורה חד ערכית את המשתמש אלא מגדיר את קבוצת המאפיינים השייכים למשתמש זה. בהינתן קבוצת מאפיינים G ניתן להגדיר את הקבוצה *G המכילה את כל המשתמשים בעלי סט המאפיינים G. שירות המקבל פנייה ממשתמש בעל token מסוג זה לא מתעניין בזהותו הספציפית של המשתמש אלא רוצה לבדוק האם המשתמש שייך לקבוצה *G מסוימת המורשית לגשת לשירות זה הזדהות הגדרת המושג Authentication ע"פ ]18[ הזדהות )Authentication( הינה הדרך באמצעותה תהליך הרץ במחשב מסוים מאמת את זהותו של המשתמש המריץ תהליך אחר, הרץ במחשב הנוכחי או במחשב מרוחק ברשת, המנסה לתקשר עימו. תהליך ההזדהות משלב בתוכו תהליכי הצפנה ופענוח )כפי שנראה בסעיף הבא( על מנת לוודא כי המשתמש עימו אנו מדברים הוא אכן המשתמש לו אנו מצפים. ואולם במנגנונים הקיימים למימוש וניהול תהליך ההזדהות, משתמש מזוהה בצורה חד ערכית על פי זהותו הדיגיטאלית, כפי שהוגדרה בסעיף מצב זה אכן ישים בארגונים סגורים בהם קבוצת המשתמשים מוגדרת היטב, במקום מרכזי אחד. במערכות מבוזרות הפרוסות על פני מספר ארגונים, מאגרי המשתמשים מפוזרים גם הם בארגונים השונים, מנוהלים ע"י מנהלי מערכות מידע שונים, בטכנולוגיות שונות. משתמש מסוים המוגדר בארגון אחד אינו מוגדר בארגון אחר בקבוצה ולכן מנגנון המזהה חד ערכית כל משתמש אינו מתאים לסוג כזה של מערכות מידע. במערכות הללו, כפי שמתאר ]6[, נדרש מנגנון חכם יותר ליצירת אמון הדדי )Trust( בין הארגונים השונים. בעבודתי זו אתאר ואממש סטנדרט ליצירת האמון ההדדי הנ"ל בין הארגונים השונים, המאפשר למשתמש המוגדר בארגון אחד לבצע הזדהות מול ארגון אחר אשר אינו מכיר אותו. 16

18 ה) מנגנונים קיימים לניהול זהויות והזדהות בסעיף זה אציג שלושה מבין המנגנונים הקיימים כיום למימוש תהליך של הזדהות )Authentication( ברשתות מחשבים ובפרט ברשת האינטרנט : Ticket ]18[, Kerberos הזדהות באמצעות מפתח ציבורי ]18[ ו - Passport.Net ]12[. כל זאת על מנת לבדוק ולהציג בהמשך את היתרונות של המנגנון אותו אציג בעבודתי זו על פני המנגנונים הקיימים הזדהות באמצעות Kerberos Ticket פרוטוקול ההזדהות Kerberos פותח באוניברסיטת M.I.T כאשר מטרתו לאפשר למשתמשי תחנות הקצה ברשת הארגונית לגשת אל המשאבים השונים בארגון בצורה מאובטחת. התקשרות המאובטחת באמצעות פרוטוקול זה בין לקוח ושרת משלבת בתוכה אינטראקציה בין 4 גורמים מרכזיים כמתואר באיור : 7 1. הלקוח מבקש השירות.)Alice( 2. השרת ספק השירות.)Bob(.3 שרת הזדהות Server Authentication )נסמן בקצרה.)AS 4. שרת המספק "אישורים" Server Ticket-Granting )נסמן בקצרה.)TGS איור 7 מתאר תהליך התקשרות בין הלקוחה Alice והשרת Bob באמצעות גרסה 4 של פרוטוקול זה ( V4.)Kerberos פרוטוקול Kerberos מבוסס על סוג של "אישור" )המכונה )Ticket אותו מקבל הלקוח משרת ה"אישורים",)TGS ובאמצעותו פונה הלקוח אל המשאבים השונים ברשת הארגונית לקבלת שירותים. ה"אישור" הינו פריט מידע מאובטח וחתום כך ששרת המקבל אישור זה מהלקוחה Alice יכול לדעת בוודאות כי זוהי אכן,Alice ולא לקוח אחר הטוען כי הוא.Alice על מנת ליזום קשר המאובטח באמצעות Kerberos בין Alice הלקוחה ו Bob השרת,.)User Name( היושבת מול תחנה כלשהי ברשת הארגונית, מזינה את שם המשתמש שלה,Alice בשלב הראשון תחנת המשתמש שולחת את שם המשתמש, באופן גלוי ולא מוצפן, אל שרת ה. AS תחנת המשתמש מולה יושבת Alice מקבלת בחזרה, בשלב השני, מפתח לשיחה עם ה K S ( TGS ו ) S )K TGS(A, K המוצפנים ע"י K A )המפתח הסודי של.)Alice בשלב זה מתבקשת Alice להזין את הסיסמה שלה באמצעותה תוכל לפענח את ההודעה שקיבלה בשלב 2. תחנת המשתמש שולחת בשלב השלישי אל ה TGS את (S K TGS(A, K )זהותה של Alice ומפתח השיחה חתומים ע"י המפתח הסודי של ה,)TGS ואת זהותו של Bob איתו היא מעוניינת לתקשר. ה TGS מייצר ומחזיר, בשלב הרביעי, את K AB המפתח לשיחה בין Alice ו.Bob ה TGS מחזיר שתי גרסאות של K, AB האחת חתומה ע"י K S המיועדת עבור Alice והשנייה חתומה ע"י K B עבור.Bob כעת בשלב החמישי, מעבירה Alice אל Bob את מפתח השיחה בניהם AB( K(. בשלב השישי והאחרון Alice מקבלת מ Bob הוכחה לכך שהיא אכן מדברת איתו ולא עם מתחזה. 17

19 AS Authentication Server [1] User name Alice (A) [2] K A (K S, K TGS (A, K S )) TGS Ticket Granting Server [3] K TGS (A, K S ), B, K S (t) Alice [4] K S (B, K AB ), K B (A, K AB ) The client [5] K B (A, K AB ), K AB (t) Bob The Service Provider (I.e. file or web server) [6] K AB (t+1) : תהליך הזדהות מבוסס Kerberos איור 7 ניתן לראות, ע"פ התהליך שתואר לעיל, כי ה Server Authentication מכיר את המפתחות הסודיים )הסיסמאות( של כל המשתמשים בארגון. דרישה זו מהווה בעיה כאשר מדובר ברשת האינטרנט במצב בו המשתמשים השונים המקבלים שירותים שייכים לארגונים שונים ולא מוגדרים במאגר משתמשים מרכזי אחד. כמו כן במנגנון זה המשתמש מזוהה בצורה חד ערכית באמצעות שם המשתמש והסיסמה שלו. במנגנון אותו אתאר בעבודתי זו משתמש מזוהה ע"י סט המאפיינים המתארים אותו. ה"אישור" במנגנון זה מהווה הוכחה לכך שהמשתמש אכן מחזיק בסט המאפיינים הללו הזדהות באמצעות 509.X Certificate )מנגנון מבוסס )PKI מנגנון הזדהות המבוסס על תעודות בפורמט 509.X הינו מימוש של הרעיון הכללי יותר המכונה ובפרט המימוש באמצעות תעודות,X.509,PKI מנגנון.)Public Key Infrastructure( PKI מספק דרך לקשירת המפתח הציבורי של ישות מסוימת אל הישות עצמה, כך שבהינתן הודעה חתומה ע"י מפתח פרטי,K Private ניתן לומר בוודאות כי הודעה זו נחתמה ע"י ישות K, וכי המפתח הציבורי של ישות זו הנו K. Public מימוש הקשר שתואר לעיל בין המפתח הציבורי לבין זהותה הדיגיטאלית של ישות מסוימת, או המפתח הפרטי שלה, מתבצע באמצעות תעודות דיגיטאליות )Certificates( המונפקות עבור הישויות ברשת. אמיתותה של התעודה הדיגיטאלית מובטח באמצעות חתימתה ע"י ישות מרכזית אחת אשר כולם סומכים עליה המכונה CA Authority( )Certificate כמתואר באיור. 8 התעודה הדיגיטאלית מכילה שדות מידע כגון: שם 18

20 המזהה את בעל התעודה בצורה חד ערכית, המפתח הפרטי שלו, מנפיק התעודה )ה CA שחתם עליה( וכדומה. מבנה נתונים זה מוגדר בצורה חד משמעית באמצעות הסטנדרט 509.X. Certificate Authority Alice Bob Betty Carol : קבוצת משתמשים המממשים PKI איור 8 קבוצת ישויות אשר "סומכות" על ישות מרכזית אחת, והמחזיקות בתעודות דיגיטאליות אשר הונפקו ע"י ישות מרכזית זו, כמתואר באיור, 8 מגדירה סביבת.PKI הקשר בין המשתמשים בקבוצה מתבצע דרך הישות המרכזית )באמצעות התעודות שהונפקו על ידה(, והמשתמשים בינם לבין עצמם אינם מכירים אחד את השני. כאשר Alice ו Bob מעוניינים לתקשר הם מציגים אחד אל השני את התעודות הדיגיטאליות שהונפקו ע"י הישות המרכזית באמצעות תהליך אותו נתאר בהרחבה בהמשך, כך הם מזדהים ומציגים את עצמם ברשת, ובנוסף מסכימים על מפתח סודי לשיחה Key(.)Session איור 9 מתאר תהליך הזדהות המבוסס על מפתח ציבורי. משתמשת ברשת המכונה,Alice המעוניינת לתקשר עם,Bob פותחת את התהליך ע"י הצפנת המזהה שלה Identity( )Digital ומספר אקראי R. A ההצפנה מתבצעת באמצעות המפתח הציבורי של Bob כך שרק הוא יכול לקרוא את ההודעה שנשלחה. כאשר Bob מקבל את ההודעה הוא עדיין לא יכול לדעת בוודאות כי הודעה זו אכן נשלחה מ.Alice ולכן בשלב השני הוא שולח בחזרה את המספר שקיבל מ R, A,Alice וכן מספר אקראי חדש שהוא מייצר R. B כמו כן הוא מציע ל Alice מפתח עבור השיחה,.)Session Key( K S הוא מצפין את ההודעה באמצעות המפתח הציבורי של.Alice כעת כאשר Alice מקבלת את ההודעה היא יכולה להיות משוכנעת כי היא אכן הגיעה מ,Bob והיא מסכימה להשתמש ב S K כמפתח לשיחה ביניהם. בשלב השלישי והאחרון Alice מחזירה אל Bob את המספר האקראי שיצר, מוצפן ע"י משוכנע שהוא אכן מתקשר עם.Alice K S )מפתח השיחה ביניהם(, על מנת שהוא יהיה 19

21 [1] E B(A, R A) [2] E A(R A, R B, K S) Alice The client [3] K S(R B) Bob The server : תהליך הזדהות מבוסס Public Key איור 9 הבעיה המרכזית של המנגנון שתואר לעיל )מנגנון המבוסס )PKI היא הצורך בישות מרכזית אחת בה מאוחסנים כל המפתחות הציבוריים של כל הישויות ברשת. ישות מרכזית זו הינה ה CA Authority( )Certificate המתואר באיור 8 כישות אשר כל המשתמשים השונים ברשת מחוברים אליה הזדהות באמצעות.NET Passport ה Passport.Net )ובקיצור )Passport הינו מנגנון הזדהות לאפליקציות Web ברשת האינטרנט המבוססות על הטכנולוגיות של.Microsoft הרעיון המרכזי העומד מאחורי טכנולוגית ה Passport הינו קיומה של ישות מרכזית אחת, המשרתת מספר רב של אפליקציות )אתרים( ברשת האינטרנט, ומספקת שירותי הזדהות )ה - Server.Net Passport כפי שמתואר באיור (. 10 האפליקציות השונות ברשת, שתהליך ההזדהות אינו חלק מהתהליכים העסקיים שלהן, "משאירות" את מימוש תהליך ההזדהות לישות אחרת )חיצונית( שזהו תפקידה המרכזי. כל נושא ניהול המשתמשים נשאר מחוץ לתחום האחריות של האפליקציות השונות. ניהול מנגנון ההזדהות במקום מרכזי אחד, המשרת מספר רב של אפליקציות ברשת, מאפשר שימוש במזהה ייחודי אחד לכל משתמש המבקש לקבל שירותים מכל אחת מהאפליקציות ברשת, שתהליך ההזדהות בהן מבוסס על.Net Passport. נושא זה מכונה )Single Sign On( SSO והוא מהווה את אחת הדרישות חשובות גם ממנגנון ההזדהות אותו אציג בעבודתי זו. מנגנון הזדהות המממש SSO מאפשר למשתמש להזדהות פעם אחת בלבד מול אותה ישות מרכזית ובהמשך להיכנס ולהזדהות בצורה פשוטה מול כל אחת מהאפליקציות המבוססות על.Net Passport )דבר המשפר את חווית הגלישה למשתמשים(. בנוסף, כל משתמש ברשת צריך ליזכור צמד אחד בלבד )שם משתמש, וסיסמה( באמצעותם הוא מזדהה מול כל האפליקציות ברשת )בעצם מול הישות המרכזית(. ואולם לצד יתרונות אילו ישנם לא מעט חסרונות בשימוש בישות מרכזית אחת המחזיקה ומנהלת את המשתמשים ברשת. התלות בישות אחת מחייב את אותה ישות להיות עמידה בפני נפילות שכן אם ישות זו אינה זמינה, כל האפליקציות המבוססות עליה הופכות להיות לא זמינות. בנוסף, ריכוז המידע על כל המשתמשים הינו בעייתי מנקודת מבט של פרטיות המידע האם משתמשי המערכות השונות יהיו מוכנים לחשוף את כל פרטיהם האישיים במקום מרכזי אחד, לכל האפליקציות ברשת המבוססות על ישות מרכזית זו? 20

22 ה) Redirect back Login to the.net Passport with a cookie [4].Net Passport Server Web Browser [3] Redirect the user to the Passport server. Get the requested web page [1] [2] [5] Request a web page Web Server : ארכיטקטורת מנגנון המבוסס.Net Passport איור 10 כמו כן בניגוד למנגנון אותו אציג בעבודתי זו, המבוסס על סטנדרטים אוניברסאליי ם, מנגנון ה Passport מבוסס על טכנולוגיה של Microsoft ולא מאפשר אינטגרציה בין אפליקציות שונות )אתרים שונים( המבוססות על טכנולוגיות שונות. תהליך ההזדהות ב - Passport.Net, כפי שמתואר באיור, 10 מבוסס על שני פרוטוקולים מעולם האינטרנט : Redirect HTTP ו HTTP מקיף בפרוטוקולים הנ"ל הינו מחוץ לתחום של עבודתי זו(. באמצעות )דיון Cookies Redirect האתר המבקש הזדהות מפנה את המשתמש אל שרת ה,Passport וזה מספק למשתמש Cookie באמצעותו יוכל המשתמש להוכיח כי הוא אכן הזדהה מול אותה ישות מרכזית - Server.).Net Passport התהליך המתואר באיור 10 מורכב מחמשת השלבים הבאים: 1. המשתמש מבקש לגשת אל דף Page( )Web באתר אינטרנט מסוים. 2. האתר, אשר אמור לספק למשתמש את הדף, מבקש מהמשתמש להזדהות ולכן מבצע פעולת HTTP Redirect אל שרת ה.Passport 3. המשתמש מקבל משרת ה Passport דף אינטרנט המכיל שדות להזנת שם המשתמש והסיסמה. המשתמש מזין את הפרטים הנדרשים ומבצע.Login 4. שרת ה Passport )בהנחה שאכן זיהה את המשתמש( מבצע למשתמש HTTP Redirect בחזרה אל דף האינטרנט שהמשתמש ביקש בתחילה. כעת המשתמש מגיע אל אתר האינטרנט עם Cookie המאשר כי הוא אכן ביצע הזדהות מול ה - Passport.Net.Server 5. בשלב האחרון המשתמש מורשה לגשת אל הדף המבוקש. 21

23 חשוב לציין כי במהלך כל התהליך הנ"ל המשתמש לא ביצע דבר פרט להזנת שם המשתמש והסיסמה, וכל המעברים )המתוארים באיור ) 10 שבין ה Server Web וה - Server Passport בוצעו באופן אוטומטי ע"י מנגנון ה - Passport.Net ניהול הרשאות גישה Authorization ע"פ ]14[, מנגנון לניהול הרשאות גישה )Authorization( מגביל ומפקח על הצעדים אותם יכול לבצע משתמש בצורה ישירה או בצורה עקיפה )באמצעות תוכנית מחשב הרצה תחת הרשאתו( במערכת מחשב כלשהי. בניגוד לתהליך ה,Authentication בשלב ניהול ההרשאה אנו כבר יודעים בוודאות מיהו המשתמש עימו אנו מתקשרים וכעת עלינו לוודא כי משתמש זה יכול לגשת רק אל פרטי המידע והשירותים להם הוא מורשה. בעבודתי זו אציג את ]2[ XACML כמנגנון סטנדרטי, דינאמי וחזק לניהול הרשאות גישה אל שירותים בסביבת,Web Services המבוסס על,XML ועל כן גם מתאים לעולם האינטרנט הגדרת המושגים Identity.Federation and Federated המושג Federation מתייחס לקבוצה של ארגונים בעלי קשר מסוים )עסקי, מחקרי וכדומה(. דוגמאות לקבוצות היכולות ליצור Federation הינן קבוצת האוניברסיטאות בארץ, בתי החולים, הגופים הפיננסיים במשק וכדומה. ע"פ ]19[, מנגנון ניהול מערך ההרשאות בסביבה כזו מכונה Federated Identity Management )ובקיצור )FIM ומטרתו לספק אפשרות למשתמשים שונים השייכים לארגונים בקבוצה להשתמש באותו מזהה דיגיטאלי בכל השירותים המסופקים ע"י ארגונים השייכים לקבוצה. הארגונים השייכים לקבוצה יוצרים ביניהם מערכת המבוססת על אמון הדדי,)Trust( כך שארגון כלשהו א', סומך על ארגון אחר ב' שיבצע עבורו את תהליך ה.Authentication משתמש השייך לארגון ב', ומבקש לקבל שירותים מארגון א', נדרש להוכיח לארגון א' כי הוא אכן הזדהה בהצלחה מול ארגון ב'. הצורך במנגנון הנ"ל נובע מהרצון לשתף משאבים ושירותים בין מספר ארגונים המנהלים את מאגר המשתמשים וההרשאות שלהם בצורות או בטכנולוגיות שונות. הסטנדרט המתואר בעבודתי זו SAML( ]1[ ) מספק את הדרך לפתרון הבעיה של ניהול זהויות בסביבת קבוצות של ארגונים. סטנדרט זה מגדיר את המושג "הכרזה",)Assertion( באמצעותה ארגון מכריז כי משתמש מסוים הזדהה מולו וכי למשתמש זה שייך סט של מאפיינים מסוימים )באמצעותם ניתן לממש בשלב מאוחר יותר תהליך של Authorization אותו נתאר ונדגים בהרחבה בהמשך(. 22

24 3.3 ניהול זהויות בסביבת Web באמצעות SAML הסטנדרט )Security Assertion Markup Language( SAML,]1[ אשר פותח ע"י הארגון המכונה,OASIS מגדיר את האופן להעברת המידע הדרוש באבטחת קישור )מימוש תהליך עסקי מסוים( בין שתי ישויות ברשת מחשבים כדוגמת רשת האינטרנט. המידע המועבר מספק אינפורמציה על הצדדים השונים המשתתפים בתהליך העסקי. הערך המוסף החשוב ביותר של SAML טמון בכך שהוא מבוסס על,XML הידועה כשפה סטנדרטית לתיאור והעברת נתונים על גבי רשת האינטרנט. סטנדרט זה בעצם מגדיר סכמות )מבנים מוגדרים וקבועים מראש( של מסמכי XML המתארים את זהותו של משתמש מסוים, את הפרטים המאפיינים אותו וכדומה. כלומר, SAML מגדיר כיצד לייצג,Token המייצג את זהותו של המשתמש, בשפת.XML באמצעות Token זה יוכל המשתמש להזדהות מול ספקי שירות שונים ברשת האינטרנט. היכולת להזדהות עם Token מסוים אחד מול מספר ארגונים שונים ברשת מכונה Single Sign ( SSO.)On ]1[ מציג ארבעה נושאים מרכזיים, הקשורים במימוש מנגנוני,SSO שהניעו את הפיתוח של הסטנדרט :SAML הנושא הראשון קשור במושג Cookies )ראה נספח מושגים(. מרבית המנגנונים המממשים SSO משתמשים ב Cookies לשם יצירת Token המזהה את המשתמש. הבעיה היא שלא ניתן להעביר cookies בין.DNS Domains כלומר, Cookie שהתקבל ע"י לא ניתן להעברה אל. בעיה זו נפתרה באמצעות מימוש מנגנוני )Cross-Domain SSO( CDSSO כדוגמת ]24[ Tivoli Access Manager של חברת,IBM המאפשר העברה של Security Token בין DNS Domains שונים. ואולם מימוש ה CDSSO אינו סטנדרטי וכל מוצר SSO פתר את הבעיה בצורה שונה, ולכן לא ניתן לבצע אינטגרציה בין המוצרים השונים. כידוע לא ניתן )וגם לא רצוי( לחייב קבוצה של ארגונים להשתמש בטכנולוגיה מסוימת. הנושא השני קשור באופן שבו מוצרים שונים מממשים SSO ו -.CDSSO אופן המימוש, כפי שציינו קודם לכן, אינו מאפשר ביצוע אינטגרציה בין מוצרים של חברות שונות. מנגנונים מבוססי,SAML כסטנדרט המבוסס על,XML נראים כיום כפתרון הטוב ביותר לעולם האינטרנט. הנושא השלישי קשור בתחום שבו עוסקת עבודתי זו אבטחת מידע בסביבת Web.Services טכנולוגית,Web Services המשמשת לקישור בין לקוחות ושירותים ברשת האינטרנט, מבוססת על.XML ולכן נוצר הצורך במנגנון לניהול הזהויות המבוסס גם הוא על שפת.XML הנושא הרביעי והאחרון קשור במושג Federation הצורך בניהול זהויות בסביבה מרובת ארגונים כאשר בכל ארגון מנוהל מערך ההרשאות והמשתמשים בטכנולוגיה שונה. 23

25 1.3.3 ניהול הרשאות באמצעות מאפיינים Security Attribute-Based מנגנון SAML מתאים במיוחד למצבים בהם מנגנון ניהול ההרשאות )Authorization( מבוסס על המאפיינים של המשתמש. מנגנון כזה מכונה Attribute-based Security וניתן לראות בו כהרחבה של.)Role-Based Access Control( ]13[ RBAC במנגנון המבוסס RBAC כל משתמש ממלא תפקיד מסוים אחד בארגון. לעומת זאת במנגנון המבוסס מאפיינים לכל משתמש קבוצה של פריטי מידע המאפיינים אותו )כגון: משכורת ממוצעת, תפקיד, מצב משפחתי, מקום עבודתו וכדומה(. בתהליך ה Authorization נבדקים פרטי המידע הרלוונטיים בהתאם למדיניות אבטחת המידע )ה - )Policy של השירות. הסטנדרט SAML מגדיר במדויק כיצד לייצג Token המכיל את המאפיינים של משתמש מסוים. הסטנדרט מכנה Token זה בשם Attribute.Assertion בפרק הבא אציג את XACML כסטנדרט המגדיר מנגנון ניהול הרשאות המבוסס על מאפיינים ארכיטקטורת מנגנון לניהול זהויות המבוסס SAML מנגנון ניהול זהויות המבוסס על SAML מורכב משלושה שחקנים כמתואר באיור 11 : מבקש השירות/הלקוח )ה )Client הארגון אשר מזהה ומכריז על מאפייניו של הלקוח )ה Provider.)Assertion ספק השירות )ה Provider.)Service Assertion Provider Step 1 Assertion Request Client Step 2 Service Request Service Provider איור : 11 השחקנים המשתתפים במערכת מבוססת SAML כשלב מקדים, לפני הפנייה לשירות, מבקש הלקוח מה Provider Assertion שלו אסמכתא המעידה כי הוא אכן הזדהה מול אותו Assertion Provider וכי ללקוח זה סט של פרטי מידע המאפיינים אותו. הבקשה מתבצעת באמצעות ההודעה המוצגת באיור 13 אשר תתואר בהמשך. 24

26 האסמכתא המתקבלת חתומה דיגיטאלית ומצורפת אל הבקשה לשירות אשר הלקוח מעוניין לשלוח אל ספק השירות )ה Provider.)Service ספק השירות משתמש במנגנונים כדוגמת XACML )אותו נתאר בהרחבה בפרק 3.4( על מנת לבדוק האם המשתמש המבקש את השירות מורשה לגשת אל שירות זה. הסטנדרט SAML מגדיר שלושה סוגים של הודעות המועברות בין שלושת הגורמים השונים בתהליך ההזדהות. איור 12 מתאר את ההודעה המרכזית והחשובה ביותר הכרזת SAML מסוג Attribute Assertion )"הכרזת מאפיינים"(. באמצעות הכרזה מן הסוג הזה מאשר ה Assertion Provider כי לבעל ההכרזה קבוצה מסוימת של מאפיינים. באיור 12, בשורה ]02[, ניתן לראות כי בעל ההכרזה קיבל אותה מארגון המכונה.anybank ניתן לזהות את שני המאפיינים השייכים למשתמש )המוגדרים בשורות ]04[ ]11[( המעידים כי הלקוח הינו "לקוח זהב", וכי ללקוח מסגרת אשראי של $50,000. בהמשך נראה כיצד באמצעות XACML ניתן להשתמש במאפיינים הללו על מנת לממש תהליך של.Authorization [01] <?xml version = "1.0" encoding = "UTF-8"?> [02] <saml: AttributeAssertion Issuer = " IssueInstant = " "> [03] <Condition NotBefore = " " NotOnOrAfter = " " /> [04] <AttributeStatement> [05] <Attribute AttributeName = "ClientStatus"> [06] <AttributeValue>Gold-Client</AttributeValue> [07] </Attribute> [08] <Attribute AttributeName = "CreditLimit"> [09] <AttributeValue>50,000</AttributeValue> [10] </Attribute> [11] </AttributeStatement> [12] </saml: AttributeAssertion> איור : 12 המבנה של הכרזת SAML Attribute Assertion קיימים שני סוגים נוספים של הכרזות SAML אשר הינם מחוץ לתחום של עבודתי זו: הכרזת Authentication המשמשת לזיהוי חד ערכי של משתמש, מכילה פריטי מידע המתארים את אופן ההזדהות של המשתמש מול ה Provider Assertion שלו, לדוגמה: מתי התבצעה ההזדהות, עד מתי הזדהות זו תקיפה ומהו ה token המשמש כתעודת הזהות של המשתמש. הכרזת Authorization באמצעותה מגדירים לאילו משאבים/שירותים משתמש כלשהו מורשה לגשת(. בניגוד להכרזת מאפיינים Assertion( )Attribute בהכרזה מן הסוג הזה מצוין בצורה מפורשת מהו השירות אליו מורשה המשתמש לגשת, לדוגמה: ה URL של 25

27 ה) אתרי האינטרנט אליהם מורשה המשתמש לגשת. בעת הפנייה אל אתר מסוים תתבצע בדיקה האם אתר זה נמצא ברשימת האתרים אליהם מורשה המשתמש לגשת. כפי שצוין קודם לכן, הסטנדרט SAML מגדיר סוג נוסף של הודעות Assertion Request( XML ו Response )Assertion באמצעותן מבקש, ואח"כ מקבל, המשתמש מה Assertion Provider הכרזות.SAML איור 13 מציג דוגמה לבקשה אותה שולח לקוח בשם anyuser אל הארגון anybank המזהה אותו )ה Provider Assertion שלו(. בנוסף להכרזות )ה SAML כיצד לצרף הכרזת SAML ואופן הבקשה והקבלה של הכרזות, מגדיר )Assertions לפרוטוקול התובלה המקשר בין הלקוח והשרת. בעבודתי זו אני מתמקד בטכנולוגית Web Services ולכן אני מניח כי פרוטוקול הקישור הינו.SOAP ואולם SAML מגדיר כיצד לצרף הכרזות אל פרוטוקולים נוספים, כגון HTTP )כאשר הלקוח הינו.)Web Browser הכרזת ה SOAP מצורפת אל כותרת הודעת ה SAML Header של ההודעה, ראה איור 3 (. [01] <?xml version = "1.0" encoding = "UTF-8"?> [02] <saml:assertionrequest [03] IssueInstance = " " [04] Destination = " [05] <Subject> [06] <NameID>anyuser</NameID> [07] <Password>123456</Password> [08] <Subject> [09] </saml:assertionrequest> איור : 13 מבנה ההודעה לבקשת הכרזה מה - Provider Assertion לבסוף מגדיר הסטנדרט גם אוסף של תרחישים אפשריים לאינטראקציה בין שלושת הגורמים המתוארים באיור 11 על מנת לממש פתרון המבוסס על.SAML תרחיש אחד כזה, מבין רשימת התרחישים המתוארים בסטנדרט, אממש בחלק המעשי של הפרויקט מהו הערך המוסף של SAML לעומת מנגנוני הזדהות קיימים כפי שראינו בתחילת הפרק, הערך המוסף החשוב ביותר של SAML הינו השימוש ב XML לייצוג מבני הנתונים ופריטי המידע השייכים לסטנדרט. שפת XML מתאימה במיוחד לרשת האינטרנט ומאפשרת אינטגרציה בין טכנולוגיות שונות ומגוונות אשר חיות בסביבה זו, דבר המאפשר יצירת "אמון הדדי" )Trust( בין ארגונים המשתמשים בטכנולוגיות שונות. כל ארגון אחראי על המשתמשים השייכים לו, ולא נדרשת תלות טכנולוגית בין מאגרי המשתמשים השונים. הפיזור של מאגרי המשתמשים על פני הארגונים השונים הינו ערך מוסף חשוב נוסף, שכן בניגוד לטכנולוגיה המבוססת על 509.X certificate )פרק ( או.Net Passport )פרק 26

28 (, מנגנון המבוסס על SAML אינו דורש ריכוז של מאגר משתמשים מרכזי אחד אשר כל קבוצת הארגונים תלויה בו. פגיעה או פריצה אל מאגר מרכזי כזה עלולה לפגוע בכל הארגונים בקבוצה. מנגנון מבוסס SAML מספק בנוסף גם כלים חזקים וחשובים למימוש מדיניות אבטחה המבוססת על מאפיינים security(.)attribute based מערכות ניהול הרשאות המבוססות מאפיינים, כגון XACML )פרק 3.4(, מהוות הרחבה של המערכות המבוססות על תפקידים )RBAC( וניתן באמצעותן לבנות מדיניות אבטחה המבוססת על אוסף של כללי היסק מורכבים יותר. הסטנדרט SAML מספק מנגנון יעיל ליצירת פרופיל של משתמש המבוסס על מאפיינים באמצעות השימוש בהכרזות מסוג.Attribute Assertions 27

29 הגדרת מדיניות אבטחה וניהול בקרת הגישה באמצעות XACML מבוא ל XACML התקן )extensible Access Control Markup Language( XACML,]2[ מגדיר את האופן להגדרת מדיניות האבטחה ובקרת הגישה אל שירותים ומשאבים. מטרתו של תקן זה, המבוסס על,XML היא להגדיר קבוצה של חוקים )Rules( שמטרתם לקבוע למי מותר לגשת למה, מתי, וכיצד. מערכת החוקים הללו מבוססת על נתונים המאפיינים את הבקשה: התפקיד )Role( אותו ממלא מבקש השירות )בדומה למנגנון המבוסס,)RBAC או מאפיינים אחרים המיוחסים למבקש השירות )רופא בכיר, מנהל מחלקה, וכדומה(. מאפייני הבקשה )לדוגמה, שירות המחייב שימוש ב SSL בעת הפנייה(. צורת ההזדהות )ה,)Authentication שירות עשוי לחייב הזדהות באמצעות תעודה בפורמט,X.509 הכרזת Kerberos Ticket,SAML וכדומה. בנוסף להיותו סטנדרט ליצירת חוקים המגדירים את מדיניות האבטחה, XACML מגדיר סט של "חוקים ליצירת חוקים", כלומר כיצד לבצע הרכבה של חוקים במטרה לבנות ולהגדיר Policy או מערכת של,)PolicySet( Policies וכיצד לבצע הערכה של החוקים במטרה לממש Authorization ולקבל החלטה בדבר הרשאת הגישה של משתמש למשאב מסוים. רשת האינטרנט והתפתחותה של פרדיגמת התכנות מבוססת השירותים ( Oriented Service )Architecture יצרו סביבה הטרוגנית בה חיות טכנולוגיות רבות ומגוונות המתקשרות האחת עם השנייה, דבר אשר חייב סטנדרטיזציה באופן תיאור מדיניות אבטחה Policy(.)Security ]2[ מגדיר את הדרישות העומדות בפני שפה המתארת מדיניות אבטחה. אנו נעמוד על הדרישות הללו בהקשר של :XACML.1 השפה תאפשר הרכבה של חוקים )Rules( ליצירת מדיניות.)Policy( בהמשך נתאר את המבנה של שפת XACML ונראה כיצד אוסף של Rules יוצרים,Policy ואוסף של PolicySets יכול להיות מורכב מכמה PolicySet בנוסף,.PolicySet יוצרים Policies.2 אחרים. השפה תגדיר אלגוריתמים להרכבה של חוקים היוצרים מדיניות )Policy( המוגדרת על שירות מסוים: :Deny-Overrides אם המשתמש אינו עומד באחת הדרישות המוגדרות על השירות Rule( אחד מבין אוסף ה Rules המגדירים,)Policy גישתו נדחית. :Permit-Overrides אם המשתמש עומד בדרישה אחת לפחות גישתו מאופשרת. :First-Applicable ההחלטה בדבר גישתו של המשתמש אל השירות מתקבלת ע"י בדיקת החוק הראשון. :Only-One-Applicable המשתמש מורשה לגשת אל השירות רק אם הוא עומד בדרישה אחת בדיוק, מבין קבוצת הדרישות המוגדרות על השירות.

30 השפה תאפשר הגדרת חוקים המבוססים על מאפיינים שונים של מבקש השירות )בדומה ל RBAC המבוסס על התפקיד אותו ממלא מבקש השירות(. השפה תאפשר מידור של מידע המתקבל משירות מסוים. לעיתים למרות שהמשתמש מורשה לגשת אל השירות, הוא אינו רשאי לצפות בכל פרטי המידע אותם השירות מספק. השפה תאפשר הגדרתם של פעולות מתמטיות באמצעותן תתבצע הערכה של.Policies לדוגמה כאשר נדרש לבדוק האם משתמש מסוים מורשה לבצע משיכה של סכום כסף מחשבון הבנק, יש לבצע חישוב המתבסס על הסכום המבוקש, מצב נוכחי של החשבון, ומסגרת האשראי. אחת הדרישות החשובות ממערכת מידור מן הסוג הזה הינה הפרדה בין המנגנון המסנן את האפשרות לגישה אל השירות לבין המנגנון המחליט, בהתאם ל Policy המוגדר על השירות, האם לאפשר או לדחות את הגישה. מנגנון XACML מורכב משני חלקים מרכזיים : PEP ו PDP אותם אתאר בהרחבה בסעיף ה. PEP Policy ( )Enforcement Point מיירט את הבקשה לשירות, מייצר בקשה לבדיקת הרשאה, ושולח אותה אל ה PDP ה. PDP )Policy Decision Point( מבצע את הבדיקה ומחזיר Permit או.Deny מצב שכזה )צמידות חלשה בין המודולים המרכיבים את המנגנון( מאפשר לבצע מידור של שירות מסוים אשר ניתן לפנות אליו באמצעות מספר פרוטוקולים שונים PDP( אחד המקבל פניות מ PEP -ים שונים(. ארכיטקטורת מנגנון בקרת גישה מבוסס XACML מנגנון XACML מורכב שלושה חלקים מרכזיים )כמתואר באיור (: 14 )Policy Enforcement Point( PEP רכיב זה אחראי ליירוט הבקשה לשירות, וביצוע פנייה לבדיקת הרשאתו של המשתמש הנוכחי לקבל את השירות. רכיב זה מותאם לפרוטוקול המקשר בין השרת והלקוח, ותפקידו לחלץ את פרטי מבקש השירות המצורפים לבקשה )הכרזת,Kerberos Ticket,X.509 certificate,saml,)xacml Request( וכדומה(, לייצר בקשה לבדיקת הרשאה UserName/Password ולשלוח אותה אל ה PDP לבדיקה. כמו כן, ניתן לראות את רכיב ה PEP הנוסף ( PEP )Out באמצעותו ניתן לממש מנגנון למידור חלקים מהמידע המוחזר אל הלקוח. מנגנונים מן הסוג הזה יעילים במערכות המשמשות לאיסוף מידע מודיעיני בהן לרשומות שונות בבסיס הנתונים ישנה רמת סיווג שונה, דבר המאפשר סינון המידע המוחזר בהתאם לסיווגו של המשתמש )מימוש מנגנון כזה הינו מחוץ לתחום של עבודתי זו(. )Policy Decision Point( PDP רכיב זה מממש את תהליך ה Authorization הלכה למעשה באמצעות פרטי המשתמש והשירות המבוקש )אשר נשלחו אליו מה,)PEP וה Policy/PolicySet המוגדרים על שירות זה. )Policy Administration Point( PAP יחידה פונקציונאלית האחראית על יצירת ה Policies וקישורם אל השירותים השונים. 29

31 ניתן לצרף שני רכיבים נוספים, אשר אינם מוצגים באיור, 14 המטפלים בשליפת מידע על השירות ועל מבקש השירות. )Policy Retrieval Point( PRP מטפל בשליפת ה Policies המוגדרים על השירות המבוקש מה Database.XACML Policies Service לעיתים אופן המימוש הוא כזה שה )Policy Information Point( PIP Provider מקבל מהמשתמש token המזהה אותו ואת ה Provider Assertion שלו. באמצעות token זה הוא פונה אל ה Provider Assertion המתאים ומבקש ממנו את המאפיינים השייכים למשתמש זה. איור 14 : מודל זרימת הנתונים )DFD( במנגנון XACML ניתן לראות באיור 14 כי אוסף ה Policies מאוחסן במאגר מרכזי אחד, וחשוב לציין כי הסטנדרט של XACML אינו מחייב מאגר נתונים מסוים, ועל כן ניתן לממש זאת באמצעות בסיס נתונים רלציוני,)RDBMS( קובץ,XML או כל מאגר נתונים אחר כלשהו. בעבודתי זו השתמשתי בקובץ XML וממשתי את כל תשתיות הגישה אליו )קריאה/כתיבה( באמצעות אוסף המחלקות המטפלות ב XML בסביבת ה -,.Net ושפת השאילתו XPath )שפה ליצירת שאילתות על מידע המאוחסן בקובצי.)XML 30

32 איור 15 מתאר את המבנה הסטאטי, באמצעות,class diagram של האובייקטים המרכיבים מנגנון,XACML ואת הקשרים שביניהם. ניתן לזהות את שלושת האובייקטים המרכזיים )המסומנים באפור( המרכיבים מנגנון )Rule, Policy, PolicySet( XACML ובאמצעותם מגדירים את מדיניות אבטחת המידע והרשאות הגישה של השירותים בארגון. חוק :)Rule( חוק )Rule( מורכב משלושה חלקים: Target מגדיר על אילו משאבים,)Resources( משתמשים,)Subjects( פעולות,)Actions( ומשתני סביבה )Environment( החוק מוגדר..)Permit or Deny( ההרשאה לביצוע Effect.Target מגדיר תנאים נוספים על הישויות המוגדרות ב Condition איור : 15 מודל UML של האוביקטים המרכיבים מנגנון XACML 31

33 ה) מדיניות :)Policy( מדיניות )Policy( מורכבת מארבעה חלקים: Target בדומה ל target של.Rule ואולם כאשר מדובר ב Policy )כמו גם ב -,)PolicySet ניתן להגדיר את ה target ישירות בשלב הגדרת המדיניות או לחשב אותה בהיסתמך על ה Targets המוגדרים על ה Rules המרכיבים את המדיניות. Rule-Combining Algorithm מציין כיצד מתבצעת ההערכה של ה Rules מרכיבים את ה Policy )לדוגמה: Deny-Overrides או.)Permit-Overrides Obligation פעולה אחת או יותר אשר ה PEP מחויב לבצע בסיום תהליך בדיקת ההרשאה. ניתן להתנות את ביצוע הפעולה בקבלת Permit או.Deny לדוגמה ניתן להגדיר כי בכל פעם אשר מתקבלת תשובת Deny נשלח דואר אלקטרוני אל מנהל המערכת. אוסף של Rules המרכיבים את המדיניות. קבוצת :)PolicySet( Policies :)Policy מורכב גם הוא מארבעה חלקים )בדומה ל PolicySet.Policy המוגדר על target בדומה ל Target Policies האלגוריתם על-פיו מתבצעת הערכת ה Policy-Combining Algorithm המרכיבים את ה PolicySet )בדומה לתהליך הערכת ה Rules ב.)Policy Obligation פעולה או פעולות המתבצעות בסיום תהליך בדיקת ההרשאה, בדומה ל.Policy המוגדר על Obligation.PolicySet המרכיבים את ה Policies אוסף של עד כה הגדרנו ותיארנו את הרכיבים השונים המרכיבים מנגנון.XACML כעת נראה, באמצעות הדוגמה באיור, 16 כיצד ממומשים הרכיבים הללו באמצעות שפת.XML איור 16 מתאר Policy השייך לארגון המכונה,Medi Corp המגדיר כי כל משתמש )User( בעל חשבון דוא"ל בארגון, "med.example.com" רשאי לבצע כל פעולה )Action( על כל משאב Resource( ב( domain של הארגון. שורה ]02[ מכילה את התג הפותח את הגדרת ה.Policy לתג זה שני מאפיינים.)attributes( שורה ]03[ מגדירה מזהה חד ערכי עבור Policy זה. שורה ]04[ מגדירה את אופן הערכת החוקים )Rules המגדירים את ה Policy.)Rule Combining Algorithm( שורה ]05[ מספקת תיאור מילולי של ה.Policy שורה ]06[ מגדירה את ה Target של ה Policy )משאבים, משתמשים, פעולות, ומשתני סביבה עליהם מוגדרת המדיניות(. תג ה Target ברמת ה Policy ריק ולכן עלינו לבדוק את תגי ה Target של החוקים המוגדרים ב Policy על מנת לחשב את ה 32

34 Target של ה.Policy בשורה ]07[ מתחילה הגדרת החוק הראשון )והיחיד( ב.Policy לחוק זה ניתן מזהה חד ערכי באמצעות המאפיין,RuleId וכן מוגדרת ההשפעה )ה )Effect של החוק. במקרה זה "Permit",Effect = מה שמגדיר כי במידה והערכת חוק זה מחזירה את הערך,true כלומר החוק מתקיים, המשתמש רשאי לגשת אל השירות. שורות ]08[ ]11[ מספקות תיאור מילולי עבור החוק הנוכחי בדומה להערה שניתנה ברמת ה Policy בשורה ]05[. שורה ]12[ פותחת את הגדרת ה Target של החוק. [01] <?xml version = "1.0" encoding = "UTF-8"?> [02] <Policy [03] PolicyId = "P1" [04] RuleCombiningAlgId = "identifier:rule-combining-algorithm:deny-overrides"> [05] <Description>Medi Corp Access Control Policy</Description> [06] <Target/> [07] <Rule RuleId = "R1" Effect = "Permit"> [08] <Description> [09] Any Subject with an in the med.example.com [10] Domain can perform any action on any resource. [11] </Description> [12] <Target> [13] <Subjects> [14] <Subject> [15] <SubjectMatch [16] MatchId = "urn: oasis: names: Tc: xacml: 1.0: function: rfc822name-match"> [17] <AttributeValue [18] DataType = " [19] Med.example.com [20] </AttributeValue> [21] </SubjectMatch> [22] </Subject> [23] </Subjects> [24] </Target> [25] </Rule> [26] </Policy> איור : 16 הגדרת Policy בשפת.XACML שורה ]13[ פותחת את הגדרת המשתמשים המורשים לגשת אל שירות המוגן ע"י Policy זה. בשורה ]15[ מוגדר האופן לפיו תתבצע בדיקת שמו של המשתמש, כאשר שורות ]17[ ]20[ מגדירות את המחרוזת "med.example.com" המייצגת את הארגון בו חייבת להיות מוגדרת תיבת הדוא"ל של המשתמש על מנת שיוכל לגשת אל השירות המוגן ע"י Policy זה. כעת נניח כי ה Policy מאיור 16 מצורף אל משאב מסוים בארגון המתואר בדוגמה. איור 17 מתאר בקשה לבדיקת הרשאת הגישה של המשתמש Bart Simpson אל משאב זה. בקשה זו תיוצר ע"י ה PEP )מתוך המידע אשר הגיע בהכרזת ה )SAML ותישלח אל ה PDP אשר יחליט, בהתאם לפרמטרים המוגדרים בבקשה, האם לאפשר את גישתו של המשתמש אל המשאב המבוקש. תהליך זה של יצירת XACML Request מתוך הכרזת ה SAML שהגיעה מהווה בעצם את המעבר מהעולם של SAML אל העולם של XACML אשר, כפי שציינו, אינם תלויים 33

35 האחד בשני. שורה ]02[ פותחת את הבקשה באמצעות התג.<Request> תג זה מכיל בתוכו ארבעה תגים בנים. בשורה ]02[ התג <Subject> מתאר את המשתמש המבקש לגשת אל הקובץ. במקרה זה המאפיין היחיד המתאר את המשתמש הינו כתובת ה שלו. שורות ]04[ ]08[ מצינות מהו פריט המידע המאפיין את המשתמש )כתובת ) ואת שמו של המשתמש )בשורה ]07[(. שורות ]10[ ]16[ מציינות מהו המשאב אליו מבקש המשתמש לגשת. שורות ]17[ ]23[ מציינות מהי הפעולה אשר המשתמש מעוניין לבצע, במקרה זה פעולת.Read בשורה ]24[ מוגדר התג <Environment> המאפשר את הגדרתם של משתני סביבה מסוימים. [01] <?xml version = "1.0" encoding = "UTF-8"?> [02] <Request> [03] <Subject> [04] <Attribute [05] AttributeId = "urn: oasis: names: Tc: xacml: 1.0: subject: subject-id" [06] DataType = "urn: oasis: names: Tc: xacml: 1.0: data-type: rfc822name"> [07] <AttributeValue>bs@simpsons.com</AttributeValue> [08] </Attribute> [09] </Subject> [10] <Resource> [11] <Attribute [12] AttributeId = "urn: oasis: names: Tc: xacml: 1.0: resource: resource-id" [13] DataType = " [14] <AttributeValue>file://example/med/record/patient/BartSimpson</AttributeValue> [15] </Attribute> [16] </Resource> [17] <Action> [18] <Attribute [19] AttributeId = "urn: oasis: names: Tc: xacml: 1.0: action: action-id" [20] DataType = " [21] <AttributeValue>read</AttributeValue> [22] </Attribute> [23] </Action> [24] <Environments/> [25] </Request> איור : 17 בקשה לבדיקת הרשאת גישה במנגנון XACML איור 18 מתאר את התשובה המתקבלת מה PDP כתגובה לבקשה שבאיור 17. ניתן לראות כי ה Policy המודיע כי לא קיים במערכת NotApplicable את הערך PEP - יחזיר אל ה PDP המתאים לבקשה שהתקבלה, ולכן לא ניתן לבצע את ההערכה. בהתאם לתשובה המתקבלת מה PDP ה, PEP יחזיר Deny אל המשתמש. [01] <?xml version = "1.0" encoding = "UTF-8"?> [02] <Response> [03] <Result> [04] <Decision>NotApplicable</Decision> [05] </Result> [06] </Response> איור : 18 התגובה המתקבלת מה - PDP 34

36 בנוסף ל NotApplicable ה PDP יכול להחזיר Deny,Permit או Indeterminate במידה ומוגדרים על השירות אוסף של Policies אשר חלקם ניתנים להערכה וחלקם לא. כפי שהוצג באיור, 14 במידה והמשתמש מורשה לגשת אלה שירות ניתן לבצע גם בדיקה ומידור של פריטי המידע המוחזרים. בנוסף ל Decision ה, Response יכול להכיל גם אוסף של Obligations המוגדרים על ה Policies המוגדרים על השירות. 35

37 טכנולוגיות קיימות המשתמשות ב SAML פרויקט )Project Liberty( Liberty Alliance הארגון המכונה ]21[ Liberty Alliance הוקם בשנת 2001 באמצעות התאגדות של כ 30 גופים, חלקם שייכים לתעשיית התוכנה וחלקם גופים המשתמשים במערכות תוכנה כגון חברות תקשורת. מטרתם המשותפת הינה פיתוח וקידום של סטנדרטים המטפלים בנושא Federated,Identity Management כל זאת על מנת להפוך את סביבת האינטרנט למאובטחת יותר עבור משתמשים )הלקוחות( וארגונים )ספקי שירותים ברשת(. הסטנדרט ]1[, SAML המתואר בהרחבה בעבודתי זו, מהווה בסיס מרכזי חשוב להשגת מטרותיו של ה Alliance Liberty הטוען כי יצירת סביבה גלובלית מאובטחת לא ניתנת למימוש באמצעות כלים המספקים פתרונות לבעיות אבטחה כאשר דרכי הפתרון אינן סטנדרטיות. נתבונן לדוגמה בבעיית ריבוי הסיסמאות ברשת, טכנולוגית.Net Passport )המתוארת בסעיף ( אכן מציגה פתרון לבעיה זו אולם אופן המימוש אינו סטנדרטי ועל כן אינה מספקת פתרון כולל למשתמשי הרשת כולה אלא רק למשתמשים בטכנולוגיות של מיקרוסופט. לטענת ה Liberty Alliance יש לרכז מאמץ משותף של מספר רב של גופים בתעשיית התוכנה על מנת לספק פתרונות הולמים לבעיות של הזדהות וניהול זהויות בעולם האינטרנט. ולכן ה Liberty Alliance הגדירו קבוצה של דרישות אותן אמור מנגנון ניהול זהויות לקיים על מנת שיוגדר כמנגנון ניהול זהויות סטנדרטי, המתאים ליצירת סביבת אינטרנט גלובלית. קבוצת הדרישות הנ"ל רוכזה בשני תקנים מרכזיים:,Liberty Federation אשר פורסם ב 2002 ו Liberty Web Services אשר פורסם ב טכנולוגית CardSpace מנגנון ]22[, CardSpace אשר כונה בתחילה,InfoCard הינו טכנולוגיה חדשה של חברת מיקרוסופט באמצעותה ניתן לממש מנגנון ניהול זהויות המבוסס על הסטנדרט ]1[. SAML טכנולוגיה זו הינה קבוצת רכיבים אשר נוספו לגרסת 3.0 של סביבת ה -.Net של מיקרוסופט, המאפשרים מימוש אינטראקציה בין שלוש הישויות אשר תוארו בעבודתי זו, ואשר מתוארים באיור 11 : Client.1 )Assertion Provider אזי זהו ה SAML משתמשים ב )אם Identity Provider.2.3 Party )Service Provider( Relaying המחייב הזדהות באמצעות Token מסוים המייצג את זהותו של המשתמש. בניגוד למה שתואר בעבודתי זו לגבי מימוש הסטנדרט,SAML מנגנון CardSpace אינו מימוש מלא של SAML והוא מאפשר שימוש בסוג של Token התואם את המתואר ב ]1[, בנוסף לאוסף של tokens אחרים בהם הוא תומך, כגון: 509.X, certificates,user Name/Password 36

38 ה) Kerberos tickets ועוד. מאידך אינו משתמש במנגנוני ה Request/Response המוגדרים בסטנדרט. משתמש מסוים יכול לתפקד גם כ Provider Identity של עצמו, מה שבעצם קורה כאשר נרשמים באתר אינטרנט מסוים )לדוגמה, פותחים תיבת דואר ב hotmail או נרשמים כמשתמש אורח ב IEEE על מנת לצפות בקבוצה מצומצמת של המאמרים המפורסמים באתר(. : תהליך ההזדהות באמצעות CardSpace איור 19 מנגנון CardSpace משתמש בפרוטוקולי ה WS-* )כגון WS-Security אשר תואר בסעיף 3.1.3( למימוש האינטראקציה בין שלושת הישויות שתוארו קודם לכן. לדוגמה, על מנת שספק השירות Provider )Service יוכל לדרוש מהמשתמש הצגת security token מסוג סוים, המנגנון משתמש ב WS-SecurityPolicy המתאר כיצד לייצג דרישה זו בשפה סטנדרטית הניתנת לעיבוד באמצעות מחשב. איור ]22[, 19 מתאר את רצף האירועים המתרחשים בתהליך ההזדהות באמצעות מנגנון :CardSpace 37

39 אפליקציית ה Client "שואלת" את ספק השירות מהו ה token באמצעותו ניתן להזדהות מול השירות. ה Client בוחר את הזהות באמצעותה הוא מעוניין להזדהות, כל זאת בהתאם לדרישות השירות לגבי סוג ה -.token במקרה של,SAML Assertion כפי שיוצג בחלק המעשי של עבודתי זו, זהו בעצם בחירת ה Provider Assertion אשר יזהה את המשתמש. ה Client מבקש את ה token Security מה Provider.Identity בשלב האחרון המשתמש פונה לקבלת השירות כאשר ה token מצורף אל הבקשה. מערכת Shibboleth מערכת ]23[ Shibboleth הינה מנגנון המספק מענה לבעיית ריבוי הסיסמאות בסביבה מרובת ארגונים,)Federation( המבוסס על הסטנדרט.SAML מערכת זו נוסדה ע"י מספר מוסדות אקדמיים וגופי מחקר אשר היו מעורבים בפיתוח פרויקט ה Internet2 כ. 40 מוסדות אקדמיים היו מעורבים בפיתוחה של מערכת Shibboleth כאשר מטרתה ליצור מנגנון לניהול הזהויות בסביבת קבוצת הארגונים הנ"ל. כלומר,ליצור Federation המורכב מהארגונים הללו כאשר משתמש בארגון אחד יוכל לגשת בצורה מאובטחת אל משאבים השייכים לארגון אחר בקבוצה וכל זאת למרות שהוא אינו משתמש המוגדר בארגון זה. 6.3 סיכום סקר הספרות המצב הקיים אשר תואר בסקירת הספרות מציג באופן ברור וחד משמעי את הצורך בסטנדרטים כדוגמת SAML ו,XACML ובפיתוח מנגנוני אבטחה בסביבת קבוצות של ארגונים )המכונות.)Federations התפתחותה של רשת האינטרנט בעשור האחרון חייבה את יצירתם של מנגנונים לשיתוף מידע הקשור בזהויות והרשאות של משתמשים בין הארגונים השונים. המנגנונים הקיימים המזהים משתמשים באופן חד ערכי )בדומה לתעודת זהות( אינם מספקים ויש לפתח מנגנונים רחבים יותר אשר אנלוגיים לדרכון המונפק ע"י מדינה אחת ובאמצעותו אדם מזדהה במדינה אחרת. שילוב של הסטנדרטים SAML ו XACML אכן מספק מענה הולם לדרישה זו. ואולם מימושים של הסטנדרטים הללו נמצאים רק בתחילת הדרך, ונדרשת עבודת פיתוח מרובה של חברות התוכנה הגדולות ליצירת כלים לניהול משתמשים והרשאות על מנת להביא סטנדרטים אלו לידי מימוש הלכה למעשה. 38

40 ה) שיטות העבודה מימוש מנגנון מבוסס SAML ו XACML מטרת הפרויקט מטרתי בפרויקט זה הינה הצגת הסטנדרטים SAML ו XACML כמנגנונים המספקים מענה לעולם האינטרנט, המאפשר שיתופי פעולה בין ארגונים דרך הרשת. שיתופי פעולה מן הסוג הנ"ל הביאו להגדרתו של המושג.Federation החלק המעשי של הפרויקט מציג פיתוח מלא שלי )בטכנולוגית.Net של,Microsoft בשפת #C( של אוסף כלים המהווים מימוש של הסטנדרטים הנ"ל, ומשמשים לניהול הזהויות והרשאות הגישה לשירותים בקבוצה של ארגונים. אוסף הכלים אותם פיתחתי, מאפשר יצירת מערכת של "אמון הדדי" )Trust( בין הארגונים השונים בקבוצה. החלק המעשי מדגים כיצד ניתן, באמצעות,XACML להגדיר מדיניות אבטחה המבוססת על מאפיינים Security( )Attribute Based המהווה בעצם הרחבה למנגנונים מבוססי התפקידים Control(.)Role Based Access נראה כיצד ניתן להגדיר את מדיניות האבטחה של שירותים בהסתמך על סט של מאפיינים השייכים למשתמש ולא רק ע"פ התפקיד שלו בארגון. מערכת היחסים והאמון ההדדי בין הארגונים השונים ניתנת למימוש באמצעות השימוש במפתחות ציבוריים ופרטיים המחולקים בין הארגונים השונים ב -.Federation יצירת ה"אמון ההדדי" )Trust בין הארגונים השונים ב Federation הינו מחוץ לתחום של עבודתי זו, ולכן לא תטופל בחלק המעשי, ואולם היא ניתנת למימוש באמצעות מנגנוני PKI תוך שימוש בסטנדרט המכונה )XML Key Management Specification( XKMS,]11[.]12[ סטנדרט זה מפשט את תהליך חלוקת המפתחות הציבוריים בין הארגונים הנשענים על מנגנון PKI ליצירת האמון ההדדי. כמו כן החלק המעשי בפרויקט לא יטפל בהצפנת ההודעות המועברות בין הגורמים השונים ב Secure ( SSL שכן הצפנה כזו ניתנת למימוש באמצעות מנגנונים קיימים כגון,Federation,)Socket Layer או מימוש מנגנונים המבוססים על הסטנדרט WS-Security המתואר בפרק לסיכום, המטרה המרכזית של פרויקט זה היא להראות כיצד ניתן לספק, למנהלי המערכות בארגונים )ה - Administrators,)System סט של כלים למימוש Attribute Based Security בסביבת.Federation סט הכלים הנ"ל מבוסס SAML ו,XACML שכן סטנדרטים אלו מתאימים במיוחד לסביבת.Web Services הסעיפים הבאים יתארו את החלק המעשי אותו מימשתי כחלק מהעבודה המסכמת. חלק זה הינו מימוש של הסטנדרטים שתוארו בסקר הספרות SAML( ו )XACML ובפרט, מימוש התהליך שהוזכר באיור 14 באמצעות דיאגרמת ה-.DFD הסעיפים הבאים מתארים את האפיון והעיצוב ברמת על של הרכיבים הלוגיים המרכיבים את הפתרון ואותם פיתחתי ואציג כחלק מעבודה מסכמת זו. בסעיף זה אשתמש ב,UML ובפרט בדיאגרמת Use Cases על מנת לתאר את התהליכים הלוגיים השונים המרכיבים את הפתרון. 39

41 ה: באיור 20 מוצגים ה Cases Use השונים וכן המשתמשים השונים )שחקנים )Actors המרכיבים את המערכת כולה. בפרק זה אספק תיאור של כל אחד מן המרכיבים הללו. Cases Use השונים המרכיבים את המערכת איור 20 40

42 2.4 תיאור השחקנים השונים במערכת )Actors( Subject משתמש )Client( המעוניין להזדהות בפני ספק שירות כלשהו תיאור ה subject מייצג משתמש כלשהו בקבוצת הארגונים )ה )Federation המוגדר במאגר המשתמשים של הארגון )ה Provider )Assertion אליו הוא שייך, ומעוניין לקבל שירותים מספק שירותים אחר בקבוצה Provider( Service ארגון אחר ב -.)Federation זה האחרון אינו מכיר את המשתמש אולם הוא מכיר את הארגון אליו שייך משתמש זה וסומך עליו כי יבצע עבורו את פעולת ההזדהות אותו משתמש. אחריות )Responsibility( באחריותו של ה subject לספק ל provider service את הכרזת ה SAML אשר קיבל מה assertion provider אשר זיהה אותו. תפקיד )Role( תפקידו של ה subject במערכת לבקש שירותים מה provider.service בהנחה שבתהליך בקשת השירות סיפק ה subject את ה assertion המכיל פרטים על זהותו, ה service יעביר את פרטיו אל מנגנון ה XACML על מנת לבדוק האם רשאי ה subject לקבל את שירות זה. Assertions Provider Administrator מנהל המערכת בארגון בו מוגדר המשתמש תיאור שחקן זה מנהל את מאגר המשתמשים המוגדרים ב domain )בארגון( אותו הוא מנהל. כמו כן הוא מגדיר עבור ה domain אותו הוא מנהל את ה domains trusted )הארגונים ב Federation עליהם הארגון אותו הוא מנהל סומך(. אחריות )Responsibility( מנהל ה domain אחראי על הגדרת המשתמשים וצירוף SAML Assertion לכל משתמש במערכת. בעת הצירוף של Assertion למשתמש באחריותו לוודא כי משתמש זה יקבל אך ורק את המאפיינים )attributes( המתארים את משתמש זה. בנוסף מנהל ה domain אחראי על הגדרת.trusted domains באחריותו לוודא כי מתבצע רישום של trusted domain במערכת אך ורק ל domain עליו הוא סומך. תפקיד )Role( מנהל ה domain ממלא אחר התפקידים הבאים: 41 הגדרת משתמשים. מתן הכרזות )assertions( למשתמשים. הגדרת.trusted domains

43 Service Administrator מנהל המערכת בצד השירות תיאור ה Administrator Service מנהל את מערך ההרשאות ומדיניות אבטחת המידע של השירותים אשר ארגונו חושף ברשת. אחריות )Responsibility( באחריותו לוודא כי כל השירותים המסופקים ע"י מערכות המידע בארגון אותן הוא מנהל מוגנים ע"י ה Policies המתאימים. תפקיד )Role( ה Administrator Service ממלא אחר התפקידים הבאים: הגדרת חוקים המגדירים את מדיניות אבטחת המידע בשירות אותו הוא מנהל. כלומר בניית Policies והגדרת המאפיינים הנדרשים לעמידה ב Policies אלו. לדוגמה: מנהל השירות יכול להגדיר Policy הדורש כי רק בעלי חשבון עסקי ממלאים אחר Policy זה. צירוף חוקים )Policies( לשירותים. לדוגמה: אם בסעיף הקודם מנהל השירות הגדיר Policy האומר כי רק משתמש בעל חשבון עסקי ממלא אחר Policy זה, הרי שבשלב זה מנהל השירות יבצע קישור של ה Policy לשירות מסוים. אם לדוגמה, השירות הוא שירות לקניית מניות בבורסה, אזי רק בעלי חשבון עסקי רשאים להשתמש בשירות זה. 3.4 תיאור ה Cases Use השונים במערכת Domain Administration מטרה ניהול המשתמשים והגדרת השותפים העסקיים של הארגון. תיאור ניהול המשתמשים השונים המוגדרים ומוכרים ע"י ארגון זה, וכמו כן ניהול הארגונים המהווים שותפים עסקיים לארגון זה )הגדרת.)trusted domains תהליך ניהול המשתמשים כולל את הגדרת המשתמשים במערכת וכן יצירה ועדכון של הכרזות SAML עבור משתמשים אלו. בתהליך הגדרת השותפים העסקיים domains(.)trusted מנהל המערכת יקבל סוג מסוים של מידע המייצג את השותף העסקי )כגון המפתח הציבורי שלו( על מנת לבצע תהליך של חתימה דיגיטאלית ביניהם. שחקנים המשתתפים בתהליך ה - Administrator Assertions Provider )מנהל מערכות המידע בארגון בו מוגדר המשתמש(. תנאי מקדים לתחילת התהליך )Pre-condition( מנהל ה domain מעוניין לבצע אחת מבין שלושת הפעולות הבאות: 42 הגדרת משתמש חדש.

44 הגדרת trusted domain חדש. מתן הכרזה למשתמש. מצב המערכת בסיום התהליך )Post-condition( בסיום התהליך המערכת נמצאת באחד מבין שלושת המצבים הבאים: נוסף משתמש חדש במערכת. נוסף domain חדש עליו הארגון הנוכחי סומך. הוגדרה הכרזת SAML עבור משתמש קיים במערכת. Users Declaration מטרה הגדרת משתמשים בארגון. תיאור תהליך הגדרת משתמשים חדשים ועדכון הפרטים של משתמשים קיימים מהווה הרחבה של תהליך ניהול ה.domain באמצעות תהליך זה יוגדרו משתמשים חדשים במאגר המשתמשים של הארגון. שחקנים המשתתפים בתהליך ה - Administrator Assertions Provider )מנהל מערכות המידע בארגון בו מוגדר המשתמש(. תנאי מקדים לתחילת התהליך )Pre-condition( מנהל המערכת מעוניין להגדיר משתמש חדש במערכת. המשתמש אותו מנהל ה domain מעוניין להזין אינו קיים במערכת. מצב המערכת בסיום התהליך )Post-condition( נוסף משתמש חדש ל domain הנוכחי. Assertion Declaration מטרה הגדרת הכרזות SAML למשתמשים. תיאור תהליך הגדרת הכרזות SAML למשתמשים ועדכון הפרטים בהכרזות קיימות של משתמשים קיימים מהווה הרחבה של תהליך ניהול ה.domain בתהליך זה מגדיר מנהל ה domain את הפרטים המאפיינים את המשתמש בהתאם ללוגיקה העסקית ולמדיניות אבטחת המידע בארגון המשתמש בכלי זה. למשל איגוד של כמה בנקים המעוניינים לבצע אינטגראציה ביניהם יהיה מעוניין לסמן את כל הלקוחות "העסקיים" בכל אחד מהבנקים כך שלקוח של בנק א' המעוניין לקבל שירות מבנק ב' יוכל להציג הכרזה שהוגדרה עבורו בבנק א' המעידה על כך שהוא לקוח עסקי בבנק זה. 43

45 שחקנים המשתתפים בתהליך ה - Administrator Assertions Provider )מנהל מערכות המידע בארגון בו מוגדר המשתמש(. תנאי מקדים לתחילת התהליך )Pre-condition( מנהל המערכת מעוניין להגדיר הכרזת SAML למשתמש במערכת. המשתמש קיים במערכת. מצב המערכת בסיום התהליך )Post-condition( עבור משתמש קיים במערכת הוגדרה הכרזת SAML חדשה או לחילופין עודכנו פרטיה של הכרזת SAML קיימת. Trusted Domains Declaration מטרה הגדרת שותפים עסקיים לארגון. תיאור תהליך הגדרת שותפים עסקיים חדשים ועדכון הפרטים של שותפים עסקיים קיימים מהווה הרחבה של תהליך ניהול ה.domain בתהליך זה מגדיר מנהל המערכת בארגון trust בין הארגון אותו הוא מנהל לבין שותף עסקי מסוים. הגדרת ה trust מהווה סוג מסוים של הסכמה לכך שהמשתמשים של בארגון הנוכחי יכולים לקבל שירותים ממערכות המידע של אותו שותף עסקי. שחקנים המשתתפים בתהליך ה - Administrator Assertions Provider )מנהל מערכות המידע בארגון בו מוגדר המשתמש(. תנאי מקדים לתחילת התהליך )Pre-condition( מנהל המערכת מעוניין להגדיר שותף עסקי חדש לארגון. השותף העסקי החדש אינו קיים במערכת. מצב המערכת בסיום התהליך )Post-condition( הוגדר שותף עסקי חדש לארגון. 44 Assertion Request Handler מטרה מימוש תהליך ההזדהות באמצעותו מזדהה הלקוח מול ה Provider Assertion של הארגון אליו הוא שייך. תיאור תהליך ההזדהות יתבצע באמצעות User Name/Password אותם ישלח הלקוח אל ה Assertion Provider ובתמורה )בהנחה שההזדהות הצליחה( יקבל הכרזת SAML מסוג.Attribute Assertion שחקנים המשתתפים בתהליך.)Subject - הלקוח )ה

46 ה - Administrator Assertions Provider )מנהל מערכות המידע בארגון בו מוגדר המשתמש(. תנאי מקדים לתחילת התהליך )Pre-condition(.Attribute Assertion להזדהות וקבלת Assertion Provider הלקוח ביצע פנייה אל ה על מנת שהתהליך יסתיים בהצלחה הלקוח חייב להיות מוגדר במאגר המשתמשים של ה.Assertion Provider מצב המערכת בסיום התהליך )Post-condition( ה Subject מחזיק ב Assertion Attribute השייך לו והמכיל את סט המאפיינים המתארים אותו. Service Request Handler מטרה בדיקת קיום הכרזת ה SAML בכותרת הבקשה לשירות, ושליפת המאפיינים המתארים את המשתמש. תיאור טיפול בבקשה לשירות מתחיל בחילוץ הכרזת ה SAML מהבקשה לשירות. תהליך זה שולף מכותרת הבקשה )ה )Header את ההכרזה וממנה את סט המאפיינים המתארים את המשתמש במטרה להעביר אותם, ואת מזהה השירות המבוקש, אל מנגנון ניהול ההרשאות. זה האחרון יחזיר תשובה בדבר הרשאת הגישה של המשתמש הנוכחי לגישה לשירות. ה case Use הנוכחי יחליט, בהתאם לתשובה שהגיעה ממנגנון ניהול ההרשאות, האם להעביר את הבקשה אל השירות המבוקש או לשלוח הודעת Access Denied אל מבקש השירות. שחקנים המשתתפים בתהליך ה Subject )מבקש השירות( תנאי מקדים לתחילת התהליך )Pre-condition( ה Subject יזם פנייה לבקשה לשירות. מצב המערכת בסיום התהליך )Post-condition( המשתמש קיבל את השירות המבוקש )או לא( בהתאם להחלטת מנגנון ניהול ההרשאות. XACML Policies Enforcement מטרה מימוש תהליך בדיקת הרשאה )ה -.)Authorization תיאור תהליך בדיקת ההרשאה מבוסס על הסטנדרט של ]2[, XACML על פיו התהליך מחולק לשלושה חלקים מרכזיים: 1. ה PEP מהווה את שער הכניסה אל מנגנון ה.XACML 45

47 .2.3 ה PDP מבצע את הבדיקה הלכה למעשה על בסיס מאפייני המשתמש המבקש את השירות ובדיקתם אל מול ה Policies המוגדרים על השירות המבוקש. ה PRP אחראי לשליפת ה Policies המוגדרים על השירות המבוקש שחקנים המשתתפים בתהליך תהליך זה מופעל בעקבות פנייה המתקבלת מתהליך ה Handler Service Request ולא כתוצאה ישירה של פנייה משחקן כלשהו במערכת. תנאי מקדים לתחילת התהליך )Pre-condition( ה Handler Service Request אכן הצליח לחלץ Attribute Assertion מכותרת הבקשה לשירות. מצב המערכת בסיום התהליך )Post-condition( התקבלה החלטה בדבר מתן האפשרות לגישה לשירות עבור המשתמש הנוכחי Access Rules Administration מטרה ניהול הרשאות הגישה לשירותים בארגון. תיאור.1.2 תהליך ניהול הרשאות הגישה לשירותים מתחלק לשני חלקים עיקריים: הגדרת מדיניות אבטחה באמצעות יצירת.Policies צירוף ה Policies לשירותים שונים בארגון. שחקנים המשתתפים בתהליך מנהל המערכת בארגון המספק את השירות )ה Administrator.)Service תנאי מקדים לתחילת התהליך )Pre-condition( מנהל המערכת בוחר להגדיר Policy חדש במערכת ו/או לצרף Policy לשירות קיים בארגון. מצב המערכת בסיום התהליך )Post-condition( הוגדר Policy חדש במערכת. צורף Policy לשירות קיים בארגון. Policies Declaration מטרה תהליך הגדרת מדיניות האבטחה ובפרט אוסף של חוקים המגדירים.Security Policy תיאור בתהליך זה מנהל המערכת מגדיר את האובייקטים השייכים לעולם הבעיה של מנגנון המבוסס Policy-Set : XACML המהווה קבוצה של,Policies אשר מהווים אוסף של Rules )חוקים(. האובייקט Policy-Set בעצם מגדיר את הפרופיל בו אמור משתמש לעמוד על מנת להתאים למדיניות האבטחה שהוגדרה ב.Policy-Set 46

48 שחקנים המשתתפים בתהליך מנהל המערכת Administrator( )System בארגון המספק את השירות. תנאי מקדים לתחילת התהליך )Pre-condition( אין מצב המערכת בסיום התהליך )Post-condition( הוגדר Policy-Set חדש במערכת Policies Attachment מטרה תהליך צירוף חוקים לשירותים. תיאור בתהליך זה קובע מנהל המערכת, עבור שירות מסוים, כי משתמש המעוניין לקבל שירות זה חייב לעמוד בדרישות מדיניות אבטחה מסוימים, המוגדרים ב Policy-Set שצורף לשירות. שחקנים המשתתפים בתהליך מנהל המערכת Administrator( )System בארגון המספק את השירות. תנאי מקדים לתחילת התהליך )Pre-condition( מדיניות האבטחה אותה אנו מעוניינים לצרף לשירות מוגדרת במערכת. מצב המערכת בסיום התהליך )Post-condition( צורף Policy-Set לשירות אחד או יותר מבין אוסף השירותים הרלוונטיים אותם מספק הארגון. 47

49 4.4 ארכיטקטורה החלק המעשי בפרויקט מורכב מחבילות התוכנה המתוארות באיור. 21 הרכיבים המסומנים בצהוב מייצגים אפליקציה ספציפית )שרת ולקוח( אותה בניתי לשם הדגמת המימוש של התקנים, SAML ו,XACML ואינם חלק מהכלי התשתיתי אותו בניתי בפרויקט זה. הרכיבים המסומנים בצבע חום מייצגים את חבילות התוכנה לניהול הזהויות המממשות את התקן.SAML הרכיבים המסומנים בירוק בהיר מייצגים את חבילות התוכנה לניהול ההרשאות הממשות את התקן XACML )והמממשות את התהליך אשר תואר באיור (. 14 שני הרכיבים הצבועים בירוק זית מייצגים חבילות תוכנה תשתיתיות אשר פתחתי ושימשו אותי לאורך כל הפרויקט )כגון תשתיות ממשק משתמש, וגישה אל מאגר נתונים הממומש כקובץ.)XML חשוב לציין כי עקרונית אין בעיה לקחת את החבילה לניהול הזהויות )המבוססת על )SAML ולחבר אליה חבילה אחרת לניהול הרשאות גישה. כלומר שני המימושים של שני התקנים, SAML ו,XACML אינם תלויים האחד בשני, שכן שני התקנים הללו בלתי תלויים אחד בשני. איור : 21 חבילות התוכנה המרכיבות את החלק המעשי בפרויקט 48

50 י- ה) המערכת מורכבת משלושה כלים מרכזיים בעלי ממשק משתמש דומה: הגדרת משתמשים והכרזות השייכים ל.Assertion Provider הגדרת ה Providers Assertion )בצד המשתמש( המזהים את המשתמש..)PAP Service Provider בצד ה XACML Policies הגדרת איור 22 מציג דוגמה של הממשק להגדרת משתמשים בצד ה Provider.Assertion ניתן לראות כי החלון מורכב משלושה חלקים מרכזיים, מהם מורכבים גם שני הכלים האחרים שיתוארו בהמשך: ה Browser Object שתפקידו להציג את כל האובייקטים המוגדרים כעת במאגר הנתונים ומנוהלים ע"י הכלי הנוכחי )משתמשים, הכרזות, Rules,Policies וכדומה(. ה Desktop )שולחן העבודה( באמצעותו מטפלים באובייקט בודד במערכת )לדוגמה, הגדרת משתמש או Policy חדש במערכת(. XML Viewer מציג את הייצוג ה XML -י של האובייקט המוצג כעת בשולחן העבודה. מטרתו של רכיב זה בממשק המשתמש היא להראות כיצד הכלים מטפלים בתקנים עליהם הם מבוססים SAML( או.)XACML חשוב לציין כי בכלי "אמיתי", למנהלי מערכות, אין צורך בהצגת המידע ה XML, וכי והוא מוסתר מהמשתמש. מטרת הכלים הללו הינה ליצור אבסטרקציה )הפשטה( של התקנים הללו. : ממשק המשתמש להגדרת משתמש חדש בצד ה - Provider Assertion איור 22 49

51 איור 23 מציג את השלב הראשון בהגדרת הכרזה למשתמש שהוגדר במערכת באיור. 22 בשלב הראשון מוגדרים אוסף של פריטי מידע השייכים להכרזה, כגון: מיהו ה,issuer ממתי ההכרזה תקיפה וכדומה. : ממשק המשתמש להגדרת הכרזת מאפיינים )שלב ראשון( איור 23 איור 24, המוצג בעמוד הבא, מציג את השלב השני בהגדרת הכרזת ה.SAML בשלב זה מנהל המערכת בארגון )ה Provider )Assertion מגדיר מהם המאפיינים השייכים למשתמש זה. בדוגמה זו ניתן ליראות כי זהו משתמש מסוג "לקוח זהב" וכי מסגרת האשראי שווה ל 50,000. באמצעות המאפיינים הללו ניתן לבצע בהמשך תהליך של Authorization בצד השירות. 50

52 איור 24 : ממשק המשתמש להגדרת הכרזת מאפיינים )שלב שני( לאחר שהמשתמש הוגדר בצד ה Provider Assertion יש לבצע הגדרה של ה Assertion Provider החדש בצד הלקוח. כל זאת על מנת שהמשתמש יוכל לבחור, בזמן אמת, את הישות באמצעותה הוא מעוניין להזדהות מתוך רשימת ה Providers Assertion "המכירים" אותו. איור 25 מציג את ממשק המשתמש לביצוע הגדרת Assertion Provider חדש בצד הלקוח. : ממשק המשתמש להגדרת ה - client - בצד ה Assertion Provider איור 25 51

53 עד כה ביצענו את כל ההגדרות הקשורות בהכרזת ה,SAML כל זאת על מנת לאפשר למשתמש להציג את הכרזת ה SAML השייכת לו בפני שירותים ברשת. על מנת ששירות מסוים יוכל להשתמש בהכרזת ה SAML שהתקבלה בעת הבקשה לשירות יש להגדיר מערך של Policies המגדירים את מדיניות האבטחה של השירות. איור 26 מציג את ממשק המשתמש להגדרת Policy-Set על שירות מסוים. : ממשק המשתמש להגדרת XACML Policies איור 26 איור 27 מתאר דיאגרמה של המחלקות המהוות תשתית לכל אחד מהכלים מן הסוג שהוצג באיור 22 עד איור. 26 ניתן לזהות את שלושת המחלקות המסומנות בצהוב הממשות את שלושת הרכיבים המרכזיים בממשק המשתמש. המחלקה המסומנת בצבע ירוק הינה החלון הראשי עליו מוצגים שלושת הרכיבים, והיא מהווה גורם מקשר )סוג של )Mediator בין שלושת הרכיבים הנ"ל. לדוגמה, כאשר מתעדכן שולחן העבודה )המשתמש מזין מידע חדש( הוא מודיע ל Mediator באמצעות אירוע )event( כי בוצע עליו עדכון ושולח לו את הייצוג ה XML -י החדש. ה Mediator מעביר את הייצוג החדש אל ה Viewer XML אשר יודע כיצד להציג אותו. שולחן העבודה, וה Browser Objects המוצגים כאן הינם מימושים תשתיתיים, ובכל כלי ספציפי ממשים מחלקות היורשות מהמחלקות הללו. ולכן קיים הצורך ב Factory המייצר את המופעים הספציפיים, כל זאת בהתאם לפעולה שנבחרה )יצירת חדש, צפייה באובייקט קיים וכדומה(. 52

54 איור : 27 המחלקות הממשות את התשתית לשלושת הכלים המרכזיים 53