צלילה עמוקה לאימות SAML
הבנת SAML בכניסה יחידה עם Salesforce
בתחום האימות, ל-SAML (Security Assertion Markup Language) יש תפקיד מרכזי בהבטחת גישה חלקה בין אפליקציות. בואו נצלול לעומק SAML, נבין את חשיבותו בכניסה יחידה (Single Sign-On, SSO), ונבחן את המימוש שלו עם Salesforce.
הגדרת ההקשר
דמיינו תרחיש שבו יש לכם שני ארגוני Salesforce (Orgs): ספק זהויות (IDP) וספק שירות (service provider). אצל ספק השירות נמצאים הנתונים שאתם רוצים לגשת אליהם, אבל במקום להשתמש בכמה סטים של פרטי גישה, אתם רוצים לעשות זאת עם סט אחד של פרטי התחברות. הרעיון נשמע פשוט, אבל המנגנונים מאחורי הקלעים יכולים להיות מורכבים.
מונחי מפתח בעולם ה-SAML
גישת המשתמש: כשמשתמש מנסה להגיע למשאב מאובטח אצל ספק השירות לפני שהתאמת.
הפניה: אם המשתמש לא מאומת, ספק השירות מפנה אותו לספק הזהויות באמצעות בקשת SAML. אם צריך, אפשר לשלוח לצידה relay state, כלומר את כתובת ה-URL שהמשתמש התכוון לבקר בה מלכתחילה.
אימות אצל ספק הזהויות: ספק הזהויות מאמת את זהות המשתמש, בדרך כלל באמצעות שם משתמש וסיסמה או אימות רב-שלבי.
טענת SAML: לאחר האימות, ספק הזהויות שולח טענת SAML לספק השירות.
האמון של ספק השירות: ספק השירות מאמת את טענת ה-SAML, מחלץ את פרטי המשתמש ומעניק גישה. אם נשלח relay state קודם לכן, ספק השירות מנווט לכתובת ה-URL הזו בדיוק.
היתרונות של כניסה יחידה
גישה פשוטה: משתמשים צריכים רק סט אחד של פרטי גישה כדי לגשת לשירותים רבים.
אבטחה: SAML משתמש בחתימות דיגיטליות כדי להבטיח את שלמות הנתונים ולמנוע שיבוש.
יכולת פעולה הדדית: כפרוטוקול סטנדרטי, SAML יכול לעבוד מול ספקי זהויות וספקי שירות שונים, על פני טכנולוגיות שונות.
לצלול עמוק יותר: בחינת תהליכי SAML
בקשת SAML: נשלחת מספק השירות לספק הזהויות, ומבקשת ממנו לאמת משתמש.
תגובת SAML: הודעה מספק הזהויות לאחר האימות, שכוללת פרטים על המשתמש.
טענות (Assertions): הצהרות של ספק הזהויות על המשתמש, שכוללות מאפיינים כמו שם המשתמש או כתובת הדוא”ל.
חתימות דיגיטליות: משמשות לאימות הטענות, כדי לוודא שהן לא שונו שלא כדין.
Relay State: כתובת URL של קישור עמוק שמבטיחה שאחרי האימות המשתמש יופנה חזרה ליעד שאליו התכוון מלכתחילה.
כשמשתמש מתחיל גישה, נשלחת בקשת SAML לספק הזהויות, וזה, אחרי אימות, מחזיר טענת SAML. כשספק השירות מאמת את הטענה הזו, המשתמש מקבל את הגישה המבוקשת.
בעזרת כלים כמו SAML Tracer לדפדפנים, אפשר לראות את התהליך הזה בעיניים. כך מקבלים מבט שקוף על תהליך האימות, מהבקשה הראשונה ועד ההפניה האחרונה אחרי האימות.
אמצעי אבטחה בטענות SAML
כדי להתמודד עם איומי אבטחה אפשריים:
חותמות זמן משמשות למניעת התקפות שידור חוזר (replay attacks), כך שטענת ה-SAML תקפה רק לחלון זמן קצר.
חתימות דיגיטליות מבטיחות שהנתונים לא שובשו במהלך ההחלפה.
בנוסף, טענות יכולות לכלול מאפייני משתמש, כמו כתובות דוא”ל או סוגי משתמשים, וכך לאפשר בקרות גישה מפורטות יותר בצד של ספק השירות.
סיכום
SAML, ביסודו, הוא פרוטוקול מבוסס XML שמכיל רכיבי מפתח לאימות. הוא אולי נראה כמו קסם, אבל הוא תוצאה של טכנולוגיה מחושבת היטב, שנועדה לסכל התקפות כמו “אדם בתווך” (man-in-the-middle) או תרחישי שידור חוזר.
היכולת שלו לחבר ספקי שירות רבים לספקי זהויות בטכנולוגיות שונות הופכת אותו לאבן יסוד בעולם האימות הדיגיטלי.
הישארו איתנו
צאו לדרך עם Salesforce Identity בביטחון! לתובנות ולטיפים נוספים, הישארו איתנו כאן ב-www.SteveTechArc.com ובערוץ ה-YouTube @SteveTechArc (opens in a new tab). הירשמו והעמיקו את ההבנה שלכם ב-Salesforce Identity.
עוזרים לשנות את העולם בשיתוף מידע על אינטגרציה עם עמיתים ארכיטקטים ועם מי שנמצאים במסע שלהם לארכיטקטורה!
STA 3.6