Single sign-on और पहचान

Sign-in URL और पुनर्प्राप्ति

सामान्य site account प्रक्रिया के लिए /login और SSO-सक्षम sign-in के लिए /sso/login इस्तेमाल करें। Registration, recovery और passwordless प्रक्रियाएँ /sso के अंतर्गत हैं। पुराने OAuth authorization पृष्ठ चालू उपयोगकर्ताओं को मौजूदा SSO विकल्प पर भेजते हैं। URL से provider सक्षम होने की पुष्टि नहीं होती; tenant और application की स्थिति जाँचें।

1. इच्छित sign-in प्रक्रिया का URL खोलें।
2. Provider न दिखे तो tenant administrator से configuration जाँचने को कहें।
3. Factor खो जाए या password समाप्त हो तो SSO recovery prompts अपनाएँ।

Tenants, domains और पहचान

Tenant अपने applications, domains, सदस्यों, नीतियों और delegations का मालिक होता है। सत्यापित domain से खोज केवल उपयोगकर्ता को सही जगह भेजती है; यह प्रमाणीकरण या सदस्यता नहीं देती। ग्राहक administrators संगठन का SAML या OIDC configure करते हैं। पहचान tenant, issuer और स्थायी subject से मिलाएँ; केवल email के आधार पर खाते न जोड़ें।

1. सदस्य, provider या domain बदलने से पहले tenant चुनें।
2. दिखाई domain स्वामित्व जाँच पूरी कर सत्यापित स्थिति देखें।
3. Duplicate identities अधिकृत tenant प्रक्रिया से सुलझाएँ।

Applications और social providers

हर application का protocol registration, policy और lifecycle अलग है। Platform social-provider settings किसी उपयोगकर्ता की linked identity से अलग हैं। Callback पर profile पूरा करना पड़ सकता है, लेकिन सही callback से application access नहीं मिलता: सदस्यता, assignment और policy भी लागू होते हैं।

1. Tenant, owner, protocol और registered redirect या metadata मान दर्ज करें।
2. Provider की प्रबंधन screen में configuration करें और credentials सुरक्षित रखें।
3. Sign-in जाँचकर tenant और application का निर्णय पक्का करें।

भूमिकाएँ और delegation

Site roles और tenant permissions अलग हैं। Governance में parent organisations, सीमाएँ और समाप्ति वाले administrator delegations सेट किए जा सकते हैं। Delegate को एक tenant में चुनी अनुमतियाँ मिलती हैं; उच्चतर, sibling और असंबंधित scopes अस्वीकृत होते हैं। सक्रिय सदस्यता, role hierarchy और application policy सभी लागू हैं।

1. लक्ष्य tenant में administrator की सक्रिय सदस्यता रखें।
2. केवल ज़रूरी permissions दें और समाप्ति तय करें।
3. काम पूरा होने पर delegation revoke कर उसकी audit entry जाँचें।

MFA, passkeys और recovery

Sign-in में MFA, passkey या अन्य passwordless verification अथवा अधिक कड़ा step-up माँगा जा सकता है। Bootstrap, challenge, setup और recovery अलग चरण हैं; एक पूरा होने से आगे की संरक्षित कार्रवाई की शर्त पूरी नहीं होती। समर्थित tenant authenticators और enrollment campaigns के लिए administrators को authentication-management अधिकार चाहिए।

1. Passkey से sign in करें या enrollment में नया authenticator सत्यापित करें।
2. उपलब्ध तरीके से recovery करें और समझौता हुए factors बदलें।
3. अस्वीकृति मिले तो कारण लिखें और अधिकृत admin से policy जाँचने को कहें।

प्रबंधन और lifecycle

बनाया गया management contract /api/auth/management/openapi.json पर है। उसमें operation schemas और सुरक्षा आवश्यकताएँ सूचीबद्ध हैं। मानवीय प्रशासन के लिए सुरक्षित workspace उपयोग करें। Tenant और application को सक्रिय करना, रोकना, retire करना तथा rollback करना version और audit इतिहास वाला lifecycle बदलाव है।

1. OpenAPI दस्तावेज़ में आवश्यक management operation खोजें।
2. उसकी permission, tenant संदर्भ और दर्ज inputs जाँचें।
3. Lifecycle बदलाव के बाद स्थिति और audit इतिहास की पुष्टि करें।

अक्सर पूछे जाने वाले प्रश्न

संबंधित पृष्ठ

• Federation protocols और provisioning
• SSO प्रशासन
• पहचान शासन और विशेषाधिकार प्राप्त पहुँच
• निजी application पहुँच