כל התחברות נפרדת היא עוד סיסמה לאיפוס ועוד חשבון לסגור כשמישהו עוזב. כניסה יחידה (SSO) ב-SAML מחברת את מערכת ניהול הלמידה שלכם לספק הזהויות שלכם, כך שאנשים נכנסים להדרכה עם חשבון העבודה שלהם והגישה עוקבת אחרי ספריית המשתמשים (directory) שלכם. הנה איך SAML עובד, איך נראית ההגדרה עם Microsoft Entra ID, Okta או Google Workspace, ומה לבדוק לפני העלייה לאוויר.
איך כניסה יחידה ב-SAML עובדת
SAML (Security Assertion Markup Language) 2.0 הוא תקן פתוח להעברת מידע על התחברות בין שתי מערכות שסומכות זו על זו. ה-LMS אף פעם לא רואה את הסיסמה של האדם: הוא שולח אותו לספק הזהויות שלכם, שבודק מי הוא, כולל כל אימות רב-שלבי (MFA) שאתם דורשים, ומחזיר אותו עם הצהרה חתומה.
| מונח | משמעות |
|---|---|
| ספק זהויות (IdP) | המערכת שמאמתת את האנשים שלכם, כמו Entra ID, Okta או Google Workspace. |
| ספק שירות (SP) | היישום שאליו אנשים מתחברים: ה-LMS שלכם. |
| הצהרה (Assertion) | הצהרת ה-XML החתומה מה-IdP: מי האדם, מתי התחבר, ומאפיינים כמו אימייל ושם. |
| Entity ID | שם ייחודי לכל צד, שלעיתים נראה כמו כתובת URL אבל הוא רק מזהה. הוא חייב להתאים בדיוק. |
| ACS URL | Assertion Consumer Service URL: כתובת ה-LMS שמקבלת את התגובה של ה-IdP. |
| אישור חתימה | ה-IdP חותם עם המפתח הפרטי שלו; ה-LMS מאמת באמצעות האישור הציבורי של ה-IdP ודוחה הצהרות מזויפות או ששונו. |
| מטא-נתונים (Metadata) | קובץ XML שאורז entity ID, נקודות קצה ואישורים, מוכן לייבוא. |
הצהרות הן קצרות מועד ומציינות את הקהל שלהן (ה-entity ID של ה-SP). ה-SP דוחה כל הצהרה שפג תוקפה או שנועדה ליישום אחר.
למה SSO משתלם ב-LMS
- בלי סיסמאות נוספות. אנשים משתמשים בחשבון היומיומי שלהם, ומדיניות ה-MFA והגישה שלכם חלה גם על ההדרכה.
- מצטרפים חדשים מקבלים גישה מהר. שייכו את יישום ה-LMS לקבוצה, ועובדים חדשים בה יכולים להתחבר כבר ביום הראשון.
- מי שעוזבים מאבדים גישה במקור. השביתו מישהו בספריית המשתמשים שלכם והוא לא יוכל להתחיל הפעלה חדשה ב-LMS. SAML שולט בהתחברות, לא בחשבון, ולכן העבירו לארכיון גם את חשבון ה-LMS כחלק מתהליך העזיבה.
יצירת חשבונות בזמן אמת (Just-in-time)
עם הקצאה בזמן אמת (just-in-time, או JIT), ה-LMS יוצר חשבון בפעם הראשונה שמישהו מתחבר, על סמך מאפייני ה-assertion, כך שאין רשימת משתמשים לייבא. הציבו לזה מעקות בטיחות:
- הגבילו אותה לדומייני האימייל שלכם, כדי שיישום שהוגדר לא נכון או חשבון אורח לא ייצרו משתמשים תועים.
- תנו לחשבונות חדשים את התפקיד הנמוך ביותר, והעניקו הרשאות מנהל במכוון.
- התאימו אנשים לפי מזהה יציב כשה-IdP שלכם יכול לשלוח כזה, כי כתובות אימייל משתנות.
התחברות ביוזמת SP מול ביוזמת IdP
- ביוזמת SP: האדם פותח את ה-LMS, שמעביר בקשת אימות ל-IdP, וה-IdP שולח (POST) את תגובתו ל-ACS URL. זה עובד מסימניות וקישורים באימייל, ונחשב בדרך כלל לזרימה הבטוחה יותר כי התגובה עונה על בקשה שה-LMS ביצע.
- ביוזמת IdP: האדם לוחץ על האריח של היישום ב-Microsoft My Apps, בלוח הבקרה של Okta שלו או בתפריט היישומים של Google, וה-IdP שולח תגובה שלא התבקשה ל-ACS URL.
אפשר להציע את שתיהן; בדקו כל אחת.
הגדרת SAML SSO שלב אחר שלב
הרצף דומה מאוד בכל מקום:
- תכננו את ההיקף: מי משתמש ב-SSO, אילו קבוצות מקבלות את היישום, אילו דומייני אימייל מותרים, ואיזה מאפיין מזהה כל אדם.
- צרו את החיבור ב-LMS ורשמו את ה-entity ID ואת ה-ACS URL שלו.
- צרו יישום SAML אצל ה-IdP שלכם עם הערכים האלה, בחרו את פורמט ה-NameID, והוסיפו מאפייני אימייל, שם פרטי ושם משפחה.
- שייכו משתמשים או קבוצות; אנשים שלא שויכו נדחים בדרך כלל.
- תנו ל-LMS את הפרטים של ה-IdP: כתובת מטא-נתונים, קובץ מטא-נתונים, או ה-entity ID של ה-IdP, כתובת ההתחברות ואישור החתימה.
- מפו את המאפיינים לשמות שה-IdP שלכם שולח בפועל.
- בדקו, ואז הפעילו, וספרו לאנשים מה משתנה.
הערות לפי ספק
בתיעוד של הספק שלכם יש את המסכים המדויקים. כדאי לדעת:
- Microsoft Entra ID: השתמשו ביישום ארגוני שאינו מהגלריה (non-gallery enterprise application), ולא ברישום אפליקציה (app registration), שאינו מציע SAML. שמות ה-claims הם URI ארוכים, ולכן העתיקו אותם בדיוק. ה-object ID הוא מזהה יציב טוב. לאנשים בלי תיבת דואר, ה-claim של האימייל עשוי להיות ריק; ה-user principal name יכול לשמש תחליף אם זו כתובת אמיתית.
- Okta: צרו אינטגרציית אפליקציה של SAML 2.0. את שמות ה-attribute statements אתם קובעים בעצמכם, ולכן הם חייבים להתאים בדיוק למיפוי ב-LMS, כולל אותיות גדולות וקטנות. מזהה המשתמש הפנימי של Okta הוא מזהה יציב.
- Google Workspace: הוסיפו אפליקציית SAML מותאמת אישית והורידו את קובץ המטא-נתונים שלה. האפליקציה מתחילה במצב כבוי, ולכן הפעילו אותה ליחידות הארגוניות או לקבוצות הנכונות. הגדרה טיפוסית מזהה אנשים לפי כתובת האימייל הראשית, ולכן תכננו מראש כתובות ששונה שמן או שנעשה בהן שימוש חוזר.
רשימת בדיקה
לפני העלייה לאוויר, בדקו את אלה בחלון גלישה פרטי:
- משתמש קיים מתחבר כשהוא מתחיל מה-LMS, ושוב מאריח היישום.
- משתמש חדש בדומיין שלכם מקבל חשבון עם התפקיד הנכון.
- מי שלא שויך ליישום נדחה.
- מי שמחוץ לדומיינים המותרים שלכם נדחה.
- אימייל, שם פרטי ושם משפחה מגיעים נכון.
- מנהל עדיין יכול להיכנס דרך מסלול השחזור.
מלכודות נפוצות
סטיית שעונים
אם ההפרש בין השעונים של ה-IdP ושל ה-LMS גדול ממה שה-LMS מוכן לסבול, הצהרות תקינות נדחות כמי שעדיין לא בתוקף או שכבר פג תוקפן. זה משפיע בעיקר על שרתי זהויות באירוח עצמי, ולכן שמרו על סנכרון השעונים שלהם.
חידוש אישורים
אישורי החתימה של ה-IdP פגים, ואם ה-LMS לא סומך על האישור החלופי, כל ההתחברויות נכשלות בבת אחת. רשמו ביומן את תאריך הפקיעה. אם ה-LMS שלכם יכול לסמוך על שני אישורים, הוסיפו שם קודם את החדש, ואז הפעילו אותו אצל ה-IdP; אחרת החליפו את שני הצדדים יחד בשעה שקטה. בדקו מיד.
מיפוי מאפיינים
שמות מאפיינים מותאמים בדרך כלל בדיוק: LMS שמצפה ל-email לא יקבל את Email. בדקו גם את המזהה. NameID חולף (transient) משתנה בכל הפעלה, וכתובת אימייל יכולה להשתנות; NameID קבוע (persistent) או מאפיין מזהה בלתי משתנה הם יציבים. אם אנשים מותאמים לפי אימייל, העבירו לארכיון את החשבון של מי שעזב לפני שהכתובת שלו מוקצית מחדש.
אי-התאמה בדומיין האימייל
בספריות משתמשים יש לעיתים קרובות אנשים ששם ההתחברות שלהם אינו כתובת האימייל שלהם, קבלנים בדומיינים אחרים, ועובדים של עסקים שנרכשו ועדיין בדומיינים הישנים. אם ה-LMS מגביל חשבונות לדומיינים מסוימים, הם נדחים. רשמו כל דומיין לפני העלייה לאוויר.
איך Acadenix עושה את זה
SAML SSO זמין במסלול Gold, עם מדריכים שלב אחר שלב ל-Entra ID, ל-Okta ול-Google Workspace.
- בדיקה ואז הפעלה. שומרים את פרטי ה-IdP כטיוטה, מריצים את Test configuration (בדיקת הגדרות) על ידי התחברות אצל הספק שלכם, ורק אז מפעילים. היעדר claim של אימייל מדווח יחד עם שמות ה-claims שהספק שלכם כן שלח.
- שינויים בשלבים. אישור חדש או tenant חדש נכנסים כעדכון הגדרות, וההגדרה הנוכחית ממשיכה לעבוד עד שמפעילים אותו.
- JIT בתוך הדומיינים שלכם. מי שאין לו חשבון מקבל חשבון לומד בהתחברות הראשונה, רק אם האימייל שלו נמצא בדומייני ההרשמה של הארגון שלכם, ואפשר לכבות זאת. כשמישהו שכבר יש לו חשבון ב-Acadenix מתחבר לראשונה דרך ה-IdP שלכם, Acadenix שולחת לו באימייל קוד חד-פעמי לאישור הקישור. זה קורה פעם אחת לכל אדם.
- שני מסלולי כניסה. אנשים מתחילים מדף ההתחברות שלכם, שיכול להעביר אותם ישר ל-IdP שלכם או להציג כפתור, או מהאריח ב-My Apps, ב-Okta או ב-Google.
- חיבור אחד, ארגון אחד. חיבור SAML לא עובר כלפי מטה לארגונים שמתחת לבעליו, וזה חשוב לקבוצות עם אתרים רבים.
- מסלול שחזור. אם ה-IdP שלכם לא זמין, מנהלים עדיין יכולים להתחבר עם קוד חד-פעמי שנשלח באימייל, ואי אפשר לכבות זאת.
לצד SAML, אנשים יכולים להתחבר עם קוד באימייל או עם חשבון Google, Microsoft או LinkedIn. עוד בדף האבטחה שלנו.
עיקרי הדברים
- החליפו entity ID, ACS URL ומטא-נתונים, ואז מפו מזהה יציב ואימייל מאומת.
- הגבילו חשבונות שנוצרים בזמן אמת לדומיינים שלכם ולתפקיד הנמוך ביותר.
- בדקו את שתי זרימות ההתחברות, את הדחיות ואת מסלול השחזור לפני העלייה לאוויר.
- רשמו ביומן את פקיעת האישורים והעבירו לארכיון את חשבונות ה-LMS של מי שעזבו.
רוצים לחבר את Acadenix לספק הזהויות שלכם? השוו מסלולים בדף המחירים שלנו, או דברו איתנו על ההגדרה שלכם.
