OpenID இணைப்பு: விருப்பத்திலிருந்து தரநிலைக்கு உள் பயன்பாடுகளின் அங்கீகாரம்

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

நீண்ட காலத்திற்கு முன்பு... இது எப்படி தொடங்கியது

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

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

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

பொதுவான தரங்களுக்கு

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

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

எங்கள் சொந்த OIDC சேவையகத்தை செயல்படுத்துவதற்கான எங்கள் வழி

1) தேவையான படிவத்திற்கு தரவு கொண்டு வரப்பட்டது

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

ஹால்மார்க் குழு பின்வரும் துணைக்குழுவில் இணைக்கப்பட்டுள்ளது - நோக்கம். அங்கீகாரத்தின் போது, ​​குறிப்பிட்ட பிராண்டுகளுக்கு அணுகல் கோரப்படுகிறது, ஆனால் ஸ்கோப்களில் இருந்து சில பிராண்டுகள் தேவையில்லை என்றாலும் கூட.

2) தேவையான மானியங்களை செயல்படுத்தியது

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

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

OAuth அங்கீகாரத்திற்குப் பிறகு பெறப்பட்ட அணுகல் டோக்கன்கள் தற்காலிகமாக இருக்க வேண்டும் மற்றும் சராசரியாக ஒவ்வொரு 10 நிமிடங்களுக்கும் மாற்றப்பட வேண்டும் என்ற கருத்தை கடைபிடிக்கிறது. அங்கீகாரக் குறியீடு மானியம் என்பது வழிமாற்றுகள் மூலம் மூன்று-படி சரிபார்ப்பு ஆகும், ஒவ்வொரு 10 நிமிடங்களுக்கும் இதுபோன்ற ஒரு படியைத் திருப்புவது, வெளிப்படையாக, கண்களுக்கு மிகவும் இனிமையான பணி அல்ல. இந்தச் சிக்கலைத் தீர்க்க, மற்றொரு மானியம் உள்ளது - புதுப்பிப்பு டோக்கன், இதை நாங்கள் நம் நாட்டிலும் பயன்படுத்தினோம். இங்கே எல்லாம் எளிதானது. மற்றொரு மானியத்திலிருந்து சரிபார்ப்பின் போது, ​​முக்கிய அணுகல் டோக்கனுடன் கூடுதலாக, இன்னொன்று வழங்கப்படுகிறது - புதுப்பிப்பு டோக்கன், இது ஒரு முறை மட்டுமே பயன்படுத்தப்படும் மற்றும் அதன் வாழ்நாள் பொதுவாக நீண்டதாக இருக்கும். இந்த ரெஃப்ரெஷ் டோக்கன் மூலம், பிரதான அணுகல் டோக்கனின் TTL (நேரம் வாழ்வதற்கான நேரம்) முடிவடையும் போது, ​​புதிய அணுகல் டோக்கனுக்கான கோரிக்கை மற்றொரு மானியத்தின் இறுதிப் புள்ளிக்கு வரும். பயன்படுத்தப்பட்ட புதுப்பிப்பு டோக்கன் உடனடியாக பூஜ்ஜியத்திற்கு மீட்டமைக்கப்படும். இந்தச் சரிபார்ப்பு இரண்டு-படி மற்றும் பயனருக்குப் புரியாத வகையில் பின்னணியில் செய்யப்படலாம்.

3) தனிப்பயன் தரவு வெளியீட்டு வடிவங்களை அமைக்கவும்

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

OIDC செயல்படுத்தலில், JWT டோக்கன் ஐடி_டோக்கன் என்று அழைக்கப்படுகிறது. வழக்கமான அணுகல் டோக்கனுடன் அதைக் கோரலாம் மற்றும் கையொப்பத்தைச் சரிபார்ப்பது மட்டுமே மீதமுள்ளது. அங்கீகார சேவையகம் இதற்கான தனி முனைப்புள்ளியை வடிவில் உள்ள பொது விசைகளுடன் கொண்டுள்ளது JWK. இதைப் பற்றி பேசுகையில், தரநிலையின் அடிப்படையில் மற்றொரு இறுதிப்புள்ளி உள்ளது என்பதைக் குறிப்பிடுவது மதிப்பு RFC5785 OIDC சேவையகத்தின் தற்போதைய உள்ளமைவை பிரதிபலிக்கிறது. இது அனைத்து இறுதிப்புள்ளி முகவரிகளையும் (கையொப்பமிடுவதற்குப் பயன்படுத்தப்படும் பொது விசை வளையத்தின் முகவரி உட்பட), ஆதரிக்கப்படும் பிராண்டுகள் மற்றும் நோக்கங்கள், பயன்படுத்தப்பட்ட குறியாக்க வழிமுறைகள், ஆதரிக்கப்படும் மானியங்கள் போன்றவற்றைக் கொண்டுள்ளது.

எடுத்துக்காட்டாக, Google இல்:

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
 "token_endpoint": "https://oauth2.googleapis.com/token",
 "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
 "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 "response_types_supported": [
  "code",
  "token",
  "id_token",
  "code token",
  "code id_token",
  "token id_token",
  "code token id_token",
  "none"
 ],
 "subject_types_supported": [
  "public"
 ],
 "id_token_signing_alg_values_supported": [
  "RS256"
 ],
 "scopes_supported": [
  "openid",
  "email",
  "profile"
 ],
 "token_endpoint_auth_methods_supported": [
  "client_secret_post",
  "client_secret_basic"
 ],
 "claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "locale",
  "name",
  "picture",
  "sub"
 ],
 "code_challenge_methods_supported": [
  "plain",
  "S256"
 ],
 "grant_types_supported": [
  "authorization_code",
  "refresh_token",
  "urn:ietf:params:oauth:grant-type:device_code",
  "urn:ietf:params:oauth:grant-type:jwt-bearer"
 ]
}

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

அமலாக்க முடிவுகள்

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

ஏற்கனவே உள்ள தீர்வுகளைப் பற்றி பேசுகிறது

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

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

Keycloak மற்றும் Ory Hydra ஆகியவை மட்டுமே ஆஃப்-தி-ஷெல்ஃப் தீர்வுகள் அல்ல. OpenID அறக்கட்டளையால் சான்றளிக்கப்பட்ட செயலாக்கத்தைத் தேர்ந்தெடுப்பது சிறந்தது. இந்த தீர்வுகள் பொதுவாக OpenID சான்றிதழ் பேட்ஜைக் கொண்டிருக்கும்.

உங்கள் OIDC சேவையகத்தை வைத்திருக்க விரும்பவில்லை என்றால், ஏற்கனவே உள்ள கட்டண வழங்குநர்களைப் பற்றி மறந்துவிடாதீர்கள். இன்று பல நல்ல விருப்பங்கள் உள்ளன.

அடுத்தது என்ன

எதிர்காலத்தில், உள் சேவைகளுக்கான போக்குவரத்தை வேறு வழியில் மூட உள்ளோம். ஓபன்ரெஸ்டியைப் பயன்படுத்தி பேலன்சரில் எங்களின் தற்போதைய எஸ்எஸ்ஓவை OAuth அடிப்படையிலான ப்ராக்ஸிக்கு மாற்ற திட்டமிட்டுள்ளோம். இங்கே ஏற்கனவே பல ஆயத்த தீர்வுகள் உள்ளன, எடுத்துக்காட்டாக:
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

கூடுதல் பொருட்கள்

jwt.io - JWT டோக்கன்களை சரிபார்க்க நல்ல சேவை
openid.net/developers/certified - சான்றளிக்கப்பட்ட OIDC செயலாக்கங்களின் பட்டியல்

ஆதாரம்: www.habr.com