16 ਨਵੰ 2025·8 ਮਿੰਟ
SSO ਲਈ OAuth vs SAML: ਐਨਟਰਪ੍ਰਾਈਜ਼ ਖਰੀਦਦਾਰਾਂ ਦੀਆਂ ਉਮੀਦਾਂ
ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ OAuth ਅਤੇ SAML ਵੱਲੋਂ SSO ਦੀਆਂ ਖਾਸੀਅਤਾਂ ਸਮਝਾਓ, ਐਨਟਰਪ੍ਰਾਈਜ਼ ਕੀ ਮੰਗਦੇ ਹਨ, ਕੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ ਲੌਗਿਨ ਨੂੰ ਬਿਨਾਂ ਤੋੜੇ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ।
ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ OAuth ਅਤੇ SAML ਵੱਲੋਂ SSO ਦੀਆਂ ਖਾਸੀਅਤਾਂ ਸਮਝਾਓ, ਐਨਟਰਪ੍ਰਾਈਜ਼ ਕੀ ਮੰਗਦੇ ਹਨ, ਕੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ ਲੌਗਿਨ ਨੂੰ ਬਿਨਾਂ ਤੋੜੇ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ।
ਜਿਵੇਂ ਹੀ ਇੱਕ ਡੀਲ "ਟੀਮ ਟ੍ਰਾਇਅਲ" ਤੋਂ ਕੰਪਨੀ ਰੋਲਆਉਟ ਵੱਲ ਵਧਦੀ ਹੈ, SSO ਤੁਰੰਤ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ। ਕੋਈ ਖਰੀਦਦਾਰ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਪਸੰਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਸੁਰੱਖਿਆ ਅਤੇ IT ਪ੍ਰਕਿਰਿਆ ਖਰੀਦਦਾਰੀ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ ਜੇ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਨਵੇਂ ਪਾਸਵਰਡ ਬਣਾਉਣੇ ਪੈਣ, ਵੱਖਰਾ MFA ਸੰਭਾਲਨਾ ਪਏ, ਜਾਂ ਲੋਕਾਂ ਦੇ ਰੋਲ ਬਦਲਣ 'ਤੇ ਖਾਤਿਆਂ ਨੂੰ ਛੱਡਣਾ ਪਵੇ।
ਕਈ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਲਈ SSO ਆਸਾਨੀ ਤੋਂ ਜ਼ਿਆਦਾ ਨਿਯੰਤਰਣ ਬਾਰੇ ਹੁੰਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਫਿਰ ਇੱਕ ਥਾਂ ਚਾਹੀਦੀ ਹੈ ਜਿੱਥੇ ਲੌਗਿਨ ਨੀਤੀਆਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣ, ਪਹੁੰਚ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਰੋਕਿਆ ਜਾ ਸਕੇ, ਅਤੇ ਆਡੀਟਰਾਂ ਨੂੰ ਦਿਖਾਇਆ ਜਾ ਸਕੇ ਕਿ ਪਹਚਾਣ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਹੈ। ਇਸੀ ਲਈ "OAuth vs SAML for SSO" ਦਾ ਸਵਾਲ ਵਿਕਰੀ ਚੱਕਰ ਦੇ ਅਖੀਰ 'ਚ ਆਉਂਦਾ ਹੈ: ਇਹ ਇੱਕ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਜਾਂਚਣ ਦਾ ਕਿ ਕੀ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦੀ ਆਈਡੈਂਟੀਟੀ ਸੈਟਅਪ ਨਾਲ ਮਿਲਦੇ ਹੋ।
SSO ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਨਾ ਉਹ ਧਾਰਣਾਵਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜਿੰਨਾਂ 'ਤੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਨਿਰਭਰ ਹੋ। ਜੇ ਤੁਹਾਡਾ ਮੌਜੂਦਾ ਮਾਡਲ "ਇੱਕ ਈਮੇਲ = ਇੱਕ ਯੂਜ਼ਰ" ਹੈ, ਤਾਂ SSO ਨਾਲ ਸ਼ੇਅਰ ਕੀਤੀਆਂ ਐਲਿਆਂਸ, ਕਈ IdP, ਜਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਦੋਹਾਂ ਪਾਸਵਰਡ ਲੌਗਿਨ ਅਤੇ SSO ਰੱਖਣ ਵਾਲੇ ਯੂਜ਼ਰ ਵਰਗੇ ਐਜ ਕੇਸ ਆ ਸਕਦੇ ਹਨ। ਜੇ ਅਕਾਊਂਟ ਲਿੰਕਿੰਗ ਗਲਤ ਹੋਈ ਤਾਂ ਲੋਕਾਂ ਦੀ ਪਹੁੰਚ ਖਤਮ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਉਸ ਤੋਂ ਵੀ ਵੱਧ, ਗਲਤ ਟੇਨੈਂਟ ਨੂੰ ਪਹੁੰਚ ਮਿਲ ਸਕਦੀ ਹੈ।
SSO ਓਨਬੋਰਡਿੰਗ ਅਤੇ ਸਪੋਰਟ ਨੂੰ ਵੀ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਗਿਆ ਹੋਵੇ ਤਾਂ ਇਹ ਪਾਸਵਰਡ ਰੀਸੈਟ ਅਤੇ "ਇਹ ਅਕਾਊਂਟ ਕਿਸਦਾ ਹੈ?" ਟਿਕਟ ਘਟਾ ਦਿੰਦਾ ਹੈ। ਖਰਾਬ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਗਿਆ ਹੋਵੇ ਤਾਂ ਰੋਲ-ਆਉਟ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਐਡਮਿਨ ਨਾਰਾਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਨਵੀਕੀਕਰਨ ਖਤਰਨਾਕ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਉਤਪਾਦ "ਟ੍ਰਾਇਅਲ ਵਿੱਚ ਚੰਗਾ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ" ਪਰ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਡਿਪਲੋਇਮੈਂਟ ਦੇ ਪਹਿਲੇ ਦਿਨ fail ਹੋ ਜਾਂਦਾ ਹੈ।
ਫ਼ੈਸਲਾ ਕਦੇ ਵੀ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਇਲਾਕਾ ਨਹੀਂ ਹੁੰਦਾ। ਖਰੀਦਦਾਰ ਗਤੀ ਚਾਹੁੰਦੇ ਹਨ, ਸੁਰੱਖਿਆ ਜਾਂਚ, ਰਿਸਕ ਅਤੇ ਆਡਿਟ ਦੀਆਂ ਲੋੜਾਂ, IT ਐਡਮਿਨ ਸਪਸ਼ਟ ਸੈਟਅਪ ਕਦਮ ਲੋੜਦੇ ਹਨ, ਅਖੀਰੀ ਯੂਜ਼ਰ ਇੱਕ ਮਿੱਠੀ ਲੌਗਿਨ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਪੋਰਟ ਲੌਕਆਉਟ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਐਕਸੀਪਸ਼ਨ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ ਤੇ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ SSO ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਯੋਜਨਾ ਬਣਾਉਣਾ ਫਾਇਦemand ਰਹੇਗਾ ਤਾਂ ਕਿ ਗਾਹਕ ਪਹਿਲਾਂ ਹੀ ਸਰਗਰਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ ਆਈਡੈਂਟੀਟੀ ਨੂੰ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਨਾ ਕਰਨਾ ਪਵੇ।
SSO (single sign-on) ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਗਾਹਕ ਤੁਹਾਡੇ ਐਪ ਵਿੱਚ ਆਪਣੇ ਕੰਪਨੀ ਲੌਗਿਨ ਨਾਲ ਸਾਇਨ ਇਨ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਵੱਖਰਾ ਪਾਸਵਰਡ। ਉਹ ਆਪਣੇ ਵਰਕ ਅਕਾਊਂਟ ਨਾਲ ਸਾਇਨ ਇਨ ਕਰਦੇ ਹਨ ਅਤੇ ਪਹੁੰਚ ਕੰਪਨੀ ਨੀਤੀਆਂ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਹੁੰਦੀ ਹੈ।
ਇਹ ਉਹ ਸ਼ਰਤਾਂ ਹਨ ਜੋ ਤੁਸੀਂ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਕਾਲਾਂ 'ਤੇ ਸੁਣੋਗੇ:
ਜਦੋਂ ਲੋਕ "OAuth login" ਕਹਿੰਦੇ ਹਨ, ਉਹ ਅਕਸਰ OpenID Connect (OIDC) ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ। OAuth ਮੁੱਖ ਤੌਰ 'ਤੇ authorization (ਕਿਸੇ ਚੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਦੀ ਆਗਿਆ) ਬਾਰੇ ਹੈ। OIDC authentication (ਯੂਜ਼ਰ ਕੌਣ ਹੈ) ਨੂੰ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਲੌਗਿਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।
SAML ਇੱਕ ਪੁਰਾਣਾ, XML-ਅਧਾਰਿਤ SSO ਮਿਆਰ ਹੈ। ਐਨਟਰਪ੍ਰਾਈਜ਼ ਹੁਣ ਵੀ ਇਸਨੂੰ ਭਾਰੀ ਪੱਧਰ ਤੇ ਵਰਤਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਸਾਬਤ شده, ਵਿਆਪਕ ਤੌਰ 'ਤੇ IdP ਦੁਆਰਾ ਸਹਿਯੋਗਤ, ਅਤੇ ਕਈ ਕੰਪਲਾਇੰਸ ਚੈੱਕਲਿਸਟਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੈ।
SCIM SSO ਨਹੀਂ ਹੈ। SCIM provisioning ਲਈ ਹੈ: ਯੂਜ਼ਰਾਂ (ਅਤੇ ਕਦੇ-ਕਦੇ ਗਰੁੱਪਾਂ) ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਬਣਾਉਣਾ, ਅਪਡੇਟ ਅਤੇ ਅਯਕਟਿਵੇਟ ਕਰਨਾ। ਆਮ ਸੈਟਅਪ SAML ਜਾਂ OIDC ਸਾਇਨ-ਇਨ ਲਈ ਅਤੇ SCIM ਇਸ ਲਈ ਕਿ ਪਹੁੰਚ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਜੋੜੀ ਜਾਂ ਹਟਾਈ ਜਾ ਸਕੇ।
ਐਨਟਰਪ੍ਰਾਈਜ਼ ਖਰੀਦਦਾਰ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਟੋਕੋਲ ਵੇਰਵਿਆਂ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਰਿਸਕ ਅਤੇ ਨਿਯੰਤਰਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ: "ਕੀ ਅਸੀਂ ਆਪਣੀ identity provider ਤੋਂ ਪਹੁੰਚ ਪ੍ਰਬੰਧਿਤ ਕਰ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਕੀ ਅਸੀਂ ਇਹ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਕਿਸਨੇ ਕੀ ਕੀਤਾ?"
ਵੱਧਤਰ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਟੀਮਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ enterprise-friendly ਵਿਕਲਪ ਚਾਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਕਈਆਂ ਨੂੰ ਦੋਨੋਂ ਚਾਹੀਦੇ ਹਨ:
ਉਹ ਇਹ ਵੀ ਪੁੱਛਣਗੇ ਕਿ ਸੈਟਅਪ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ: metadata ਜਾਂ discovery URL, ਸਰਟੀਫਿਕੇਟ ਰੋਟੇਸ਼ਨ, ਅਤੇ ਕੀ IT ਆਪਣੇ ਆਪ ਸੇਲਫ-ਸਰਵ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਤੁਹਾਡੇ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਉਡੀਕ ਕੀਤੇ।
ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਡੀਲ ਖੋਣ ਦਾ ਤਰੀਕਾ offboarding ਬਾਰੇ vague ਹੋਣਾ ਹੈ। ਉਹ ਪੁੱਛਣਗੇ ਕਿ ਇੱਕ ਕਰਮਚਾਰੀ ਦੇ ਜਾਣ ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਡਿਪਾਰਟਮੈਂਟ ਬਦਲਦਾ ਹੈ, ਜਾਂ ਲੈਪਟਾਪ ਖੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।
ਤਕਨੀਕੀ ਸਵਾਲ ਜਿਹੜੇ ਉਹ ਪੁੱਛਣਗੇ:
ਉਹ ਇੱਕ ਸਰਲ ਸਥਿਤੀ ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹਨ: ਇੱਕ ਐਡਮਿਨ 9:02 ਤੇ ਯੂਜ਼ਰ ਨੂੰ disabled ਕਰਦਾ ਹੈ, ਅਤੇ 9:03 ਤਕ ਉਹ ਯੂਜ਼ਰ ਐਪ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਣਾ ਚਾਹੀਦਾ, ਭਾਵੇਂ ਉਹ ਅਜੇ ਵੀ browser tab ਰੱਖੇ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਉਸ ਫਲੋ ਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਵਧੇਰੇ ਰਿਵਿਊ ਚੱਕਰਾਂ ਦੀ ਉਮੀਦ ਕਰੋ।
OAuth ਸ਼ੁਰੂ ਵਿੱਚ delegated access ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ: ਇੱਕ ਸਿਸਟਮ ਨੂੰ ਦੂਜੇ ਸਿਸਟਮ ਦੀ API ਕਾਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣਾ ਬਿਨਾਂ ਪਾਸਵਰਡ ਸਾਂਝਾ ਕੀਤੇ। ਬਹੁਤ ਸਾਰੇ ਟੀਮ ਹੁਣ ਵੀ ਇਸਦਾ ਇਸਤੇਮਾਲ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ ਇੱਕ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਜੋ ਕੈਲੇਂਡਰ ਪੜ੍ਹਦਾ ਹੈ)। ਕਰਮਚਾਰੀ ਲੌਗਿਨ ਲਈ, ਜ਼ਿਆਦਾਤਰ ਉਤਪਾਦ OpenID Connect (OIDC) ਵਰਤਦੇ ਹਨ, ਜੋ OAuth ਦੇ ਉੱਤੇ ਬੈਠਦਾ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਕੌਣ ਹੈ ਇਹ ਸਾਬਤ ਕਰਨ ਦਾ ਇੱਕ ਮਿਆਰੀ ਤਰੀਕਾ ਜੋੜਦਾ ਹੈ।
OIDC ਦੇ ਨਾਲ, ਆਮ ਸੈਟਅਪ authorization code flow ਹੈ। ਤੁਹਾਡੀ ਐਪ ਯੂਜ਼ਰ ਨੂੰ ਕੰਪਨੀ ਦੇ IdP ਵੱਲ ਸਾਇਨ ਇਨ ਲਈ ਭੇਜਦੀ ਹੈ। ਸਫਲ ਲੌਗਿਨ ਤੋਂ ਬਾਦ, IdP ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਇੱਕ ਛੋਟੇ ਸਮੇਂ ਵਾਲਾ authorization code ਭੇਜਦਾ ਹੈ। ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਉਸ ਕੋਡ ਨੂੰ ਟੋਕਨ ਲਈ ਐਕਸਚੇਂਜ ਕਰਦਾ ਹੈ।
ਜੋ ਟੋਕਨ ਅਹਿਮ ਹਨ ਉਹ ਇਹ ਹਨ:
OAuth vs SAML for SSO ਬਾਰੇ ਪ੍ਰੈਕਟਿਕਲ ਰੂਪ ਵਿੱਚ ਸੋਚੋ: OIDC ਉਹਦੇ ਵਾਸਤੇ ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਆਧੁਨਿਕ ਲੌਗਿਨ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਵੈੱਬ, ਮੋਬਾਈਲ ਅਤੇ API ਪੈਟਰਨਾਂ ਨਾਲ ਫਿੱਟ ਬaithe। SAML ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਵੱਧ ਮਿਲਦਾ ਹੈ ਜਦੋਂ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਨੂੰ ਰਿਵਾਇਤੀ "ਐਪ ਵਿੱਚ ਸਾਇਨ ਇਨ" ਹਨਡਸ਼ੇਕ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹ API ਪਹੁੰਚ ਬਾਰੇ ਘੱਟ ਚਿੰਤਿਤ ਹੁੰਦੇ ਹਨ।
ਤੁਹਾਨੂੰ ਜੋ ਸਟੋਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਉਹ ਸਧਾਰਨ ਰੱਖੋ: ਯੂਜ਼ਰ ਦਾ ਸਥਿਰ ਪਹਚਾਨ (subject), ਉਹਨਾਂ ਦੀ ਈਮੇਲ (ਜੇ ਦਿੱਤੀ ਗਈ ਹੋਵੇ), ਅਤੇ ਜਿਸ ਟੈਨੈਂਟ ਕਨੈਕਸ਼ਨ ਨੂੰ ਉਹ ਵਰਤੇ। ਯੂਜ਼ਰ ਦਾ ਪਾਸਵਰਡ ਸਟੋਰ ਨਾ ਕਰੋ। ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ refresh ਟੋਕਨ ਸਟੋਰ ਕਰਨ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ offline API ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ।
ਇਸ ਨੂੰ ਪ੍ਰਤੀ ਗਾਹਕ ਟੈਨੈਂਟ ਲਈ ਕੰਮ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਏਗੀ:
ਠੀਕ ਤਰੀਕੇ ਨਾਲ, ਯੂਜ਼ਰ ਆਪਣੀ ਐਪ 'ਚ ਵਾਪਸ ਲੈਂਡ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਟੋਕਨ ਵੈਰੀਫਾਈ ਕਰਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਆਪਣੀ ਨਾਰਮਲ ਸੈਸ਼ਨ ਬਣਾਉਂਦੇ ਹੋ ਬਿਨਾਂ ਆਪਣੇ ਪੂਰੇ auth ਮਾਡਲ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ।
SAML ਏਨਟਰਪ੍ਰਾਈਜ਼ IdP ਨੂੰ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਦੱਸਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ: "ਇਹ ਵਿਅਕਤੀ ਪਹਿਲਾਂ ਹੀ ਸਾਇਨ ਇਨ ਕਰ ਚੁੱਕਾ ਹੈ, ਇਨ੍ਹਾਂ ਵੇਰਵਿਆਂ ਦੇ ਨਾਲ।" IdP ਇੱਕ SAML assertion ਭੇਜਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਾਇਨ ਕੀਤਾ ਹੋਇਆ ਨੋਟ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਯੂਜ਼ਰ ਕੌਣ ਹੈ (ਕਈ ਵਾਰੀ ਗਰੁੱਪ ਜਾਂ ਰੋਲ ਜਾਣਕਾਰੀ ਵੀ), ਅਤੇ ਇੱਕ ਛੋਟੀ ਵੈਧਤਾ ਖਿੜਕੀ ਹੁੰਦੀ ਹੈ।
ਉਸ ਨੋਟ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ, SAML metadata ਅਤੇ certificates 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ। Metadata ਇੱਕ ਛੋਟੀ ਕਨਫਿਗ ਫਾਈਲ ਹੈ ਜੋ endpoints ਅਤੇ ਕੁੰਜੀਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਮੁੱਖ ਤੌਰ 'ਤੇ signatures ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਐਪ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ ਕਿ assertion ਗਾਹਕ ਦੇ IdP ਤੋਂ ਆਇਆ ਹੈ ਅਤੇ ਬਦਲਾ ਨਹੀਂ ਗਿਆ।
ਦੋ identifiers ਆਮ ਤੌਰ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ:
ਜੇ ਕੋਈ ਵੀ ਗਲਤ ਹੋਵੇ ਤਾਂ ਲੌਗਿਨ fail ਹੋ ਜਾਂਦਾ ਹੈ ਭਾਵੇਂ ਹੋਰ ਸਭ ਕੁਝ ਠੀਕ ਲੱਗੇ।
ਅਸਲ ਦੁਨੀਆਂ ਵਿੱਚ SAML ਕੋਡ ਤੋਂ ਜ਼ਿਆਦਾ ਓਪਰੇਸ਼ਨ ਹੈ। ਟੈਨੈਂਟ-ਸਤਰ ਦੀ SAML ਸੈਟਿੰਗ, ਸਰਟੀਫਿਕੇਟ ਰੋਟੇਸ਼ਨ ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ, ਘੜੀ ਦੇ ਸਕਿਊ (ਕੱਛ मिनट ਵੀ assertions ਨੂੰ ਬ੍ਰੇਕ ਕਰ ਸਕਦੇ ਹਨ), ਅਤੇ ਐਡਮਿਨ ਲਈ ਸਪਸ਼ਟ ਏਰਰ ਸੁਨੇਹੇ ਯੋਜਨਾ ਵਿੱਚ ਰੱਖੋ ( ਸਿਰਫ਼ "invalid response" ਨਾ ਹੋਵੇ)।
ਆਮ ਪੈਟਰਨ: ਗਾਹਕ ਐਡਮਿਨ ਪ੍ਰਤੀ-ਟੈਨੈਂਟ SAML ਯੋਗ ਕਰਦਾ ਹੈ, ਫਿਰ ਤੁਹਾਡੀ ਐਪ ਸਿਗਨੇਚਰ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ, assertions expire ਨਹੀਂ ਹੋਏ ਇਹ ਦੇਖਦੀ ਹੈ, ਅਤੇ ਈਮੇਲ (ਜਾਂ NameID) ਨੂੰ ਮੌਜੂਦਾ ਯੂਜ਼ਰ ਨਾਲ ਮੈਪ ਕਰਦੀ ਹੈ ਜਾਂ ਸੁਰੱਖਿਅਤ auto-provision ਨੀਤੀ ਲਾਉਂਦੀ ਹੈ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਹੀ OAuth vs SAML ਫੈਸਲੇ ਦਾ ਕੇਂਦਰ ਹੈ: SAML ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਮਜਬੂਤ ਐਡਮਿਨ ਵਰਕਫਲੋਜ਼ ਬਣਾਉਣ 'ਤੇ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।
OIDC ਅਤੇ SAML ਵਿਚੋਂ ਚੋਣ ਜ਼ਿਆਦਾਤਰ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡਾ ਖਰੀਦਦਾਰ ਪਹਿਲਾਂ ਹੀ ਕੀ ਚਲਾ ਰਿਹਾ ਹੈ। ਬਹੁਤ سارے B2B ਐਪ ਆਖਿਰਕਾਰ ਸਮੇਂ ਦੇ ਨਾਲ ਦੋਨੋਂ ਸਪੋਰਟ ਕਰ ਲੈਂਦੇ ਹਨ, ਪਰ ਤੁਸੀਂ ਹਰੇਕ ਗਾਹਕ ਲਈ ਇੱਕ ਸਾਫ਼ ਫੈਸਲਾ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਆਪਣੇ auth ਸਿਸਟਮ ਨੂੰ ਪੇਸ਼ਗੀ ਬਣਾਈ ਰੱਖ ਸਕਦੇ ਹੋ।
OIDC ਆਮ ਤੌਰ 'ਤੇ ਆਧੁਨਿਕ ਐਪਾਂ ਲਈ ਜ਼ਿਆਦਾ ਨਰਮ ਹੁੰਦਾ ਹੈ। ਇਹ ਬ੍ਰਾ9ਜ਼ਰ ਅਤੇ ਮੋਬਾਈਲ ਐਪਾਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, APIs ਨਾਲ ਠੀਕ ਖੇਡਦਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ debug ਅਤੇ ਵਧਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ (scopes, token lifetimes, ਆਦਿ)। ਜੇ ਤੁਹਾਡਾ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਗਾਹਕ ਪਹਿਲਾਂ ਹੀ ਆਧੁਨਿਕ IdP ਸੈਟਅਪ ਵਰਤਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੀ IT ਟੀਮ OIDC ਨਾਲ ਆਮ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ OIDC ਸ਼ੁਰੂ ਕਰੋ।
SAML ਕਈ ਵਾਰੀ ਗੈਰ-ਮੁਨਾਫ਼ਾ ਨਹੀਂ ਹੁੰਦਾ। ਕਈ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਕੋਲ ਮੌਜੂਦਾ SAML ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਵੈਂਡਰ ਓਨਬੋਰਡਿੰਗ ਨੀਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਵੇਂ "ਕੇਵਲ SAML"। ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਸਿੱਧਾ ਹੈ: SAML ਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਤਰੀਕੇ ਨਾਲ ਇੱਕ ਵਾਰੀ ਇੰਪਲੀਮੈਂਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਤੁਹਾਡੇ ਬਾਕੀ ਲੌਗਿਨ ਸਿਸਟਮ ਤੋਂ ਆਲੱਗ ਰੱਖੋ।
ਕੁਝ ਸਵਾਲ ਜੋ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛਣੇ ਚਾਹੀਦੇ ਹਨ:
ਛੇਤੀ ਫੈਸਲਾ ਗਾਈਡ:
| If the customer says... | Prefer | Why |
|---|---|---|
| "We use Entra ID and want a modern app integration" | OIDC | Better fit for web and API flows |
| "Our policy is SAML only for vendors" | SAML | Required to pass security onboarding |
| "We need both for different subsidiaries" | Both | Common in large orgs |
| "We need custom claims per app" | Either | Both support attribute mapping |
ਜੇ ਤੁਸੀਂ ਦੋਹਾਂ ਸਪੋਰਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਬਾਕੀ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਇਕਸਾਰ ਰੱਖੋ: ਇੱਕ ਅੰਦਰੂਨੀ ਯੂਜ਼ਰ ਮਾਡਲ, ਇੱਕ ਸੈਸ਼ਨ ਮਾਡਲ, ਅਤੇ ਇੱਕ autorização ਨੀਤੀ। SSO ਦੀ ਵਿਧੀ ਨੂੰ ਇਹ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ "ਇਹ ਯੂਜ਼ਰ ਕੌਣ ਹੈ ਅਤੇ ਉਹ ਕਿਸ ਟੈਨੈਂਟ ਨਾਲ ਸੰਬੰਧਤ ਹੈ," ਨਾ ਕਿ ਇਹਕੋ ਕਿ ਪਹੁੰਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਦਿਓ।
ਸ਼ੁਰੂਆਤ ਕਰਕੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ "ਟੈਨੈਂਟ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਜ਼ਿਆਦਾਤਰ B2B ਐਪਾਂ ਲਈ, SSO ਆਰਗਨਾਈਜ਼ੇਸ਼ਨ ਜਾਂ ਵਰਕਸਪੇਸ ਫਰ੍ਹ ਹਰ ਟੈਨੈਂਟ ਤੇ ਸੰਰਚਿਤ ਹੁੰਦਾ ਹੈ, ਨ ਕਿ ਯੂਜ਼ਰ-ਸਤਰ 'ਤੇ। ਇਹ ਫੈਸਲਾ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ IdP ਸੈਟਿੰਗਾਂ ਕਿੱਥੇ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਕੌਣ ਉਨ੍ਹਾਂ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਯੂਜ਼ਰ ਵਰਕਸਪੇਸਾਂ ਵਿਚ ਕਿਵੇਂ ਲਿਜਾਏ ਜਾਂਦੇ ਹਨ।
ਅਗਲਾ, ਇੱਕ predictable login ਵਰਤਾਰਾ ਚੁਣੋ। ਈਮੇਲ ਡੋਮੇਨ ਰੂਟਿੰਗ (ਈਮੇਲ ਟਾਈਪ ਕਰੋ, ਫਿਰ ਜੇ ਡੋਮੇਨ SSO-ਯੋਗ ਹੈ ਤਾਂ ਰੀਡਾਇਰੈਕਟ) ਕਾਫ਼ੀ ਘਟਾਉਣ ਵਾਲੀ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ contractors ਅਤੇ ਮਲਟੀ-ਡੋਮੇਨ ਕੰਪਨੀਆਂ ਵਰਗੇ ਐਜ ਕੇਸ ਸੰਭਾਲਣੇ ਪੈਣਗੇ। ਇੱਕ ਸਧਾਰਨ "Continue with SSO" ਬਟਨ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਹੈ, ਪਰ ਯੂਜ਼ਰ ਗਲਤ ਵਿਕਲਪ ਚੁਣ ਸਕਦੇ ਹਨ।
OIDC ਜਾਂ SAML ਲਈ ਇੱਕ ਸੇਫ਼ ਬਿਲਡ ਆਰਡਰ:
ਟੈਸਟਿੰਗ ਪਸ਼ਨਲ ਨਹੀਂ ਹੈ। ਇਕ sandbox IdP ਅਤੇ staging ਟੈਨੈਂਟ ਵਰਤੋ ਜੋ ਹਕੀਕਤੀ ਡੋਮੇਨਸ ਨਾਲ ਮਿਲਦਾ ਜੁਲਦਾ ਹੋਵੇ। ਖੁਸ਼ ਰਸਤਾ ਅਤੇ ਫੇਲਿਊਰ ਕੇਸ ਚਲਾਓ: expired cert, galat audience, clock skew, IdP ਤੋਂ ਯੂਜ਼ਰ ਹਟਾਉਣਾ। SSO rollout ਨੂੰ feature flag ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ।
Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀ iteration ਨੂੰ ਅਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ snapshots ਅਤੇ rollback ਨਾਲ ਪ੍ਰਤੀ-ਟੈਨੈਂਟ ਕਨਫਿਗ ਦੀ ਸਹਾਇਤਾ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਕਿ ਇਕ ਗਲਤ ਬਦਲਾਅ ਹਰ ਗਾਹਕ ਨੂੰ ਬੰਦ ਨਾ ਕਰ ਦੇਵੇ।
SSO ਸਿਰਫ਼ ਇੱਕ ਲੌਗਿਨ ਬਟਨ ਨਹੀਂ ਹੈ। ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਸੈਸ਼ਨ ਦੀ ਅਵਧੀ, offboarding, ਅਤੇ ਤੁਸੀਂ ਕਿਸ ਗੱਲ ਦੀ ਸਾਬਤੀ ਦੇ ਸਕਦੇ ਹੋ ਇਸ ਬਾਰੇ ਪੁੱਛਣਗੀਆਂ। ਜੇ ਤੁਸੀਂ SSO ਨੂੰ ਆਪਣੇ auth ਸਿਸਟਮ ਦਾ ਮੂਲ ਹਿੱਸਾ ਮੰਨਦੇ ਹੋ (ਨ ਕਿ ਇੱਕ bolt-on), ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਦਰਦਨਾਕ escalation ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ।
ਸ਼ੁਰੂਆਤ ਸੈਸ਼ਨ ਨਿਯਮਾਂ ਨਾਲ ਕਰੋ। ਇੱਕ idle timeout ਅਤੇ absolute session lifetime ਚੁਣੋ, ਅਤੇ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਜਦੋਂ ਕੋਈ ਲੈਪਟਾਪ ਬੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲ ਨੂੰ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। OIDC ਨਾਲ, refresh ਟੋਕਨ ਸੈਸ਼ਨਾਂ ਨੂੰ ਲੰਮਾ ਰੱਖ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਵਿੱਚ ਲਿਮਿਟਸ (rotation, max age) ਸੈੱਟ ਕਰੋ ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਦੇ ਹੋ। SAML ਨਾਲ, browser sessions ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰਹਿ ਸਕਦੇ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ re-auth enforce ਨਾ ਕਰੋ।
ਲੌਗਆਉਟ ਇੱਕ ਹੋਰ ਜਾਲ ਹੈ। "Single logout" ਸਾਰਥਕ ਨਹੀਂ ਹੈ। ਆਪਣੀ ਐਪ ਲਈ local logout ਭਰੋਸੇਯੋਗ ਬਣਾਓ, ਅਤੇ ਦੱਸੋ ਕਿ ਗਲੋਬਲ logout ਹਰ ਐਪ 'ਤੇ IdP 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
MFA ਨੂੰ IdP ਤੇ ਲਾਗੂ ਕਰਨ ਦੀ ਇੱਛਾ ਰੱਖੋ; ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇੱਕ authenticated ਯੂਜ਼ਰ ਨੂੰ ਬਿਨਾ ਮੁੜ ਪੁੱਛੇ ڪيਬਦਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਵੀ, risky actions (ਜਿਵੇਂ ਡਾਟਾ ਐਕਸਪੋਰਟ) ਲਈ step-up checks ਰੱਖਣਾ ਲਾਭਦਾਇਕ ਹੈ।
User provisioning ਜਥੇ ਪਹੁੰਚ ਲੀਕ ਹੁੰਦੀ ਹੈ। JIT provisioning ਸੁਵਿਧਾਜਨਕ ਹੈ, ਪਰ ਇਹ ਕਿਸੇ ਵੀ ਹੋ ਸਕਦਾ ਲਈ ਖਾਤੇ ਬਣਾਉ ਸਕਦਾ ਹੈ ਜੋ authenticate ਕਰ ਸਕਦਾ ਹੈ। Invite-only ਸੁਲਭ ਹੈ ਪਰ ਐਡਮਿਨ ਕੰਮ ਵਧਾਉਂਦਾ ਹੈ। ਬਹੁਤ ਟੀਮ ਮਿਡ-ਗ੍ਰਾਊਂਡ 'ਤੇ ਆਉਂਦੇ ਹਨ: JIT ਦੀ ਆਗਿਆ ਹੈ, ਪਰ allowed domains ਅਤੇ (ਚਾਹੇ ਤਾਂ) ਗਰੁੱਪ claims ਦੁਆਰਾ ਸੀਮਿਤ ਕੀਤਾ ਗਿਆ।
SSO কਨਫਿਗ least-privilege roles ਦੇ ਪਿੱਛੇ ਰੱਖੋ। ਕਿਸੇ ਨੂੰ ਸਿਰਫ਼ ਸਰਟੀਫਿਕੇਟ ਰੋਟੇਸ਼ਨ ਜਾਂ IdP URL ਅੱਪਡੇਟ ਕਰਨ ਲਈ super-admin ਹੱਕ ਨਹੀਂ ਚਾਹੀਦੇ।
ਸਪੋਰਟ ਲਈ, ਇੱਕ ਹੀ ਲੌਗਿਨ ਨੂੰ ਟਰੇਸ ਕਰਨ ਲਈ ਕਾਫੀ ਲੌਗ ਰੱਖੋ ਬਿਨਾਂ secrets ਸੰਭਾਲੇ:
ਇਹ ਫਰਕ ਹੈ "ਅਸੀਂ ਇਸਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ" ਅਤੇ ਐਨਟਰਪ੍ਰਾਈਜ਼ SSO outage ਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਠੀਕ ਕਰਨ ਦੇ ਬੀਚ।
ਇੱਕ ਮਿਡ-ਮਾਰਕੀਟ ਕੰਪਨੀ procurement ਤੇ ਪਹੁੰਚਦੀ ਹੈ ਅਤੇ ਕਹਿੰਦੀ ਹੈ: "ਸਾਨੂੰ ਸਾਇਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ SSO ਦੀ ਲੋੜ ਹੈ।" ਇਹ ਬਹੁਤ ਘੱਟ ਦਾਰਸ਼ਨਿਕ ਹੁੰਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਲਈ onboarding, offboarding, ਅਤੇ audit ਲਈ ਨਿਯੰਤਰਣ ਹੈ।
ਹੁਣ ਮੋੜ: ਤੁਸੀਂ ਦੋ ਟੀਮਾਂ ਨੂੰ ਵੇਚ ਰਹੇ ਹੋ। Team A OIDC ਨਾਲ ਖੁਸ਼ ਹੈ ਕਿਉਂਕਿ ਉਹ Okta ਨਾਲ ਆਧੁਨਿਕ apps ਵਰਤਦੇ ਹਨ। Team B SAML 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਨਾਂ ਦੇ legacy ਟੂਲ ਅਜੇ ਵੀ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹਨ। ਇੱਥੇ OAuth vs SAML ਦਾ ਸਵਾਲ ਬਹਿਸ ਨਹੀਂ ਰਹਿੰਦਾ; ਇਹ ਇੱਕ ਰੋਲਆਉਟ ਯੋਜਨਾ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਨਿਯਮ ਰੱਖੋ: SSO ਪ੍ਰਤੀ-ਟੈਨੈਂਟ ਲੌਗਿਨ ਵਿਕਲਪ ਹੈ, ਗਲੋਬਲ ਵਾਂਗੋਂ ਨਹੀਂ। ਮੌਜੂਦਾ ਯੂਜ਼ਰ ਪੁਰਾਣੇ ਤਰੀਕੇ ਨਾਲ ਲੌਗਿਨ ਕਰ ਸਕਦੇ ਹਨ ਜਦ ਤੱਕ ਟੈਨੈਂਟ ਐਡਮਿਨ "SSO required" ਨੂੰ ਓਨ ਨਹੀਂ ਕਰ ਦਿੰਦਾ।
ਪਹਿਲੀ SSO ਲੌਗਿਨ 'ਤੇ, ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਅਕਾਊਂਟ ਲਿੰਕਿੰਗ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇੱਕ ਸਾਫ਼ ਤਰੀਕਾ ਇਹ ਹੈ: verified email 'ਤੇ match ਕਰੋ, ਟੈਨੈਂਟ ਨੂੰ domain (ਜਾਂ ਇਨਵਾਈਟ) ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ IdP identity ਨੂੰ ਮੌਜੂਦਾ ਯੂਜ਼ਰ ਨਾਲ ਜੋੜੋ। ਜੇ ਕੋਈ ਮਿਲਾਅ ਨਹੀਂ ਹੈ, ਤਾਂ ਜਸਟ-ਇਨ-ਟਾਈਮ ਯੂਜ਼ਰ ਬਣਾਉ, ਪਰ ਸਿਰਫ਼ ਜੇ ਐਡਮਿਨ ਨੇ ਉਸਨੂੰ ਆਗਿਆ ਦਿੱਤੀ ਹੋਵੇ।
Role assignment ਅਕਸਰ ਡੀਲਾਂ ਨੂੰ ਅਟਕਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਸਧਾਰਨ ਰੱਖੋ: ਨਵੇਂ ਯੂਜ਼ਰਾਂ ਲਈ ਇੱਕ ਡੀਫਾਲਟ ਰੋਲ, ਅਤੇ IdP ਗਰੁੱਪਾਂ ਜਾਂ claims ਤੋਂ ਤੁਹਾਡੇ ਰੋਲਾਂ ਲਈ ਵਿਕਲਪਕ ਮੈਪਿੰਗ।
ਐਡਮਿਨ ਪਾਸੇ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਸੈਟਅਪ ਕਰਨਗੇ:
ਸਵਿੱਚ ਦੌਰਾਨ ਲੌਕਆਉਟ ਤੋਂ ਬਚਣ ਲਈ, SSO ਤੋਂ ਬਾਹਰ ਇੱਕ break-glass ਐਡਮਿਨ ਖਾਤਾ ਰੱਖੋ, ਪਹਿਲੀਆਂ ਕੁਝ ਲੌਗਇਨਾਂ ਲਈ test mode ਚਲਾਓ, ਅਤੇ ਕੇਵਲ ਇਕ ਪੁਸ਼ਟੀ ਕੀਤੀ ਹੋਈ ਐਡਮਿਨ ਸੈਸ਼ਨ ਤੋਂ ਬਾਅਦ SSO enforce ਕਰੋ।
ਬਹੁਤ ਸਾਰੇ SSO ਘਟਨਾਕ੍ਰਮ IdP ਵੱਲੋਂ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ ਐਪ SSO ਨੂੰ ਇੱਕ ਗਲੋਬਲ سਵਿੱਚ ਵਜੋਂ ਸਮਝਦੀ ਹੈ, ਨਾ ਕਿ ਪ੍ਰਤੀ-ਗਾਹਕ ਸੈਟਿੰਗ।
ਇੱਕ ਕਲਾਸਿਕ ਫੇਲਿਯਰ ਟੈਨੈਂਟ ਸੀਮਾਵਾਂ ਨੂੰ ਗੁਆਚਣਾ ਹੈ। ਇੱਕ ਨਵਾਂ IdP ਕਨਫਿਗ ਗਲੋਬਲੀ ਸੇਵ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅਚਾਨਕ ਹਰ ਗਾਹਕ ਨੂੰ ਤੁਹਾਡੀ ਆਖਰੀ IdP ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। IdP ਸੈਟਿੰਗਾਂ ਨੂੰ ਟੈਨੈਂਟ ਨਾਲ ਜੋੜੋ, ਅਤੇ SSO ਹੈਂਡਸ਼ੇਕ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਮੇਸ਼ਾ ਟੈਨੈਂਟ ਨੂੰ ਰਿਜ਼ਾਲਵ ਕਰੋ।
ਅਕਾਊਂਟ ਮੈਚਿੰਗ ਅਗਲਾ ਵੱਡਾ ਫੇਲ-ਪੋਇੰਟ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਈਮੇਲ 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਡੁਪਲਿਕੇਟ ਯੂਜ਼ਰ ਬਣਾਉਗੇ ਜਾਂ ਜਦੋਂ ਉਨਾਂ ਦੀ IdP ਈਮੇਲ ਪਹਿਲਾਂ ਵਰਤੇ ਗਏ ਈਮੇਲ ਤੋਂ ਵੱਖਰੀ ਹੋਵੇ ਤਾਂ ਅਸਲੀ ਯੂਜ਼ਰ ਨੂੰ ਬਾਹਰ ਰੱਖ ਦੇਵੋਗੇ। ਆਪਣੇ merge policy upfront ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਤੁਸੀਂ ਕਿਹੜੀਆਂ ਪਹਚਾਨਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ, ਈਮੇਲ ਬਦਲਣਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹੋ, ਅਤੇ ਕਿਵੇਂ ਐਡਮਿਨ engineering ਮਦਦ ਬਿਨਾਂ mismatch ਠੀਕ ਕਰ ਸਕਦੇ ਹਨ।
ਟੀਮਾਂ ਅਕਸਰ claims 'ਤੇ ਜ਼ਰਿਆਦਾ ਭਰੋਸਾ ਕਰਦੀਆਂ ਹਨ। ਜੋ ਤਤੱਵ ਤੁਸੀਂ ਵਾਪਸ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਉਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: issuer, audience, signature, ਅਤੇ ਇਹ ਕਿ email verified ਹੈ (ਜਾਂ ਇੱਕ ਸਥਿਰ subject identifier ਵਰਤੋ)। ਗਲਤ audience ਜਾਂ unverified email ਨੂੰ ਮੰਨ ਲੈਣਾ ਆਸਾਨ ਤਰੀਕੇ ਨਾਲ ਗਲਤ ਵਿਅਕਤੀ ਨੂੰ ਪਹੁੰਚ ਦੇ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਕੁਝ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, vague errors ਲੰਬੇ support calls ਬਣਾਉਂਦੇ ਹਨ। ਯੂਜ਼ਰ ਨੂੰ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਓ, ਅਤੇ ਐਡਮਿਨ ਨੂੰ diagnostic hint ਦਿਓ (ਉਦਾਹਰਨ: "Audience mismatch" ਜਾਂ "Certificate expired") ਬਿਨਾਂ secrets ਪਰਦਾਨ ਕੀਤੇ।
ਟਾਈਮ-ਸਬੰਧੀ ਮੁੱਦੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹਨ। ਘੜੀ ਦਾ ਸਕਿਊ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਰੋਟੇਸ਼ਨ ਸੋਮਵਾਰ ਸਵੇਰੇ 9 ਵਜੇ ਲੌਗਿਨ ਤੋੜ ਸਕਦੇ ਹਨ।
ਪੰਜ ਚੈੱਕ ਜਿਹੜੇ ਜ਼ਿਆਦਾਤਰ ਆਊਟੇਜਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ:
SSO ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿਥੇ ਛੋਟੇ ਅਨੁਮਾਨ ਵੱਡੇ ਸਪੋਰਟ ਟਿਕਟ ਬਣ ਜਾਂਦੇ ਹਨ। ਕਿਸੇ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਗਾਹਕ ਨੂੰ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਇਹ ਸਪੋਰਟ ਕਰਦੇ ਹੋ, ਇਹ ਯਕੀਨ ਬਣਾਓ ਕਿ ਬੁਨਿਆਦੀ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਨਾ ਕਿ सिर्फ ਡੈਮੋ ਵਿੱਚ।
ਇਨ੍ਹਾਂ ਨੂੰ ਇੱਕ staging environment ਵਿੱਚ ਚਲਾਓ ਜੋ production ਦਾ ਅਨੁਕਰਣ ਕਰਦਾ ਹੋਵੇ:
ਇੱਕ ਪੂਰਾ "ਬੁਰਾ ਦਿਨ" ਡ੍ਰਿਲ ਕਰੋ: ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਰੋਟੇਸ਼ਨ ਕਰੋ, ਇੱਕ claim ਬਦਲੋ, ਜਾਂ IdP URL ਨੂੰ ਤੋੜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪਛਾਣ ਸਕਦੇ ਹੋ।
ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ SSO ਫੇਲਿਊਰ (ਟੈਨੈਂਟ ਅਨੁਸਾਰ) ਲਈ ਮਾਨੀਟਰੀਂਗ ਅਤੇ alerts ਹਨ, ਅਤੇ ਇੱਕ rollback ਯੋਜਨਾ (feature flag, config revert, ਜਾਂ quick deploy) ਜੋ ਤੁਸੀਂ ਅਭਿਆਸ ਕਰ ਚੁਕੇ ਹੋ।
ਇੱਕ ਸਪਸ਼ਟ ਸ਼ੁਰੂਆਤੀ ਨੁਕਤਾ ਚੁਣੋ। ਵੱਧਤਰ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਖਰੀਦਦਾਰ "Okta/Entra ID ਨਾਲ SAML" ਜਾਂ "Google/Microsoft ਨਾਲ OIDC" ਮੰਗਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਹਫ਼ਤੇ ਦੇ ਪਹਿਲੇ ਹਿੱਸੇ ਵਿੱਚ ਦੋਹਾਂ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਜੇ ਤਕ ਤੁਸੀਂ ਟੀਮ ਨਹੀਂ ਰੱਖਦੇ। ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਕੀ ਸਪੋਰਟ ਕਰੋਂਗੇ (ਕੇਵਲ SAML, ਕੇਵਲ OIDC, ਜਾਂ ਦੋਹਾਂ) ਅਤੇ ਲਿਖੋ ਕਿ ਤੁਹਾਡੇ ਉਤਪਾਦ ਅਤੇ ਸਪੋਰਟ ਟੀਮ ਲਈ "ਕਿੱਥੇ ਤੱਕ ਮੁਕੰਮਲ" ਹੈ।
ਅਸਲ ਗਾਹਕ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਛੋਟਾ ਅੰਦਰੂਨੀ ਡੈਮੋ ਟੈਨੈਂਟ ਬਣਾਓ। ਇਸਤੇ SSO ਯੋਗ ਕਰਨਾ, ਲੌਗਿਨ ਟੈਸਟ ਕਰਨਾ, ਡੋਮੇਨ ਲਈ ਬੰਦ ਕਰਨਾ, ਅਤੇ ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਪਹੁੰਚ ਰਿਕਵਰ ਕਰਨਾ ਅਭਿਆਸ ਕਰੋ। ਇੱਥੇ ਤੁਹਾਡਾ support playbook ਵੀ ਟੈਸਟ ਹੁੰਦਾ ਹੈ।
ਇੱਕ enterprise requirements ਦਸਤਾਵੇਜ਼ ਰੱਖੋ ਜੋ ਜ਼ਿੰਦਾ ਰਹੇ। ਸਮੀਖਿਆਵਾਂ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਜਗ੍ਹਾ ਹੋਣ ਨਾਲ ਤੁਸੀਂ ਇੱਕ-ਵਾਰ-ਕੀਤੀਆਂ ਵਚਨਾਂ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ ਜੋ ਬਾਅਦ ਵਿਚ onboarding ਨੂੰ ਤੋੜ ਦੇਣ।
ਇੱਕ ਸਧਾਰਣ ਯੋਜਨਾ ਜੋ ਅਮਲ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ:
ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਡਕਟ ਪਾਸੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ Koder.ai (Koder.ai) ਵਿੱਚ settings screens ਅਤੇ ਟੈਨੈਂਟ ਸਾਂਚਾ ਪਹਿਲਾਂ prototype ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਗਾਹਕ ਸੁਰੱਖਿਆ ਪ੍ਰਸ਼ਨਾਵਲੀਆਂ ਆਉਣ ਨਾਲ iterate ਕਰਦੇ ਜਾਓ।
SSO ਤੋਂ ਬਾਅਦ ਆਮ ਤੌਰ 'ਤੇ ਜੋ ਐਡ-ਆਨ ਆਉਂਦੇ ਹਨ ਉਹਨਾਂ ਲਈ ਤਿਆਰੀ ਕਰੋ: SCIM provisioning, audit log exports, ਅਤੇ ਸਾਫ਼ ਪਰਮੀਸ਼ਨ ਵਾਲੇ ਐਡਮਿਨ ਰੋਲ। ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਤੁਰੰਤ ਸ਼ਿਪ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਵੀ ਖਰੀਦਦਾਰ ਪੁੱਛਣਗੇ, ਅਤੇ ਤੁਹਾਡਾ ਜਵਾਬ ਸਥਿਰ ਰਹੇ।
ਜ਼ਿਆਦਾਤਰ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਟੀਮਾਂ ਇੱਕ ਕੇਂਦ੍ਰਿਤ ਨਿਯੰਤਰਣ ਚਾਹੁੰਦੀਆਂ ਹਨ। SSO ਉਨਾਂ ਨੂੰ ਆਪਣੇ IdP 'ਤੇ MFA ਅਤੇ ਲੌਗਿਨ ਨੀਤੀਆਂ ਲਾਗੂ ਕਰਨ ਦਾ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ, ਕਿਸੇ ਦੇ ਜਾਂਦਿਆਂ ਪਹੁੰਚ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਹਟਾਉਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਆਡਿਟ ਦੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਬਗੈਰ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਪਾਸਵਰਡ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ 'ਤੇ ਨਿਰਭਰ ਹੋਏ।
ਉਹਨਾਂ ਦੇ IdP ਦੁਆਰਾ ਪਹਿਲਾਂ ਹੀ ਕੀ ਸਹਾਇਤਿਤ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੀ ਵੈਂਡਰ ਓਨਬੋਰਡਿੰਗ ਨੀਤੀ ਕੀ ਮੰਗਦੀ ਹੈ, ਇਹ ਜाँचੋ। OIDC ਆਧੁਨਿਕ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਫਲੋਜ਼ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਨਰਮ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ SAML ਅਕਸਰ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਪੁਰਾਣਾ ਅਤੇ ਵਿਸ਼ਵਾਸਯੋਗ ਮਾਪਦੰਡ ਹੈ।
OIDC ਇੱਕ authentication ਤਹ ਦਾ ਹੋਰ ਹੈ ਜੋ OAuth ਦੇ ਉੱਤੇ ਬਣਿਆ ਹੈ ਅਤੇ ਲੌਗਿਨ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ। OAuth ਖੁਦ APIs ਲਈ ਆਥਰਾਈਜ਼ੇਸ਼ਨ ਬਾਰੇ ਹੈ, ਨਾ ਕਿ ਇਸ ਗੱਲ ਦੀ ਗਰੰਟੀ ਕਰਨ ਬਾਰੇ ਕਿ ਯੂਜ਼ਰ ਕੌਣ ਹੈ। ਜੇ ਤੁਸੀਂ “ਸਾਇਨ ਇਨ ਵਿਥ ਕੰਪਨੀ IdP” ਲਾਗੂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ OIDC ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹੋ ਨਾ ਕਿ ਸਿਰਫ਼ ਕੱਚੇ OAuth ਦੀ।
ਨਹੀਂ। SSO ਸਾਇਨ-ਇਨ ਬਾਰੇ ਹੈ, ਜਦਕਿ SCIM ਯੂਜ਼ਰਾਂ (ਅਤੇ ਕੁਝ ਸਮੇਂ ਗਰੁੱਪਾਂ) ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਬਣਾਉਣ, ਅਪਡੇਟ ਅਤੇ ਅਯਕਟਿਵੇਟ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਆਮ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਸੈਟਅਪ ਵਿੱਚ SAML ਜਾਂ OIDC ਸਾਇਨ-ਇਨ ਲਈ ਹੈ ਅਤੇ SCIM ਆਫ਼ਬੋਰਡਿੰਗ ਅਤੇ ਰੋਲ ਬਦਲਾਅ ਨੂੰ ਮੈਨੂਅਲ ਕੰਮ ਤੋਂ ਬਚਾਉਣ ਲਈ ਹੁੰਦਾ ਹੈ।
SSO ਨੂੰ ਪ੍ਰਤੀ-ਟੈਨੈਂਟ ਸੈਟਿੰਗ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ, ਨਾ ਕਿ ਗਲੋਬਲ ਸਵਿੱਚ ਵਜੋਂ। ਪਹਿਲਾਂ ਟੈਨੈਂਟ ਨੂੰ ਰਿਜ਼ਾਲਵ ਕਰੋ (ਡੋਮੇਨ ਰੂਟਿੰਗ, ਇਨਵਾਈਟ, ਜਾਂ ਇਕ ਸਪਸ਼ਟ ਆਰਗ ਚੋਣ ਦੇ ਕੇ), ਫਿਰ ਉਸ ਟੈਨੈਂਟ ਦੇ IdP ਕਨਫਿਗ ਨਾਲ SSO ਹੈਂਡਸ਼ੇਕ ਸ਼ੁਰੂ ਕਰੋ। ਇਸ ਨਾਲ ਇੱਕ ਗਾਹਕ ਦੀ IdP ਸੈਟਿੰਗ ਦੂਜੇ ਗਾਹਕਾਂ ਦੀ ਲੌਗਿਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰੇਗੀ।
IdP ਵੱਲੋਂ ਮਿਲਣ ਵਾਲੇ ਇੱਕ ਸਥਿਰ ਪਹਚਾਨ-ਹੋਰ (ਜਿਵੇਂ OIDC sub ਜਾਂ SAML NameID) ਨੂੰ ਪ੍ਰਮੁੱਖ ਲਿੰਕ ਵਜੋਂ ਵਰਤੋ ਅਤੇ ਈਮੇਲ ਨੂੰ ਦੂਜੇ ਦਰਜੇ ਦੀ ਐਟ੍ਰਿਬਿਊਟ ਮੰਨੋ ਜੋ ਬਦਲ ਸਕਦੀ ਹੈ। ਪਹਿਲੀ SSO ਲੌਗਿਨ ਤੇ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਮੌਜੂਦਾ ਖਾਤੇ ਨਾਲ ਲਿੰਕ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਯਕੀਨ ਹੋ ਕਿ ਉਹੀ ਵਿਅਕਤੀ ਹੈ ਅਤੇ ਟੈਨੈਂਟ ਸਹੀ ਹੈ; ਨਹੀਂ ਤਾਂ ਇਨਵਾਈਟ ਜਾਂ ਐਡਮਿਨ ਪੁਸ਼ਟੀ ਮੰਗੋ।
ਇੱਕ break-glass ਐਡਮਿਨ ਖਾਤਾ ਰੱਖੋ ਜੋ SSO ਤੋਂ ਬਿਨਾਂ ਸਾਈਨ ਇਨ ਕਰ ਸਕੇ, ਅਤੇ ਇੱਕ ਐਡਮਿਨ ਦੇ ਕੰਮ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਤੱਕ SSO ਨੂੰ opt-in ਰੱਖੋ। ਨਾਲ ਹੀ ਇੱਕ ਸਿੰਗਲ ਟੌਗਲ ਦਿਓ ਜੋ ਉਸ ਟੈਨੈਂਟ ਲਈ SSO ਨੂੰ ਬੰਦ ਕਰ ਸਕੇ ਤਾਂ ਕਿ IdP ਬਿਗੜਣ 'ਤੇ support ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚ ਨੂੰ بحال ਕਰ ਸਕੇ ਬਿਨਾਂ ਕੋਡ ਬਦਲਣ ਦੇ।
ਆਪਣੇ ਐਪ ਵਿੱਚ ਸਥਾਨਕ ਲੌਗਆਉਟ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਓ ਅਤੇ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਗਲੋਬਲ ਸਾਈਨ-ਆਊਟ ਹਰ ਐਪ 'ਤੇ IdP ਦੀਆਂ ਖ਼ਾਸੀਅਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਦੀਨ-ਭੇਦ ਦੇ ਕੰਮਾਂ ਲਈ (ਜਿਵੇਂ ਡਾਟਾ ਐਕਸਪੋਰਟ ਜਾਂ ਬਿਲਿੰਗ ਬਦਲਣਾ) ਖਤਰੇ-ਵਾਲੇ ਐਕਸ਼ਨਾਂ 'ਤੇ step-up ਚੈੱਕਸ ਦਾ ਸਹਿਯੋਗ ਰੱਖੋ, ਕਿਉਂਕਿ ਹਰ IdP नीति ਪੂਰੀ ਨਹੀਂ ਹੋ ਸਕਦੀ।
ਟੋਕਨ ਜਾਂ ਅਸਰਸ਼ਨ ਸਮੱਗਰੀ ਨੂੰ ਰਿਕਾਰਡ ਨਾ ਕਰਦੇ ਹੋਏ ਮੁਸ਼ਕਲਾਂ ਦਾ ਨਿਰਾਕਰਨ ਕਰਨ ਯੋਗ ਲੌਗ ਰੱਖੋ: ਇੱਕ correlation ID, ਟੈਨੈਂਟ, issuer/entity ID, ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਸਪਸ਼ਟ ਕਾਰਨ ਜਿਵੇਂ signature failure, audience mismatch ਜਾਂ expired certificate. ਕੱਚੇ ਟੋਕਨ, ਪੂਰੀ SAML assertions, client secrets ਜਾਂ ਪ੍ਰਾਈਵੇਟ ਕੀਜ਼ ਨੂੰ ਲੌਗ ਨਾ ਕਰੋ।
ਟੈਨੈਂਟ-ਪੱਧਰੀ ਕਨਫਿਗ ਸਟੋਰੇਜ, ਇੱਕ ਐਡਮਿਨ UI IdP ਸੈਟਿੰਗਾਂ ਲਈ, ਸੁਰੱਖਿਅਤ ਅਕਾਊਂਟ-ਲਿੰਕਿੰਗ ਨਿਯਮ, ਅਤੇ ਇਕ ਰੋਲਬੈਕ ਰਸਤਾ ਜ਼ਰੂਰੀ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਟੈਨੈਂਟ ਮਾਡਲ ਸ਼ੁਰੂ ਤੋਂ ਯੋਜਨਾ ਬਣਾਓ ਅਤੇ ਰੋਲਆਉਟ ਦੌਰਾਨ snapshots ਅਤੇ rollback ਵਰਤੋ ਤਾਂ ਕਿ ਕੋਈ ਗਲਤ ਬਦਲਾਅ ਹਰ ਗਾਹਕ ਨੂੰ ਲੌਗ ਆਊਟ ਨਾ ਕਰ ਦੇਵੇ।