בכנס SharePoint Extreme האחרון העברתי מצגת על Claims Based Authentication עם SharePoint 2010.
מכיוון שזהו נושא חדש יחסית, המצגת התמקדה בעיקר בהיכרות עם מה זה בכלל Claims Based Authenticatoin, ואיך זה עובד.
לאחר המצגת קיבלתי שאלות בנוגע לתהליך הטכני. פוסט זה בא להבהיר את התהליך.
התהליך שהצגתי הוא כזה:
-
משתמש ניגש לשרת SP
-
המשתמש מופנה ל STS
-
STS מאמת את המשתמש
-
STS מחזיר למשתמש Token
-
המשתמש ניגש אל ה SP, הפעם עם ה Token
-
SP מאשר את ה Token ומאפשר גישה
השאלה העיקרית הייתה בנוגע לשימוש ב Cookies, ואיך כל זה עובד עם מגבלות כמו Cross-Domain.
הדרך שבה זה עובד בצורה טכנית היא כזו (מספרי השורות תואמים לשלבים שתוארו מקודם):
-
משתמש מבצע HTTP GET ל SP
-
SP מחזיר 302 Redirect. בסופו של דבר המשתמש מופנה אל הכתובת של ה STS (בד”כ סדרה של הפניות)
-
הדפדפן ניגש אל ה STS, המשתמש מאומת באמצעות דף ה Login
-
ה STS מחזיר למשתמש דף שמכיל את ה Token (בגוף הדף, בד”כ כ hidden field),
-
באותו דף ישנו קוד Javascript שגורם לדפדפן לעשות HTTP POST אל ה SP, עם ה Token.
-
SP מקבל את הבקשה ויודע לנתח אותה בהתאם
אם כן, השאלה הבאה היא איך Cookies נכנסים לתמונה?
ה STS, או ה SP יכולים להשתמש ב cookies (או באיזו טכנולוגיה שהם רוצים) כדי לשמר session עם המשתמש.
כלומר, כדי שתהליך ההזדהות לא יקרה בכל פעם, ה SP מנפיק למשתמש cookie שמשאיר אותו מזוהה במהלך השימוש שלו באתר (ע”ע FedAuth).
באותה מידה ה STS יכול להנפיק למשתמש cookie כדי לזהות בצורה אוטומאטית את המשתמש אם הגיעה בקשה נוספת להזדהות.