ਇੱਕ OTP Wi-Fi, VPN ਅਤੇ ਰਜਿਸਟਰੀ ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਢਕ ਸਕਦਾ
Wi-Fi ਦਾਖਲਾ, VPN ਦਾਖਲਾ ਅਤੇ ਰਜਿਸਟਰੀ ਹਰ ਇੱਕ ਆਪਣੇ ਦਰਸ਼ਕਾਂ ਅਤੇ ਆਯੂ ਨਾਲ ਵੱਖਰਾ ਵਟਾਂਦਰਾ ਚਲਾਉਂਦਾ ਹੈ। ਖਾਤਾ ਸਾਂਝਾ ਕਰਨਾ ਟੋਕਨ ਸਾਂਝਾ ਕਰਨਾ ਨਹੀਂ ਹੈ।
ਸਿੰਗਲ ਸਾਈਨ-ਆਨ ਇੱਕ ਪਛਾਣ ਅਤੇ ਘੱਟ ਪੁੱਛਗਿੱਛ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਵਾਅਦਾ ਤੀਜੇ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਜਾਲ ਇਹ ਮੰਨਣਾ ਹੈ ਕਿ ਇੱਕ ਸਫਲ ਪ੍ਰਮਾਣਿਕਤਾ ਅਜਿਹਾ ਟੋਕਨ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਹਰ ਦੂਜਾ ਪ੍ਰੋਟੋਕੋਲ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ। Wi-Fi ਦਾਖਲਾ, VPN ਦਾਖਲਾ ਅਤੇ ਕੰਟੇਨਰ ਰਜਿਸਟਰੀ ਹਰ ਇੱਕ ਵੱਖਰਾ ਵਟਾਂਦਰਾ ਚਲਾਉਂਦਾ ਹੈ, ਵੱਖਰੇ ਦਰਸ਼ਕਾਂ ਅਤੇ ਆਯੂ ਨਾਲ। ਖਾਤਾ ਸਾਂਝਾ ਕਰਨਾ ਡਾਇਰੈਕਟਰੀ ਦਾ ਫੈਸਲਾ ਹੈ; ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸਾਂਝਾ ਕਰਨਾ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਕਦੇ-ਕਦਾਈਂ ਹੀ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ।
ਤਿੰਨ ਵਟਾਂਦਰੇ, ਤਿੰਨ ਮਾਲਕ
ਐਂਟਰਪ੍ਰਾਈਜ਼ Wi-Fi 802.1X ਦੇ ਅੰਦਰ EAP ਢੰਗ ਚਲਾਉਂਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਵਰਤੋਂਕਾਰ ਜਾਂ ਡਿਵਾਈਸ ਬਾਰੇ ਆਪਣਾ ਨਜ਼ਰੀਆ ਰੱਖਣ ਵਾਲੀ RADIUS ਸੇਵਾ ਇਸਨੂੰ ਖਤਮ ਕਰਦੀ ਹੈ। VPN ਗੇਟਵੇ ਆਪਣੇ ਸਮਰਥਿਤ ਪ੍ਰਵਾਹ ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਆਪਣੇ ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਟਾਈਮਰ ਵਾਲਾ ਸੈਸ਼ਨ ਰੱਖਦਾ ਹੈ। ਰਜਿਸਟਰੀ ਬਿਨਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਵਾਲੀ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਟੋਕਨ ਸੇਵਾ, ਦਰਸ਼ਕ ਅਤੇ ਦਾਇਰਾ ਦੱਸਣ ਵਾਲੀ ਚੁਣੌਤੀ ਨਾਲ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਆਪਣੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨੂੰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਾਲੇ ਟੋਕਨ ਨਾਲ ਬਦਲਦਾ ਹੈ।
ਇਹ ਇੱਕ ਸੈਸ਼ਨ ਦੇ ਤਿੰਨ ਦ੍ਰਿਸ਼ ਨਹੀਂ ਹਨ। ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ ਸਤਿਆਪਕ, ਆਪਣੀ ਆਯੂ ਅਤੇ ਆਪਣਾ ਰੱਦ ਕਰਨ ਦਾ ਮਾਰਗ ਹੈ, ਇਸ ਲਈ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਪਾਸਵਰਡ ਬਦਲਣ ਨਾਲ ਇੱਕ ਚੱਲਦਾ ਅਤੇ ਦੂਜਾ ਟੁੱਟਿਆ ਰਹਿ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਸੰਜੋਗ ਨਾਲ ਇੱਕ ਵਰਤੋਂਕਾਰ ਡਾਇਰੈਕਟਰੀ ਸਾਂਝੀ ਕਰਨ ਵਾਲੇ ਤਿੰਨ ਏਕੀਕਰਨ ਮੰਨੋ।
ਬ੍ਰਾਊਜ਼ਰ SSO ਕੀ ਢੋਂਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
ਪਛਾਣ ਪ੍ਰਦਾਤਾ 'ਤੇ ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਸੱਚਮੁੱਚ ਲਾਹੇਵੰਦ ਹੈ: ਉੱਥੇ ਰੀਡਾਇਰੈਕਟ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਪੂਰਾ ਕੀਤਾ ਲੌਗਇਨ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ। ਇਹ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਐਪਲੀਕੇਸ਼ਨਾਂ ਉਹੀ ਰੀਡਾਇਰੈਕਟ ਅਤੇ ਟੋਕਨ ਪ੍ਰੋਟੋਕੋਲ ਬੋਲਦੀਆਂ ਹਨ ਅਤੇ ਉਹੀ ਦਰਸ਼ਕ ਸਵੀਕਾਰ ਕਰਦੀਆਂ ਹਨ। EAP ਬੋਲਣ ਵਾਲੇ ਬੇਨਤੀਕਰਤਾ ਕੋਲ ਪਿੱਛਾ ਕਰਨ ਲਈ ਕੋਈ ਰੀਡਾਇਰੈਕਟ ਨਹੀਂ ਹੈ, ਅਤੇ ਰਜਿਸਟਰੀ ਚੁਣੌਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ Docker ਕਲਾਇੰਟ OIDC ਪਛਾਣ ਟੋਕਨ ਨਹੀਂ ਮੰਗਦਾ। ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਸਿਰਫ਼ ਉਹਨਾਂ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਜ਼ਮਾਨਤ ਦੇ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਲਈ ਉਹ ਬਣਾਇਆ ਗਿਆ ਹੈ।
ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ ਪਤਾ ਹੋਣ 'ਤੇ ਲੌਗਾਂ ਵਿੱਚ ਅਸਫਲਤਾ ਵੇਖਣੀ ਸੌਖੀ ਹੈ। ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਸਫਲ ਲੌਗਇਨ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ Wi-Fi ਜੁੜਾਅ ਅਜੇ ਵੀ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਕਦੇ ਨਾ ਵੇਖੀ ਟੋਕਨ ਵਟਾਂਦਰੇ ਤੋਂ ਬਾਅਦ ਰਜਿਸਟਰੀ 401 ਵਾਪਸ ਕਰਦੀ ਹੈ। ਦੋ ਸਫਲਤਾਵਾਂ ਅਤੇ ਇੱਕ ਅਸਫਲਤਾ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ ਹਨ; ਇਹ ਤਿੰਨ ਵੱਖਰੇ ਪ੍ਰਮਾਣੀਕਰਨ ਹਨ।
ਜਿੱਥੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦੁਹਰਾਇਆ ਕੋਡ ਬਦਲਦਾ ਹੈ
ਪ੍ਰਬੰਧਿਤ ਡਿਵਾਈਸਾਂ ਲਈ, ਪ੍ਰਮਾਣ-ਪੱਤਰ ਅਧਾਰਿਤ EAP ਪਛਾਣ ਹਟਾਏ ਬਿਨਾਂ ਮਨੁੱਖੀ ਕਦਮ ਹਟਾਉਂਦਾ ਹੈ: ਡਿਵਾਈਸ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਪੇਸ਼ ਕਰਦਾ ਹੈ, RADIUS ਸੇਵਾ ਇਸਨੂੰ ਜਾਰੀ ਕਰਨ ਵਾਲੀ ਅਥਾਰਟੀ ਕੋਲ ਜਾਂਚਦੀ ਹੈ, ਅਤੇ ਰੱਦ ਕਰਨਾ ਉਸੇ ਅਥਾਰਟੀ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਸਾਂਝੇ ਭੇਤ ਵਿੱਚ ਨਹੀਂ। ਕੀਮਤ ਜੀਵਨ-ਚੱਕਰ ਦਾ ਕੰਮ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਖਤਮ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਨਵੀਨੀਕਰਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਰਜਿਸਟਰੀਆਂ ਵਿੱਚ ਵੀ ਬਰਾਬਰ ਵੰਡ ਹੈ। ਇੰਟਰਐਕਟਿਵ ਵਰਤੋਂਕਾਰ ਇੱਕ ਵਾਰ ਲੌਗਇਨ ਕਰਕੇ ਨਤੀਜਾ ਟੋਕਨ ਨੂੰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸਹਾਇਕ ਸੰਗ੍ਰਹਿ ਕਰਨ ਦੇ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਤੰਗ ਦਾਇਰੇ ਵਾਲਾ ਸੇਵਾ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜਾਂ ਵਰਕਲੋਡ ਪਛਾਣ ਵਰਤਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਨਕਲ ਕੀਤਾ ਮਨੁੱਖ ਦਾ ਇੱਕ-ਵਾਰੀ ਕੋਡ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਸਹਾਇਕ ਕਿਸੇ ਖਾਸ ਰਜਿਸਟਰੀ ਦਰਸ਼ਕ ਲਈ ਟੋਕਨ ਸੰਗ੍ਰਹਿ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸੰਰਚਨਾ ਫ਼ਾਈਲ ਸੋਧ ਕੇ ਇਸਨੂੰ VPN ਗੇਟਵੇ ਵੱਲ ਨਹੀਂ ਮੋੜਿਆ ਜਾ ਸਕਦਾ।
docker login registry.example.comਰੱਖ-ਰਖਾਅ ਖਰਚ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਪੁੱਛਗਿੱਛ ਦੀ ਗਿਣਤੀ ਦੀ ਨਹੀਂ
ਸਾਂਝਾ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸਸਤਾ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਕੰਮ ਅਸਫਲ ਹੋਣ ਤੱਕ ਅਦਿੱਖ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਦੀ ਥਾਂ ਗਿਣੋ ਕਿ ਹਰ ਵਿਕਲਪ ਇੱਕ ਸਾਲ ਵਿੱਚ ਕੀ ਖਰਚ ਕਰਦਾ ਹੈ: ਦਾਖਲਾ, ਨਵੀਨੀਕਰਨ, ਰੱਦ ਕਰਨਾ, ਲੀਕ ਦਾ ਪ੍ਰਭਾਵ-ਘੇਰਾ ਅਤੇ ਕੋਈ ਜਾਣ ਵੇਲੇ ਛੋਹੇ ਜਾਣ ਵਾਲੇ ਸਿਸਟਮਾਂ ਦੀ ਗਿਣਤੀ। ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦਾ ਬੇੜਾ ਬਣਾਉਣ ਵਿੱਚ ਵੱਧ ਅਤੇ ਪੈਮਾਨੇ 'ਤੇ ਚਲਾਉਣ ਵਿੱਚ ਘੱਟ ਖਰਚ ਕਰਦਾ ਹੈ; ਨਕਲ ਕੀਤਾ ਕੋਡ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਅਤੇ ਸੁਲਝਾਉਣ ਵਿੱਚ ਸਭ ਕੁਝ ਖਰਚ ਕਰਦਾ ਹੈ।
ਫਿਰ ਵਿਸ਼ਵਵਿਆਪੀ ਨਹੀਂ, ਹਰ ਹਿੱਸੇ ਲਈ ਚੁਣੋ। Wi-Fi ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਵੱਲ ਜਾ ਸਕਦਾ ਹੈ, VPN MFA ਨਾਲ ਸਮਰਥਿਤ SSO ਰੱਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਰਜਿਸਟਰੀ ਸਪਸ਼ਟ ਦਾਇਰਿਆਂ ਵਾਲੇ ਟੋਕਨ ਵਰਤ ਸਕਦੀ ਹੈ। ਹਰ ਇੱਕ ਲਈ ਮਾਲਕ, ਦਰਸ਼ਕ, ਦਾਇਰਾ, ਸਮਾਪਤੀ ਅਤੇ ਰੱਦ ਕਰਨ ਦਾ ਮਾਰਗ ਦਰਜ ਕਰੋ, ਅਤੇ ਪੁੱਛਗਿੱਛ ਇੱਕੋ ਸਮੇਂ ਹਰ ਥਾਂ ਨਹੀਂ, ਸਗੋਂ ਲੋੜੀਂਦੀ ਥਾਂ 'ਤੇ ਪਵੇਗੀ। ਉਹ ਦਰਜ ਉਦੋਂ ਵੀ ਜਵਾਬ ਹੈ ਜਦੋਂ ਲੇਖਾ-ਪਰੀਖਿਅਕ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਸਿਸਟਮ ਅਜੇ ਵੀ ਪਾਸਵਰਡ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ।