VPN SSO ಬಳಕೆದಾರರನ್ನು ಆಂತರಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೈನ್ ಇನ್ ಮಾಡುತ್ತದೆಯೇ?
ಒಂದು ಸೈನ್-ಇನ್ ಸುರಂಗ ಮತ್ತು ಅದರ ಹಿಂದಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಆವರಿಸಬಹುದು, ಆದರೆ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೂ ತನ್ನದೇ ನಂಬಿಕೆ ಇದ್ದಾಗ ಮಾತ್ರ. ಅದನ್ನು ಜೋಡಿಸುವ ಮತ್ತು ಪರೀಕ್ಷಿಸುವ ಕ್ರಮ ಇಲ್ಲಿದೆ.
ಗುರುತಿನ ಪೂರೈಕೆದಾರರ ಮೂಲಕ ದೃಢೀಕರಣ ಮಾಡುವ VPN ಗೇಟ್‌ವೇ ಒಂದು ವಿಷಯವನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ: ಪೂರೈಕೆದಾರರು ಗೇಟ್‌ವೇ ಮುಂದೆ ಒಬ್ಬ ಬಳಕೆದಾರರಿಗೆ ಖಾತರಿ ನೀಡಿದ್ದಾರೆ. ಅದು ಆ ಬಳಕೆದಾರರಿಗೆ ಇಂಟ್ರಾನೆಟ್ ವಿಕಿ, ಮೇಲ್ವಿಚಾರಣಾ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅಥವಾ build ಸರ್ವರ್‌ಗೆ ಯಾವುದೇ ರಹಸ್ಯಪತ್ರ ನೀಡುವುದಿಲ್ಲ. ಆ ಸೇವೆಗಳು ಜನರನ್ನು ತಮ್ಮದೇ ಒಕ್ಕೂಟದ ಮೂಲಕ ಸೈನ್ ಇನ್ ಮಾಡಿಸಿ ತಮ್ಮದೇ ಅಧಿಕಾರವನ್ನು ಅನ್ವಯಿಸುತ್ತವೆ, ಮತ್ತು ಸುರಂಗವು ಯಾವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಅವರನ್ನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ.
ಮೂರು ಅವಧಿಗಳು, ಮೂರು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು
ಸ್ಥಿತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ವೇಳಾಪಟ್ಟಿಯಂತೆ ಮುಗಿಯುತ್ತದೆ. 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 ಪ್ರೊಫೈಲ್ ಅಲ್ಲ.
ಯಾರು ಕೇಳಿದರು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿದು ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಸರಿಪಡಿಸಿ
ಎರಡನೇ ಗುಪ್ತಪದ ಪ್ರಾಂಪ್ಟ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ದೋಷ ಅಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಹೆಚ್ಚಿನ ಭರವಸೆ ಮಟ್ಟವನ್ನು ಕೇಳಬಹುದು, ಅಥವಾ ಪೂರೈಕೆದಾರರು ಗರಿಷ್ಠ ಅವಧಿ ವಯಸ್ಸು ಮತ್ತು ಹೊಸ ಸವಾಲನ್ನು ವಿಧಿಸಬಹುದು. ಹರಿವನ್ನು ಶಾಂತಗೊಳಿಸಲು ಆ ಅಗತ್ಯಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು ಉದ್ದೇಶಪೂರ್ವಕ ನಿಯಂತ್ರಣವನ್ನು ದುರ್ಬಲಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀತಿ ಬದಲಿಸುವ ಮೊದಲು ಯಾವ ಘಟಕ ಕೇಳಿತು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.
ನಂತರ ಏನು ಸುಧಾರಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ. ಪ್ರಾಂಪ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಬಂದರೆ, ಅದರ ಒಕ್ಕೂಟ ನಮೂದನ್ನು ಸರಿಪಡಿಸಿ. ನೀತಿಯಂತೆ ಪೂರೈಕೆದಾರರಿಂದ ಬಂದರೆ, ಅಗತ್ಯವನ್ನು ದಾಖಲಿಸಿ. ಯಶಸ್ವಿ ಸೈನ್-ಇನ್ ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪಲಾಗದಿದ್ದರೆ, ಸುರಂಗದ ಮಾರ್ಗನಿರ್ದೇಶನವೇ ಸಂಶಯಾಸ್ಪದ, ಏಕೆಂದರೆ ಗುರುತು ಮತ್ತು ಪ್ಯಾಕೆಟ್ ವಿತರಣೆ ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು ಬಳಕೆದಾರರ ಆಸನದಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ.