חושפים את אבטחת Salesforce: הדקויות של הגדרת SAML ושל תהליך הכניסה היחידה
בעולם של Salesforce, הבנת המנגנונים של אבטחה וזהות עם כניסה יחידה (SSO) יכולה להיות חשובה. בואו נצלול לאופן שבו Salesforce פועלת כשהיא ספק שירות תחת ספק זהויות חיצוני (IDP), ונדגיש את ההגדרות והתהליכים המרכזיים.
פירוט ההגדרות:
התפקיד המרכזי של הדפדפן: באקוסיסטם הטכנולוגי המשולב שלנו, הדפדפן הוא לא סתם צופה; הוא מתווך פעיל, שמאפשר תקשורת מאובטחת בין ספק הזהויות ל-Salesforce, ספק השירות.
ניווט בדיאלוגים של SAML: שיטת התקשורת של כניסה יחידה סובבת סביב שליחת בקשות SAML לספקי זהויות. בתמורה, היא מצפה לטענות ה-SAML שלהם, שהן בעצם “הוכחות” דיגיטליות לאימות.
אמון דרך תעודה דיגיטלית: כדי להבטיח אינטראקציות מאובטחות ואמינות, Salesforce וספק הזהויות מחליפים תעודה דיגיטלית. לחיצת היד האלקטרונית הזו היא הבסיס ליחסים המאובטחים ביניהם.
הגדרה צעד אחר צעד:
[caption id="" align=“alignnone” width=“1780”]
הגדרת SAML [/caption]
במגרש של ספק הזהויות: ההגדרות כוללות הקמת האפליקציה המחוברת, קביעת הפרטים של התעודה הדיגיטלית, והזנת נתיבי ה-URL Redirect אל ספק השירות.
בתחום של Salesforce: השלבים נעים מוידוא ש-‘My Domain’ מוגדר והפעלת SAML, ועד השלב הקריטי של העלאת התעודה של ספק הזהויות. בנוסף, הגדרת הפניות חזרה לספק הזהויות הופכת לחיונית.
זהות המשתמש דרך Federation ID: Salesforce מזהה באופן ייחודי משתמשים מספק הזהויות דרך Federation ID. חשבו עליו כעל תגית מיוחדת, כמו מספר עובד או מזהה ייחודי אחר, שעוזרת לזהות את המשתמש בצורה חלקה.
צלילה לתהליך הכניסה היחידה:
[caption id="" align=“alignnone” width=“1780”]
תהליך התחברות שיוזם ספק השירות (SP Initiated) [/caption]
1a/1b הגישה הראשונית של המשתמש: כשהיום מתחיל, משתמשים עשויים לנסות לגשת למשאב מאובטח ב-Salesforce. אם הם לא מחוברים, Salesforce מזהה זאת ומוציאה פקודת הפניה.
2a המסע לספק הזהויות: Salesforce מנתבת את המשתמש מחדש לספק הזהויות שלו. כאן מתחיל המסע האמיתי: ממסכי התחברות מסורתיים ועד שיטות מתקדמות יותר כמו אימות רב-שלבי.
2b חותמת האישור של ספק הזהויות: אחרי שזהות המשתמש אומתה, ספק הזהויות מנסח טענת SAML ושולח אותה ל-Salesforce, כשהוא ערב למשתמש.
3a/3b/4 הדלת המזמינה של Salesforce: כשהיא מקבלת את האישור של ספק הזהויות, Salesforce מבצעת אימות משלה, ואחריו פותחת סשן. מבחינת המשתמשים, החוויה מרגישה חלקה: הם לוחצים על קישור של Salesforce, עוברים אימות, והופ, הם מופנים לדף ה-Salesforce שלהם.
לסיכום
יצירת חוויה חלקה היא היבט מרכזי בריקוד הזה של התהליך שיוזם ספק השירות (Service Provider Initiated Flow). כאן, משתמשים שהולכים ישירות ל-Salesforce עוברים עיקוף קצר: הם מלווים לאימות, ואחרי האימות מנווטים בחזרה ל-Salesforce בצורה חלקה.
המשחק ההרמוני הזה בין Salesforce, ספקי הזהויות והדפדפנים של המשתמשים אולי נראה מורכב, אבל הוא מתוכנן לאזן בין אמצעי האבטחה לבין גישה מהירה של המשתמשים.
שימו עין, כי נצלול עמוק יותר להיבטים מתמחים במאמרים הבאים, כמו העולם המסקרן של קישורים עמוקים (deep links) ו-relay states. ולמי שאוהבים הדגמות מעשיות, אני מכין סרטונים מפורטים שמדגימים הגדרות בתוך סביבות של ארגוני Salesforce.
לתוכן מרתק כזה ועוד, הירשמו לערוץ ה-YouTube @SteveTecharc. בואו ננווט יחד במבוך של אבטחת Salesforce!
הישארו איתנו
צאו לדרך עם Salesforce Identity בביטחון! לתובנות ולטיפים נוספים, הישארו איתנו כאן ב-www.SteveTechArc.com ובערוץ ה-YouTube @SteveTechArc (opens in a new tab). הירשמו והעמיקו את ההבנה שלכם ב-Salesforce Identity.
עוזרים לשנות את העולם בשיתוף מידע על אינטגרציה עם עמיתים ארכיטקטים ועם מי שנמצאים במסע שלהם לארכיטקטורה!
תישארו סקרנים, תישארו מאובטחים!
STA 3.4