הגדרת כניסה יחידה (SSO) עבור הצוות שלך - (אפליקציית האינטרנט של הצוות)

מה SSO עושה

כניסה יחידה מאפשרת לחברי הצוות שלך להיכנס באמצעות ספק הזהויות של החברה שלך, כגון Okta, Microsoft Entra ID (Azure AD), Google Workspace או Auth0. את/ה מגדיר/ה אותה בדף SSO. רק בעלים ומנהלים יכולים לפתוח אותו. כותרת הדף היא Single Sign-On (SSO).

בדף יש שלוש לשוניות: Email Domains, OIDC ו-SAML 2.0. אפשר לבחור ב-OIDC או ב-SAML 2.0, לא בשניהם בו-זמנית.

צעד 1: הוספה ואימות של דומיין אימייל

פתיחה של הלשונית Email Domains. SSO מתחיל בהוכחה שאת/ה הבעלים של דומיין האימייל של החברה שלך. אימות הדומיין משותף ל-SAML ול-OIDC, ולכן צריך לאמת פעם אחת בלבד.

1. תחת Add Email Domain, הקלד/י את הדומיין שלך (לדוגמה, example.com) ולחץ/י על Add Domain.
2. הדומיין מוצג כ-Pending Verification. לחיצה על How to Verify פותחת את השלבים.
3. בחר/י שיטה אחת: - DNS TXT Record: הוסף/י רשומת TXT ל-DNS של הדומיין שלך עם הערך המוצג. שינויי DNS עשויים לקחת עד 48 שעות. - File Upload: מקם/י קובץ טקסט עם קוד האימות בכתובת https://yourdomain/.well-known/scribblemaps-verify.txt. הקובץ חייב להיות נגיש דרך HTTPS.
4. לחץ/י על Verify Now. כשהפעולה מצליחה, הדף מציג "Domain verified successfully!" והדומיין מסומן Verified.

אם אי אפשר לאמת באמצעות DNS או קובץ, שלח/י אימייל אל [email protected] והצוות יוכל לאמת את הדומיין שלך ידנית.

צעד 2 (אפשרות א'): הגדרת OIDC

פתיחה של הלשונית OIDC.

1. העתקה של Redirect URI / Callback URL המוצג תחת Callback URLs. את הכתובת הזו מוסרים לספק הזהויות שלך בעת יצירת האפליקציה.
2. ב-Quick Setup אפשר להדביק את כתובת ה-discovery של הספק שלך (כתובת ה-.well-known/openid-configuration) וללחוץ על ייבוא כדי למלא אוטומטית את ה-Authority ואת סוג הספק.
3. מילוי של השדות הנדרשים תחת Provider Settings: - Provider Type - Client ID - Client Secret - Authority / Issuer URL
4. פתיחה של User Settings כדי להפעיל את Just-In-Time (JIT) Provisioning, שיוצר חשבון משתמש בפעם הראשונה שמישהו נכנס באמצעות OIDC.
5. פתיחה של Security Settings כדי להפעיל את Require Multi-Factor Authentication (MFA) אם רוצים לאשר MFA לפני הכניסה.
6. לחיצה על שמירת הגדרות, ואז על Test Connection. אפשר גם להשתמש ב-Test SSO Login כדי לנסות את הכניסה המלאה בחלון חדש.
7. הפעלה של המתג OIDC SSO enabled.

כשיוצרים את האפליקציה בספק הזהויות שלך, יש לבחור ב-Web Application כסוג (ולא SPA או Native), מפני ש-Client Secret הוא שדה חובה.

צעד 2 (אפשרות ב'): הגדרת SAML 2.0

פתיחה של הלשונית SAML 2.0.

1. העתקה של Service Provider (SP) Information כדי למסור לספק הזהויות שלך: SP Entity ID / Audience URI, Single Sign-On URL / ACS URL ו-SP Metadata URL.
2. ב-Quick Setup, בחר/י את הספק שלך וייבא/י את כתובת ה-metadata שלו כדי למלא אוטומטית את ההגדרות.
3. מילוי של Identity Provider (IdP) Settings: - IdP Entity ID (Issuer) - IdP Single Sign-On URL - IdP Single Logout URL (אופציונלי) - IdP X.509 Certificate בפורמט PEM
4. פתיחה של Advanced Settings כדי להגדיר את Signature Algorithm (מומלץ SHA-256) ואת NameID Format.
5. פתיחה של User Settings כדי להפעיל את Just-In-Time (JIT) Provisioning.
6. לחיצה על שמירת הגדרות, ואז על Test Connection. השתמש/י ב-Test SSO Login כדי לנסות את הכניסה המלאה.
7. הפעלה של המתג SAML SSO enabled.

פרוטוקול אחד בכל פעם

אפשר להפעיל רק OIDC או SAML, לא את שניהם. אם מפעילים אחד בזמן שהאחר כבר מופעל, הדף שואל אם ברצונך להשבית קודם את האחר. לדוגמה, הפעלת OIDC כאשר SAML פועל מציגה "SAML is currently enabled. Would you like to disable it?" עם האפשרויות Disable SAML ו-השארה שניהם.

צפייה במשתמשי ה-SSO שלך

בהמשך הדף, הכרטיס SSO Provisioned Users מציג רשימה של אנשים שנוצרו באמצעות SSO. לחיצה על הצגה פותחת את הרשימה, ולחיצה על הסתרה סוגרת אותה. הטבלה מציגה לכל משתמש את האימייל, השם, תאריך היצירה והכניסה האחרונה. כל עוד איש לא נכנס בדרך הזו, מופיע "No users have been provisioned via SSO yet."