Follow Up on My SharePoint Extreme Session on Claims Based Authentication

22 במרץ 2012

אין תגובות

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

התהליך שהצגתי הוא כזה:

  1. משתמש ניגש לשרת SP
  2. המשתמש מופנה ל STS
  3. STS מאמת את המשתמש
  4. STS מחזיר למשתמש Token
  5. המשתמש ניגש אל ה SP, הפעם עם ה Token
  6. SP מאשר את ה Token ומאפשר גישה

השאלה העיקרית הייתה בנוגע לשימוש ב Cookies, ואיך כל זה עובד עם מגבלות כמו Cross-Domain.

הדרך שבה זה עובד בצורה טכנית היא כזו (מספרי השורות תואמים לשלבים שתוארו מקודם):

  1. משתמש מבצע HTTP GET ל SP
  2. SP מחזיר 302 Redirect. בסופו של דבר המשתמש מופנה אל הכתובת של ה STS (בד”כ סדרה של הפניות)
  3. הדפדפן ניגש אל ה STS, המשתמש מאומת באמצעות דף ה Login
  4. ה STS מחזיר למשתמש דף שמכיל את ה Token (בגוף הדף, בד”כ כ hidden field),
  5. באותו דף ישנו קוד Javascript שגורם לדפדפן לעשות HTTP POST אל ה SP, עם ה Token.
  6. SP מקבל את הבקשה ויודע לנתח אותה בהתאם

אם כן, השאלה הבאה היא איך Cookies נכנסים לתמונה?

ה STS, או ה SP יכולים להשתמש ב cookies (או באיזו טכנולוגיה שהם רוצים) כדי לשמר session עם המשתמש.
כלומר, כדי שתהליך ההזדהות לא יקרה בכל פעם, ה SP מנפיק למשתמש cookie שמשאיר אותו מזוהה במהלך השימוש שלו באתר (ע”ע FedAuth).
באותה מידה ה STS יכול להנפיק למשתמש cookie כדי לזהות בצורה אוטומאטית את המשתמש אם הגיעה בקשה נוספת להזדהות.

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

כתיבת תגובה

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