VPN SSO பயனர்களை உள் பயன்பாடுகளில் தானாக உள்நுழைக்குமா?

அடையாள வழங்குநர் வழியாக அங்கீகரிக்கும் VPN நுழைவாயில் ஒரு விஷயத்தை மட்டும் நிரூபிக்கிறது: வழங்குநர் நுழைவாயிலின் முன் ஒரு பயனருக்கு உத்தரவாதம் அளித்தார். அது அந்தப் பயனருக்கு உள் வலை விக்கி, கண்காணிப்பு டாஷ்போர்டு அல்லது build சேவையகத்திற்கான சான்றுகளை வழங்காது. அந்தச் சேவைகள் மக்களைத் தங்கள் சொந்த கூட்டமைப்பின் மூலம் உள்நுழைத்து தங்கள் சொந்த அனுமதியைப் பயன்படுத்துகின்றன, சுரங்கப்பாதை எந்தப் பொதிகளை அவர்களை அடையலாம் என்பதை மட்டுமே தீர்மானிக்கிறது.

மூன்று அமர்வுகள், மூன்று தனித்தனி முடிவுகள்

நிலைகளைத் தனித்தனியாக வைத்திருங்கள், ஏனெனில் ஒவ்வொன்றும் அதன் சொந்த அட்டவணையின்படி காலாவதியாகும். VPN அமர்வு என்பது நுழைவாயில் ஒரு அடையாளத்தை ஏற்றுக்கொள்வதும் அது வழங்கிய பிணைய அணுகலும் ஆகும். அடையாள வழங்குநரிடம் உள்ள உலாவி அமர்வு என்பது உலாவி அந்த வழங்குநருக்கு இன்னும் வைத்திருப்பதும் அதன் கொள்கையின்படி மீண்டும் பயன்படுத்தக்கூடியதும் ஆகும். பயன்பாட்டு அமர்வு தனக்கு அனுப்பப்பட்ட பதிலைச் சரிபார்த்த ஒரு சேவைக்கு உரியது.

இந்த நிலைகளைக் கலப்பது தவறான கேள்வியை உருவாக்குகிறது, பொதுவாக சுரங்கப்பாதை பயனரை எல்லா இடங்களிலும் ஏன் உள்நுழைக்கவில்லை என்று கேட்கப்படுகிறது. அதை மீண்டும் எழுதுங்கள்: எந்தப் பயன்பாட்டுக்கு கூட்டமைப்பு பதிவு இல்லை, எது பயனரை நிராகரிக்கிறது, எதற்கு வழி இல்லை. உள் வலைப் பயன்பாட்டைத் திறக்கும் ஒரே உள்நுழைவு கோரிக்கை இன்னும் வழங்குநருக்குத் திரும்பலாம், ஏனெனில் இரண்டாவது வழிமாற்றம் வேறு பார்வையாளர்களுக்கான புதிய அனுமதிக் கோரிக்கை.

நுழைவாயிலை அதன் சொந்த பயன்பாடாக இணைக்கவும்

VPN-ஐ வழங்குநரிடம் அங்கீகரிக்கப்பட்ட பயன்பாடாகப் பதிவு செய்யுங்கள், அதன் சொந்த அடையாளங்காட்டி, வழிமாற்று URI மற்றும் பயனர் ஒதுக்கீட்டுடன். பின்னர் அந்த உள்நுழைவு எந்தப் பிணைய அனுமதிகளை வழங்குகிறது என்பதைத் தீர்மானியுங்கள், ஏனெனில் அது VPN கொள்கை, வழங்குநர் அம்சம் அல்ல. கண்காணிப்பு துணை வலையத்தை மட்டும் அடைய வேண்டிய பயனர்கள் வேறு நுழைவாயில் கொள்கையைப் பெறுகிறார்கள், வேறு கடவுச்சொல்லை அல்ல.

சுரங்கப்பாதையின் அங்கீகாரப் பதில் மீண்டும் பயன்படுத்தக்கூடிய சான்று அல்ல. OIDC ID டோக்கன்கள் எந்த வாடிக்கையாளருக்காக அவை வழங்கப்பட்டன என்பதைக் குறிப்பிடும் பார்வையாளர் உரிமையைக் கொண்டுள்ளன, மேலும் SAML தாங்கி உறுதிமொழிகள் பார்வையாளர்களைப் பெறும் சேவை வழங்குநருக்கு வரம்பிடுகின்றன. முதல் சேவையின் பதிலை ஏற்கும் இரண்டாவது சேவை தவறாக உள்ளமைக்கப்பட்டுள்ளது, டோக்கனை வேறு பயன்பாட்டுக்கு நகலெடுப்பது ஒருங்கிணைப்பு அல்ல.

ஒவ்வொரு உள் பயன்பாட்டையும் பதிவு செய்யுங்கள், பின்னர் உலாவி சூழலை அமைக்கவும்

ஒவ்வொரு சேவைக்கும் ஆதரிக்கப்படும் SAML அல்லது OIDC மதிப்புகள் தேவை: வழங்குபவர், வாடிக்கையாளர் அடையாளங்காட்டி, திரும்ப அழைப்பு அல்லது உறுதிமொழி நுகர்வோர் URL, தேவையான உரிமைகோரல்கள் மற்றும் ஒதுக்கீடு. அணுகல் அதன் மேல் வருகிறது, ஏனெனில் அடையாளச் சரிபார்ப்புகள் ஒருபோதும் வழி அல்லது DNS பதிலை வழங்குவதில்லை.

1. பயன்பாட்டுப் பதிவை உருவாக்கி, நிறுவனம் அல்லது வாடிக்கையாளர் ID பயன்பாடு அனுப்புவதற்குப் பொருந்துகிறதா என்பதை உறுதிப்படுத்துங்கள்.
2. திட்டம் மற்றும் துறைமுகம் உட்பட சரியான திரும்ப அழைப்பு URL-ஐப் பதிவு செய்யுங்கள்; சிறிய தவறு பயனர் அங்கீகரிக்கப்பட்ட பிறகு தோல்வியடையும்.
3. பயனர்கள் அல்லது குழுக்களை ஒதுக்குங்கள், பின்னர் தேவையான உரிமைகோரல்கள் வழங்கப்படுகின்றன என்பதை உறுதிப்படுத்துங்கள்.
4. தனியார் பயன்பாட்டுடன் அடையாள வழங்குநரின் முனைப்புள்ளிகளையும் அனுமதியுங்கள், இல்லையெனில் வழிமாற்றம் முடியாது.

உலாவி சூழல் ஏற்கனவே உள்ள வழங்குநர் அமர்வு மீண்டும் பயன்படுத்தப்படுமா என்பதைத் தீர்மானிக்கிறது. கணினி உலாவியைத் திறக்கும் உள்ளூர் வாடிக்கையாளர் அந்த நிலையைப் பகிரலாம், ஆனால் அதன் சொந்த குக்கி ஜாடியுடன் உட்பொதிக்கப்பட்ட காட்சி பொதுவாக முடியாது. புதிய உலாவி, தனியார் சாளரங்கள் மற்றும் இரண்டாவது சுயவிவரம் அனைத்தும் பூஜ்ஜியத்திலிருந்து தொடங்குகின்றன, இது எதிர்பார்க்கப்படுகிறது, உடைந்த 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 சுயவிவரம் அல்ல.

யார் கேட்டார்கள் என்பதைக் கண்டறிந்து கோரிக்கைகளைச் சரிசெய்யுங்கள்

இரண்டாவது கடவுச்சொல் கோரிக்கை தானாக ஒரு குறைபாடு அல்ல. பயன்பாடு அதிக உறுதிநிலையைக் கேட்கலாம், அல்லது வழங்குநர் அதிகபட்ச அமர்வு வயதையும் புதிய சவாலையும் விதிக்கலாம். ஓட்டத்தை அமைதியாக்க அந்தத் தேவைகளை நீக்குவது வேண்டுமென்றே வைத்த கட்டுப்பாட்டைப் பலவீனப்படுத்துகிறது, எனவே கொள்கையை மாற்றுவதற்கு முன் எந்தக் கூறு கேட்டது என்பதை உறுதிப்படுத்துங்கள்.

பின்னர் எதை மேம்படுத்துவது என்பதைத் தீர்மானியுங்கள். கோரிக்கை பயன்பாட்டிலிருந்து வந்தால், அதன் கூட்டமைப்புப் பதிவைச் சரிசெய்யுங்கள். கொள்கையின்படி வழங்குநரிடமிருந்து வந்தால், தேவையை ஆவணப்படுத்துங்கள். வெற்றிகரமான உள்நுழைவுக்குப் பிறகு பயன்பாட்டை அடைய முடியாவிட்டால், சுரங்கப்பாதையின் வழிப்பாதையே சந்தேகத்திற்குரியது, ஏனெனில் அடையாளமும் பொதி வழங்கலும் வெவ்வேறு இடங்களில் தோல்வியடைகின்றன மேலும் பயனரின் இருக்கையிலிருந்து ஒரே மாதிரியாகத் தெரிகின்றன.