ਕੀ VPN SSO ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਐਪਾਂ ਵਿੱਚ ਆਪਣੇ ਆਪ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ?
ਇੱਕ ਸਾਈਨ-ਇਨ ਟਨਲ ਅਤੇ ਇਸ ਪਿੱਛੇ ਦੀਆਂ ਐਪਾਂ ਨੂੰ ਕਵਰ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਤਦ ਜਦੋਂ ਹਰ ਐਪ ਦਾ ਆਪਣਾ ਭਰੋਸਾ ਹੋਵੇ। ਇਸਨੂੰ ਜੋੜਨ ਅਤੇ ਪਰਖਣ ਦਾ ਕ੍ਰਮ ਇਹ ਹੈ।
ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਨ ਵਾਲਾ VPN ਗੇਟਵੇ ਸਿਰਫ਼ ਇੱਕ ਗੱਲ ਸਾਬਤ ਕਰਦਾ ਹੈ: ਪ੍ਰਦਾਤਾ ਨੇ ਗੇਟਵੇ ਸਾਹਮਣੇ ਇੱਕ ਵਰਤੋਂਕਾਰ ਦੀ ਜ਼ਮਾਨਤ ਦਿੱਤੀ ਹੈ। ਇਹ ਉਸ ਵਰਤੋਂਕਾਰ ਨੂੰ ਇੰਟਰਾਨੈੱਟ ਵਿਕੀ, ਨਿਗਰਾਨੀ ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਬਿਲਡ ਸਰਵਰ ਲਈ ਕੋਈ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨਹੀਂ ਦਿੰਦਾ। ਉਹ ਸੇਵਾਵਾਂ ਲੋਕਾਂ ਨੂੰ ਆਪਣੇ ਫੈਡਰੇਸ਼ਨ ਰਾਹੀਂ ਸਾਈਨ ਇਨ ਕਰਵਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਆਪਣਾ ਅਧਿਕਾਰ ਲਾਗੂ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਟਨਲ ਸਿਰਫ਼ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਪੈਕਟ ਉਨ੍ਹਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ।
ਤਿੰਨ ਸੈਸ਼ਨ, ਤਿੰਨ ਵੱਖਰੇ ਫ਼ੈਸਲੇ
ਸਥਿਤੀਆਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ, ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਆਪਣੇ ਟਾਈਮ-ਟੇਬਲ ਅਨੁਸਾਰ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ। VPN ਸੈਸ਼ਨ ਗੇਟਵੇ ਵੱਲੋਂ ਪਛਾਣ ਦੀ ਸਵੀਕ੍ਰਿਤੀ ਅਤੇ ਉਸ ਵੱਲੋਂ ਦਿੱਤੀ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਹੈ। ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਵਿੱਚ ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਉਹ ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਉਸ ਪ੍ਰਦਾਤਾ ਲਈ ਅਜੇ ਵੀ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਸ ਦੀ ਨੀਤੀ ਅਨੁਸਾਰ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦਾ ਹੈ। ਐਪ ਸੈਸ਼ਨ ਉਸ ਇੱਕ ਸੇਵਾ ਦਾ ਹੈ ਜਿਸਨੇ ਆਪਣੇ ਵੱਲ ਭੇਜੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਹੈ।
ਇਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਗ਼ਲਤ ਸਵਾਲ ਬਣਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਟਨਲ ਵਰਤੋਂਕਾਰ ਨੂੰ ਹਰ ਥਾਂ ਸਾਈਨ ਇਨ ਕਿਉਂ ਨਹੀਂ ਕਰਦਾ। ਇਸਨੂੰ ਮੁੜ ਲਿਖੋ: ਕਿਸ ਐਪ ਕੋਲ ਫੈਡਰੇਸ਼ਨ ਐਂਟਰੀ ਨਹੀਂ ਹੈ, ਕਿਹੜੀ ਵਰਤੋਂਕਾਰ ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੀ ਵਿੱਚ ਰੂਟ ਨਹੀਂ ਹੈ। ਇੰਟਰਾਨੈੱਟ ਐਪ ਖੋਲ੍ਹਣ ਵਾਲਾ ਇੱਕ ਹੀ ਸਾਈਨ-ਇਨ ਪ੍ਰੋਂਪਟ ਫਿਰ ਵੀ ਪ੍ਰਦਾਤਾ ਵੱਲ ਵਾਪਸ ਜਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਦੂਜਾ ਰੀਡਾਇਰੈਕਟ ਵੱਖਰੇ ਦਰਸ਼ਕਾਂ ਲਈ ਨਵੀਂ ਅਧਿਕਾਰ ਬੇਨਤੀ ਹੈ।
ਗੇਟਵੇ ਨੂੰ ਇਸਦੀ ਆਪਣੀ ਐਪ ਵਜੋਂ ਜੋੜੋ
VPN ਨੂੰ ਪ੍ਰਦਾਤਾ ਵਿੱਚ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਐਪ ਵਜੋਂ ਰਜਿਸਟਰ ਕਰੋ, ਇਸਦੇ ਆਪਣੇ ਪਛਾਣਕਰਤਾ, ਰੀਡਾਇਰੈਕਟ URI ਅਤੇ ਵਰਤੋਂਕਾਰ ਅਲਾਟਮੈਂਟ ਨਾਲ। ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਉਹ ਲੌਗਇਨ ਕਿਹੜੇ ਨੈੱਟਵਰਕ ਅਧਿਕਾਰ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ VPN ਨੀਤੀ ਹੈ, ਪ੍ਰਦਾਤਾ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ। ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ਼ ਨਿਗਰਾਨੀ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰੀ ਗੇਟਵੇ ਨੀਤੀ ਮਿਲਦੀ ਹੈ, ਵੱਖਰਾ ਪਾਸਵਰਡ ਨਹੀਂ।
ਟਨਲ ਦਾ ਪ੍ਰਮਾਣਿਕਤਾ ਜਵਾਬ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨਹੀਂ ਹੈ। OIDC ID ਟੋਕਨ ਵਿੱਚ ਦਰਸ਼ਕ ਦਾਅਵਾ ਹੁੰਦਾ ਹੈ ਜੋ ਉਸ ਕਲਾਇੰਟ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ ਜਿਸ ਲਈ ਉਹ ਜਾਰੀ ਹੋਏ ਸਨ, ਅਤੇ SAML ਬਿਅਰਰ ਬਿਆਨ ਦਰਸ਼ਕਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਤੱਕ ਸੀਮਿਤ ਕਰਦੇ ਹਨ। ਪਹਿਲੀ ਸੇਵਾ ਦਾ ਜਵਾਬ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੀ ਦੂਜੀ ਸੇਵਾ ਗ਼ਲਤ ਸੰਰਚਿਤ ਹੈ, ਅਤੇ ਟੋਕਨ ਨੂੰ ਦੂਜੀ ਐਪ ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ ਏਕੀਕਰਨ ਨਹੀਂ ਹੈ।
ਹਰ ਅੰਦਰੂਨੀ ਐਪ ਰਜਿਸਟਰ ਕਰੋ, ਫਿਰ ਬ੍ਰਾਊਜ਼ਰ ਸੰਦਰਭ ਸੈੱਟ ਕਰੋ
ਹਰ ਸੇਵਾ ਨੂੰ ਸਮਰਥਿਤ SAML ਜਾਂ OIDC ਮੁੱਲ ਚਾਹੀਦੇ ਹਨ: ਜਾਰੀਕਰਤਾ, ਕਲਾਇੰਟ ਪਛਾਣਕਰਤਾ, ਕਾਲਬੈਕ ਜਾਂ ਬਿਆਨ-ਖਪਤਕਾਰ URL, ਲੋੜੀਂਦੇ ਦਾਅਵੇ ਅਤੇ ਅਲਾਟਮੈਂਟ। ਪਹੁੰਚ ਇਸਦੇ ਉੱਪਰ ਆਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਪਛਾਣ ਜਾਂਚਾਂ ਕਦੇ ਵੀ ਰੂਟ ਜਾਂ DNS ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀਆਂ।
- ਐਪ ਐਂਟਰੀ ਬਣਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਂਟਿਟੀ ਜਾਂ ਕਲਾਇੰਟ ID ਐਪ ਵੱਲੋਂ ਭੇਜੇ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।
- ਸਕੀਮ ਅਤੇ ਪੋਰਟ ਸਮੇਤ ਸਹੀ ਕਾਲਬੈਕ URL ਰਜਿਸਟਰ ਕਰੋ; ਥੋੜ੍ਹੀ ਗ਼ਲਤੀ ਵਰਤੋਂਕਾਰ ਦੇ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਬਾਅਦ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ।
- ਵਰਤੋਂਕਾਰ ਜਾਂ ਸਮੂਹ ਅਲਾਟ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਲੋੜੀਂਦੇ ਦਾਅਵੇ ਜਾਰੀ ਹੁੰਦੇ ਹਨ।
- ਨਿੱਜੀ ਐਪ ਦੇ ਨਾਲ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਦੇ ਐਂਡਪੁਆਇੰਟਾਂ ਨੂੰ ਵੀ ਮਨਜ਼ੂਰੀ ਦਿਓ, ਨਹੀਂ ਤਾਂ ਰੀਡਾਇਰੈਕਟ ਪੂਰਾ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਬ੍ਰਾਊਜ਼ਰ ਸੰਦਰਭ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਮੌਜੂਦਾ ਪ੍ਰਦਾਤਾ ਸੈਸ਼ਨ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾਵੇਗਾ ਜਾਂ ਨਹੀਂ। ਸਿਸਟਮ ਬ੍ਰਾਊਜ਼ਰ ਖੋਲ੍ਹਣ ਵਾਲਾ ਨੇਟਿਵ ਕਲਾਇੰਟ ਉਹ ਸਥਿਤੀ ਸਾਂਝੀ ਕਰ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਆਪਣੇ ਕੂਕੀ ਜਾਰ ਵਾਲਾ ਐਂਬੈਡਿਡ ਵਿਊ ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਨਵਾਂ ਬ੍ਰਾਊਜ਼ਰ, ਨਿੱਜੀ ਵਿੰਡੋ ਅਤੇ ਦੂਜੀ ਪ੍ਰੋਫ਼ਾਈਲ ਸਿਫ਼ਰ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਜੋ ਉਮੀਦ ਅਨੁਸਾਰ ਹੈ, ਟੁੱਟਿਆ SSO ਸੰਰਚਨਾ ਨਹੀਂ।
ਪ੍ਰਵਾਹ ਚਲਾਓ ਅਤੇ ਪੜ੍ਹੋ ਕਿ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ
ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਨੈੱਟਵਰਕ ਪੈਨਲ ਨਾਲ ਮੁੜ ਪੈਦਾ ਕਰੋ ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਚੇਨ ਦੇਖੋ। ਲਾਹੇਵੰਦ ਸਫ਼ਰ ਇੱਕ ਸਮੇਂ ਇੱਕ ਛਾਲ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ: ਗੇਟਵੇ ਤੋਂ ਪ੍ਰਦਾਤਾ ਤੱਕ, ਪ੍ਰਦਾਤਾ ਤੋਂ ਕੋਡ ਜਾਂ ਬਿਆਨ ਸਮੇਤ ਐਪ ਤੱਕ, ਐਪ ਤੋਂ ਪ੍ਰਦਾਤਾ ਦੇ ਟੋਕਨ ਐਂਡਪੁਆਇੰਟ ਤੱਕ, ਐਪ ਸੈਸ਼ਨ ਜਾਰੀ। ਜਿੱਥੇ ਚੇਨ ਰੁਕਦੀ ਹੈ ਉਹ ਛਾਲ ਸੁਧਾਰਨ ਵਾਲੇ ਹਿੱਸੇ ਦਾ ਨਾਮ ਦਿੰਦੀ ਹੈ।
ਕਮਾਂਡ ਲਾਈਨ ਦੀਆਂ ਦੋ ਜਾਂਚਾਂ ਆਮ ਸ਼ੱਕ ਦੂਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਐਡਮਿਨ ਹੋਸਟ ਤੋਂ ਚਲਾਉਣਾ ਸੁਰੱਖਿਅਤ ਹੈ:
curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'ਜਦੋਂ ਮੈਟਾਡੇਟਾ ਉਹ ਐਂਡਪੁਆਇੰਟ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਰਜਿਸਟਰ ਨਹੀਂ ਕੀਤੇ, ਐਪ ਕਿਸੇ ਹੋਰ ਟੈਨੈਂਟ ਜਾਂ ਜਾਰੀਕਰਤਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਹੈ। ਜਦੋਂ ਐਪ ਨੂੰ ਪਹਿਲੀ ਬੇਨਤੀ ਅਣਕਿਆਸੇ ਹੋਸਟ ਨੂੰ 302 ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਦੇਖਣ ਦੀ ਥਾਂ ਐਪ ਦੀ ਫੈਡਰੇਸ਼ਨ ਸੰਰਚਨਾ ਹੈ, VPN ਪ੍ਰੋਫ਼ਾਈਲ ਨਹੀਂ।
ਕਿਸਨੇ ਮੰਗਿਆ ਇਹ ਲੱਭ ਕੇ ਪ੍ਰੋਂਪਟ ਸੁਧਾਰੋ
ਦੂਜਾ ਪਾਸਵਰਡ ਪ੍ਰੋਂਪਟ ਆਪਣੇ ਆਪ ਨੁਕਸ ਨਹੀਂ ਹੈ। ਐਪ ਉੱਚਾ ਭਰੋਸਾ ਪੱਧਰ ਮੰਗ ਸਕਦੀ ਹੈ, ਜਾਂ ਪ੍ਰਦਾਤਾ ਵੱਧ ਤੋਂ ਵੱਧ ਸੈਸ਼ਨ ਉਮਰ ਅਤੇ ਨਵੀਂ ਚੁਣੌਤੀ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ. ਪ੍ਰਵਾਹ ਨੂੰ ਸ਼ਾਂਤ ਕਰਨ ਲਈ ਉਹ ਲੋੜਾਂ ਹਟਾਉਣਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਰੱਖੇ ਨਿਯੰਤਰਣ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਨੀਤੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ ਨੇ ਮੰਗਿਆ।
ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਕੀ ਸੁਧਾਰਨਾ ਹੈ। ਜੇ ਪ੍ਰੋਂਪਟ ਐਪ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਫੈਡਰੇਸ਼ਨ ਐਂਟਰੀ ਸੁਧਾਰੋ। ਜੇ ਨੀਤੀ ਅਨੁਸਾਰ ਪ੍ਰਦਾਤਾ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਲੋੜ ਦਰਜ ਕਰੋ। ਜੇ ਸਫਲ ਸਾਈਨ-ਇਨ ਤੋਂ ਬਾਅਦ ਐਪ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ, ਤਾਂ ਟਨਲ ਦੀ ਰੂਟਿੰਗ ਸ਼ੱਕੀ ਹੈ, ਕਿਉਂਕਿ ਪਛਾਣ ਅਤੇ ਪੈਕਟ ਡਿਲੀਵਰੀ ਵੱਖਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੀ ਸੀਟ ਤੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ।