Federation protocols और provisioning

OIDC, OAuth और PKCE

Registered OIDC clients browser authorization, account चयन, consent और जहाँ निर्धारित हो terms का उपयोग करते हैं। Device authorization अलग interface है, client registration का विकल्प नहीं। PKCE और ऊँचे assurance विकल्प client तथा tenant policy पर निर्भर हैं। PAR, private-key JWT, mTLS, DPoP और FAPI profiles शर्तों के अधीन हैं; source में होना उनके enabled होने का प्रमाण नहीं।

1. Client के लिए सही issuer, redirect और response settings दर्ज करें।
2. Consent तथा account चयन पूरा करें और identity व audience जाँचें।
3. Policy में PKCE या assurance support देखें; अस्वीकृति हटाने के लिए validation कमजोर न करें।

SAML और दूरस्थ logout

SAML service- तथा identity-provider routes metadata और browser assertion flow देते हैं। Connection को SAML management से configure करें। Partner के साथ issuer, audience, reply destination, signature और समय शर्तें जाँचें। Logout अलग है: स्थानीय revocation से यह सिद्ध नहीं होता कि हर relying-party cookie या session हट गया।

1. Partner के साथ connection metadata, signing key और endpoints मिलाएँ।
2. Signed assertion जाँचें; tenant, subject, सदस्यता और expiry सत्यापित करें।
3. समर्थित logout controls उपयोग करें और स्थानीय revocation को remote sign-out से अलग समझें।

SCIM और directory sync

Provisioning, interactive federation से अलग है। SCIM का data ढाँचा और मिलान प्रक्रिया उपलब्ध हैं; साथ ही ऐसे directory connectors हैं जो ग्राहक पक्ष पर दर्ज agent इस्तेमाल करते हैं। Import tenant का स्रोत-संदर्भ बनाए रखते हैं और conflicts को अलग जाँच के लिए रोकते हैं; केवल email से खाते link नहीं होते। Server में ग्राहक agent binary शामिल नहीं है।

1. Tenant target दर्ज कर समर्थित attributes और स्थायी identity keys map करें।
2. नियंत्रित sync चलाएँ; नतीजे देखें और रोके गए conflicts tenant प्रक्रिया में सुलझाएँ।
3. Connector का काम queue करने से पहले संगत agent अलग से deploy और enroll करें।

CAS, WS-Federation और RADIUS

CAS के लिए स्पष्ट enablement चाहिए। अनुमति प्राप्त registration या policy चालू न करे तो WS-Federation और WS-Trust बंद रहते हैं; realm, audience, reply, सदस्यता, signature और expiry checks अनिवार्य हैं। RADIUS वैकल्पिक signed agent उपयोग करता है, site listener नहीं। बनाए रखा reference TLS या DTLS पर RADIUS/1.1 को प्राथमिकता देता है; पुराना UDP केवल निजी network की compatibility के लिए है।

1. CAS या WS-Federation जाँचने से पहले protocol enablement और client registration देखें।
2. RADIUS के लिए customer agent, tenant connector और अनुमत transport की पुष्टि करें।
3. बंद या unenrolled स्थिति में policy से बचने हेतु protocol बदलने के बजाय setup पूरा करें।

Registration और credentials

Client registration उसी tenant और application में रहना चाहिए जिसके स्वामित्व में वह है। Dynamic registration, private-key JWT, mTLS और FAPI संदर्भ शर्तों वाले contract बताते हैं, सार्वभौमिक enablement नहीं। Private keys उनके मालिक के पास रखें और संबंधित management control से credentials rotate या revoke करें। Agent keys OAuth client credentials नहीं हैं।

1. Owner, tenant, redirect या metadata, scopes और credential type जुटाएँ।
2. मिला secret सुरक्षित रखें; management से rotate या revoke करें।
3. Agent enrollment के लिए private key ग्राहक पक्ष पर बनाएँ और उसका CSR जमा करें।

Contract और समस्या निवारण

मौजूदा management operations, fields और सुरक्षा के लिए /api/auth/management/openapi.json उपयोग करें। बनाए रखे protocol notes में connector और assurance का अधिक सीमित व्यवहार है। आम समस्याएँ: गलत tenant, unregistered redirect, पुराना metadata या certificate, disabled profile, अमान्य signature, SCIM conflict या revoked agent। संबंधित trust boundary ठीक करें; जाँच बंद न करें।

1. Operation का OpenAPI ढाँचा और सुरक्षा शर्तें जाँचें।
2. सुरक्षित error विवरण तथा registered मान मौजूदा provider metadata से मिलाएँ।
3. नियंत्रित प्रक्रिया फिर जाँचें और rollout से पहले identity या sync स्थिति की पुष्टि करें।

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

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

• Single sign-on और पहचान
• SSO प्रशासन
• पहचान शासन और विशेषाधिकार प्राप्त पहुँच
• निजी application पहुँच