VPN SSO ഉപയോക്താക്കളെ ആന്തരിക ആപ്പുകളിലേക്ക് സ്വയമേവ സൈൻ ഇൻ ചെയ്യുന്നുണ്ടോ?

ഐഡന്റിറ്റി പ്രൊവൈഡർ വഴി പ്രാമാണീകരണം നടത്തുന്ന VPN ഗേറ്റ്‌വേ ഒരു കാര്യം മാത്രം തെളിയിക്കുന്നു: പ്രൊവൈഡർ ഗേറ്റ്‌വേയുടെ മുന്നിൽ ഒരു ഉപയോക്താവിന് ഉറപ്പ് നൽകി. ആ ഉപയോക്താവിന് ഇൻട്രാനെറ്റ് വിക്കിയിലേക്കോ നിരീക്ഷണ ഡാഷ്ബോർഡിലേക്കോ ബിൽഡ് സെർവറിലേക്കോ അത് യാതൊരു ക്രെഡൻഷ്യലും നൽകുന്നില്ല. ആ സേവനങ്ങൾ സ്വന്തം ഫെഡറേഷൻ വഴി ആളുകളെ സൈൻ ഇൻ ചെയ്യിച്ച് സ്വന്തം അധികാരം പ്രയോഗിക്കുന്നു, ഏത് പാക്കറ്റുകൾ അവരിലേക്ക് എത്താമെന്ന് ടണൽ മാത്രം തീരുമാനിക്കുന്നു.

മൂന്ന് സെഷനുകൾ, മൂന്ന് വെവ്വേറെ തീരുമാനങ്ങൾ

അവസ്ഥകൾ വെവ്വേറെ സൂക്ഷിക്കുക, കാരണം ഓരോന്നും സ്വന്തം ഷെഡ്യൂൾ പ്രകാരം കാലഹരണപ്പെടുന്നു. 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 പ്രൊഫൈലല്ല.

ആരാണ് ആവശ്യപ്പെട്ടതെന്ന് കണ്ടെത്തി പ്രോംപ്റ്റുകൾ ശരിയാക്കുക

രണ്ടാം പാസ്‌വേഡ് പ്രോംപ്റ്റ് സ്വയമേവ ഒരു വൈകല്യമല്ല. ആപ്പ് ഉയർന്ന ഉറപ്പ് നിലവാരം ആവശ്യപ്പെടാം, അല്ലെങ്കിൽ പ്രൊവൈഡർ പരമാവധി സെഷൻ പ്രായവും പുതിയ വെല്ലുവിളിയും അടിച്ചേൽപ്പിക്കാം. പ്രവാഹം ശാന്തമാക്കാൻ ആ ആവശ്യകതകൾ നീക്കം ചെയ്യുന്നത് ബോധപൂർവമുള്ള നിയന്ത്രണം ദുർബലമാക്കുന്നു, അതിനാൽ നയം മാറ്റുന്നതിന് മുമ്പ് ഏത് ഘടകമാണ് ആവശ്യപ്പെട്ടതെന്ന് നിർണ്ണയിക്കുക.

തുടർന്ന് എന്ത് മെച്ചപ്പെടുത്തണമെന്ന് തീരുമാനിക്കുക. പ്രോംപ്റ്റ് ആപ്പിൽ നിന്ന് വരുന്നുവെങ്കിൽ, അതിന്റെ ഫെഡറേഷൻ എൻട്രി ശരിയാക്കുക. നയപ്രകാരം പ്രൊവൈഡറിൽ നിന്ന് വരുന്നുവെങ്കിൽ, ആവശ്യകത രേഖപ്പെടുത്തുക. വിജയകരമായ സൈൻ-ഇന് ശേഷം ആപ്പ് എത്താനാകുന്നില്ലെങ്കിൽ, ടണലിന്റെ റൂട്ടിംഗാണ് സംശയാസ്പദം, കാരണം ഐഡന്റിറ്റിയും പാക്കറ്റ് വിതരണവും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പരാജയപ്പെടുന്നു ഉപയോക്താവിന്റെ ഇരിപ്പിടത്തിൽ നിന്ന് സമാനമായി തോന്നുകയും ചെയ്യുന്നു.