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 ప్రొఫైల్ కాదు.
ఎవరు అడిగారో కనుగొని ప్రాంప్ట్‌లను సరిచేయండి
రెండవ పాస్‌వర్డ్ ప్రాంప్ట్ స్వయంచాలకంగా లోపం కాదు. యాప్ ఉన్నత హామీ స్థాయిని అడగవచ్చు, లేదా ప్రదాత గరిష్ఠ సెషన్ వయస్సు మరియు కొత్త సవాలును విధించవచ్చు. ప్రవాహాన్ని ప్రశాంతంగా చేయడానికి ఆ అవసరాలను తొలగించడం ఉద్దేశపూర్వక నియంత్రణను బలహీనపరుస్తుంది, కాబట్టి విధానాన్ని మార్చే ముందు ఏ భాగం అడిగిందో నిర్ధారించండి.
ఆపై ఏమి మెరుగుపరచాలో నిర్ణయించండి. ప్రాంప్ట్ యాప్ నుండి వస్తే, దాని సమాఖ్య నమోదును సరిచేయండి. విధానం ప్రకారం ప్రదాత నుండి వస్తే, అవసరాన్ని డాక్యుమెంట్ చేయండి. విజయవంతమైన సైన్-ఇన్ తర్వాత యాప్ చేరుకోలేకపోతే, టన్నెల్ రూటింగ్ అనుమానాస్పదం, ఎందుకంటే గుర్తింపు మరియు ప్యాకెట్ డెలివరీ వేర్వేరు ప్రదేశాలలో విఫలమవుతాయి మరియు వినియోగదారు సీటు నుండి ఒకేలా కనిపిస్తాయి.