כניסה מאוחדת (SSO)

כניסה מאוחדת (SSO) מאפשרת למשתמשים להתחבר ל-Nodaro שלכם באירוח עצמי דרך ספק זהות חיצוני ומהימן. מתארים כל ספק במשתנה EXTERNAL_SSO_PROVIDERS, ודף ההתחברות מציג כפתור SSO. החשבון שהמשתמש מגיע אליו הוא משתמש רגיל בהתקנה שלכם: SSO הוא רק דרך להתחיל סשן. הדף הזה עוסק בצד של מנהל השרת; הפרוטוקול מתואר בדף התחברות חיצונית (SSO) למפתחים.

איזה סוג ספק לבחור

SSO כבוי כברירת מחדל. כשהמשתנה EXTERNAL_SSO_PROVIDERS לא מוגדר, דף ההתחברות לא מציג כפתור SSO, הנתיב GET /v1/sso/providers מחזיר רשימה ריקה, וכל נתיב של ספק מחזיר 404 unknown_provider.

הגדרת הספקים

הגדירו את EXTERNAL_SSO_PROVIDERS כמערך JSON, ישירות בערך המשתנה, או כ-@/path/to/providers.json כדי לקרוא אותו מקובץ.

[
  {
    "id": "librechat",
    "label": "LibreChat",
    "kind": "assertion",
    "secret": "a-dedicated-32+char-hmac-key-not-the-idp-session-secret",
    "audience": "nodaro",
    "claimMap": { "email": "email", "emailVerified": "email_verified", "subject": "sub" },
    "initiateUrl": "https://chat.example.com/oauth/nodaro",
    "maxLifetimeSeconds": 300
  },
  {
    "id": "keycloak",
    "label": "Acme (Keycloak)",
    "kind": "oidc",
    "supabaseProvider": "keycloak"
  }
]

ערך פגום עוצר את האתחול. שגיאת הקלדה ברשומה שיש בה סוד לעולם לא אמורה להשמיט ספק בשקט, מה שהיה נראה כמו כשל של SSO עם 404, או להשאיר את ההתחברות מוגדרת למחצה.

במערך השירותים של Compose, הוסיפו את EXTERNAL_SSO_PROVIDERS ואת EXTERNAL_SSO_LINK_EXISTING תחת environment: של השירות nodaro, כי קובץ ה-Compose לא מעביר אותם מהקובץ .env. כדי להשתמש בקובץ, מפו אותו לתוך הקונטיינר וציינו את הנתיב שלו בתוך הקונטיינר.

השדות של ספק

רק השדות id, label ו-kind מתפרסמים, דרך GET /v1/sso/providers. הסוד אף פעם לא יוצא מהשרת.

מה Nodaro בודק ב-assertion

שרת הזהות של ספק מסוג assertion חותם על JWT ושולח את הדפדפן אל GET /v1/sso/<id>?assertion=<jwt>. Nodaro מקבל את ה-assertion רק כשכל התנאים האלה מתקיימים:

• ה-assertion חתום ב-HS256 ובערך secret של הספק.
• aud שווה לערך audience של הספק.
• exp קיים ועדיין לא עבר, עם סובלנות של 5 שניות, ואורך החיים לא חורג מ-maxLifetimeSeconds.
• jti קיים ואף פעם לא נעשה בו שימוש. כל assertion עובד פעם אחת.
• ה-claim של האימייל קיים. ה-claim של האימות חייב להיות true כדי ליצור חשבון או לקשר חשבון.

assertion שנכשל באחת הבדיקות נדחה עם 401. הנתיב מקבל עד 20 בקשות ב-60 שניות מכתובת IP אחת, ובקשות נוספות נדחות עם 429. החוזה המלא, קודי השגיאה וזרימת ההפניות מתוארים בדף התחברות חיצונית (SSO) למפתחים.

איך חשבונות מקושרים

כש-assertion עובר את הבדיקות, Nodaro מוצא את המשתמש המתאים או יוצר אותו. הכללים מבטיחים ש-assertion לעולם לא יוכל להשתלט על חשבון קיים רק כי יש לו אותה כתובת אימייל.

ברירת המחדל של EXTERNAL_SSO_LINK_EXISTING היא false, וזו ההגדרה שמגינה מפני השתלטות. רק הערכים true או 1, באותיות גדולות או קטנות, מפעילים אותו. הפעילו אותו רק כשאתם סומכים על ה-claims של אימייל מאומת שהספקים שלכם שולחים, עד כדי כך שאתם מוכנים לקשר אותם לחשבונות קיימים.

הקודים account_exists ו-email_unverified מנוסחים אותו דבר לכל חשבון, ולכן אי אפשר להשתמש בטופס ההתחברות כדי לגלות אילו כתובות קיימות. יומן השרת רושם לאיזה חשבון כוונה הבקשה.

כפתור ההתחברות

דף ההתחברות מציג כפתור SSO כשמוגדר לפחות ספק אחד.

• ספק אחד: על הכפתור כתוב כניסה מאוחדת (SSO), או הערך של auth.ssoLabel בפרופיל הממשק.
• כמה ספקים: כל כפתור מציג את ה-label של הספק שלו, אלא אם פרופיל הממשק מגדיר auth.ssoLabel.

אחרי ההתחברות, המשתמש מגיע ל-/projects. הספק יכול לשלוח אותו לדף אחר אם הוא מוסיף &next=<path> כשהוא מפנה בחזרה. Nodaro מכבד את הפרמטר הזה רק כשהוא נתיב יחסי באותו origin, שמתחיל ב-/ אבל לא ב-//. כל ערך אחר מוביל ל-/projects. במארחים שמופיעים ב-CORS_ORIGIN, ההפניה לדף הנחיתה נשארת יחסית, במארח שהמשתמש הגיע אליו.

התחברות דרך SSO בלבד

במהדורת Business, פרופיל הממשק יכול להסיר את שאר שיטות ההתחברות:

NODARO_SURFACE_PROFILE={"auth":{"methods":["sso"],"ssoLabel":"Sign in with Acme"}}

רשימה שכוללת רק את sso מפעילה גם כלל בצד השרת: כל חשבון מחובר צריך להיות חשבון שנוצר או קושר דרך SSO. כל סשן אחר נדחה בקריאה הראשונה שלו ל-API עם 403 sso_required, כך שחשבון שנרשם ישירות בשירות ההתחברות לא יכול להשתמש בהתקנה. הוספת email לרשימה משביתה את הכלל. ראו את הסעיף שיטות התחברות בדף מהדורות ופרופילי ממשק.

סיכום האבטחה

• סוד ייעודי לכל ספק, שונה מסוד הסשנים של הספק עצמו.
• assertions לשימוש חד־פעמי, עם אורך חיים קצר שהשרת אוכף.
• הפניות רק לאותו origin אחרי ההתחברות.
• אף סוד לא יוצא מהשרת. ה-assertions והאסימונים החד־פעמיים מוסרים מיומני הבקשות.
• מגבלות קצב על נתיב ההחלפה, לכל כתובת IP.
• סשנים רגילים. אחרי ההחלפה, המשתמש הוא משתמש רגיל, בלי פרטי גישה מיוחדים.