ओपनआयडी कनेक्ट: सानुकूल ते मानकापर्यंत अंतर्गत अनुप्रयोगांची अधिकृतता

काही महिन्यांपूर्वी, मी आमच्या शेकडो अंतर्गत अनुप्रयोगांसाठी प्रवेश व्यवस्थापित करण्यासाठी OpenID Connect सर्व्हर लागू करत होतो. आमच्या स्वतःच्या घडामोडींवरून, लहान प्रमाणात सोयीस्कर, आम्ही सामान्यतः स्वीकारल्या जाणार्‍या मानकांकडे गेलो आहोत. केंद्रीय सेवेद्वारे प्रवेश केल्याने नीरस ऑपरेशन्स मोठ्या प्रमाणात सुलभ होतात, अधिकृततेच्या अंमलबजावणीची किंमत कमी होते, तुम्हाला अनेक तयार समाधाने शोधण्याची परवानगी मिळते आणि नवीन विकसित करताना तुमचा मेंदू रॅक होत नाही. या लेखात, मी या संक्रमणाबद्दल आणि आम्ही भरण्यात व्यवस्थापित केलेल्या अडथळ्यांबद्दल बोलेन.

खूप वर्षांपूर्वी... हे सर्व कसे सुरू झाले

काही वर्षांपूर्वी, जेव्हा मॅन्युअल नियंत्रणासाठी बरेच अंतर्गत अनुप्रयोग होते, तेव्हा आम्ही कंपनीमध्ये प्रवेश नियंत्रित करण्यासाठी एक अनुप्रयोग लिहिला. हा एक साधा रेल ऍप्लिकेशन होता जो कर्मचार्‍यांच्या माहितीसह डेटाबेसशी कनेक्ट होता, जिथे विविध कार्यक्षमतेचा प्रवेश कॉन्फिगर केला होता. त्याच वेळी, आम्ही पहिला SSO उभा केला, जो क्लायंट आणि अधिकृतता सर्व्हरच्या बाजूने टोकनच्या पडताळणीवर आधारित होता, टोकन एन्क्रिप्टेड स्वरूपात अनेक पॅरामीटर्ससह प्रसारित केले गेले आणि अधिकृतता सर्व्हरवर सत्यापित केले गेले. हा सर्वात सोयीस्कर पर्याय नव्हता, कारण प्रत्येक अंतर्गत अनुप्रयोगास तर्कशास्त्राच्या महत्त्वपूर्ण स्तराचे वर्णन करावे लागले आणि कर्मचारी डेटाबेस अधिकृतता सर्व्हरसह पूर्णपणे समक्रमित केले गेले.

काही काळानंतर, आम्ही केंद्रीकृत अधिकृततेचे कार्य सुलभ करण्याचा निर्णय घेतला. SSO ची बॅलन्सरकडे बदली झाली. OpenResty च्या मदतीने, लुआमध्ये एक टेम्पलेट जोडले गेले जे टोकन तपासते, विनंती कोणत्या अनुप्रयोगाकडे जात आहे हे माहित होते आणि तेथे प्रवेश आहे की नाही हे तपासू शकते. या दृष्टिकोनाने अंतर्गत अनुप्रयोगांमध्ये प्रवेश नियंत्रित करण्याचे कार्य मोठ्या प्रमाणात सुलभ केले - प्रत्येक अनुप्रयोगाच्या कोडमध्ये, यापुढे अतिरिक्त तर्कशास्त्राचे वर्णन करणे आवश्यक नव्हते. परिणामी, आम्‍ही बाहेरून रहदारी बंद केली आणि ॲप्लिकेशनलाच अधिकृततेबद्दल काहीही माहिती नाही.

तथापि, एक समस्या अनुत्तरीत राहिली. कर्मचार्‍यांची माहिती आवश्यक असलेल्या अनुप्रयोगांचे काय? अधिकृतता सेवेसाठी API लिहिणे शक्य होते, परंतु नंतर आपल्याला अशा प्रत्येक अनुप्रयोगासाठी अतिरिक्त तर्क जोडावे लागतील. याव्यतिरिक्त, आम्हाला आमच्या अंतर्गत अधिकृतता सर्व्हरवरील, OpenSource मध्ये अनुवादासाठी भविष्यात अभिमुख असलेल्या आमच्या स्व-लिखित अनुप्रयोगांपैकी एकावरील अवलंबित्वापासून मुक्ती मिळवायची होती. त्याबद्दल आपण कधीतरी बोलू. दोन्ही समस्यांचे समाधान OAuth होते.

सामान्य मानकांसाठी

OAuth हे समजण्याजोगे, सामान्यतः स्वीकारलेले प्रमाणिकरण मानक आहे, परंतु केवळ त्याची कार्यक्षमता पुरेशी नसल्यामुळे, त्यांनी लगेच OpenID Connect (OIDC) वर विचार करण्यास सुरुवात केली. OIDC ही खुल्या प्रमाणीकरण मानकाची तिसरी अंमलबजावणी आहे, जी OAuth 2.0 प्रोटोकॉल (ओपन ऑथरायझेशन प्रोटोकॉल) वर अॅड-ऑनमध्ये प्रवाहित झाली आहे. हे समाधान अंतिम वापरकर्त्याबद्दल डेटाच्या कमतरतेची समस्या बंद करते आणि अधिकृतता प्रदाता बदलणे देखील शक्य करते.

तथापि, आम्ही विशिष्ट प्रदाता निवडला नाही आणि आमच्या विद्यमान अधिकृतता सर्व्हरसाठी OIDC सह एकत्रीकरण जोडण्याचा निर्णय घेतला. या निर्णयाच्या बाजूने हे तथ्य होते की ओआयडीसी अंतिम वापरकर्त्याच्या अधिकृततेच्या बाबतीत अतिशय लवचिक आहे. अशा प्रकारे, तुमच्या सध्याच्या अधिकृतता सर्व्हरवर OIDC समर्थन लागू करणे शक्य झाले.

आमचा स्वतःचा OIDC सर्व्हर लागू करण्याचा आमचा मार्ग

1) इच्छित फॉर्ममध्ये डेटा आणला

OIDC समाकलित करण्यासाठी, वर्तमान वापरकर्ता डेटा मानकानुसार समजण्यायोग्य स्वरूपात आणणे आवश्यक आहे. OIDC मध्ये याला क्लेम्स म्हणतात. दावे मूलत: वापरकर्ता डेटाबेस (नाव, ईमेल, फोन इ.) मधील अंतिम फील्ड आहेत. अस्तित्वात स्टॅम्पची मानक यादी, आणि या सूचीमध्ये समाविष्ट नसलेली प्रत्येक गोष्ट सानुकूल मानली जाते. म्हणूनच, तुम्हाला विद्यमान OIDC प्रदाता निवडायचा असेल तर तुम्हाला ज्या पहिल्या मुद्द्याकडे लक्ष देणे आवश्यक आहे ते म्हणजे नवीन ब्रँड्सच्या सोयीस्कर सानुकूलनाची शक्यता.

हॉलमार्कचा गट खालील उपसंच - व्याप्तीमध्ये एकत्रित केला आहे. अधिकृततेदरम्यान, विशिष्ट ब्रँडसाठी नाही तर स्कोपसाठी प्रवेशाची विनंती केली जाते, जरी व्याप्तीमधील काही ब्रँडची आवश्यकता नसली तरीही.

2) आवश्यक अनुदान लागू केले

OIDC एकत्रीकरणाचा पुढील भाग म्हणजे अधिकृतता प्रकारांची निवड आणि अंमलबजावणी, तथाकथित अनुदान. निवडलेला अनुप्रयोग आणि अधिकृतता सर्व्हर यांच्यातील परस्परसंवादाची पुढील परिस्थिती निवडलेल्या अनुदानावर अवलंबून असेल. योग्य अनुदान निवडण्यासाठी एक अनुकरणीय योजना खालील आकृतीमध्ये दर्शविली आहे.

आमच्या पहिल्या अर्जासाठी, आम्ही सर्वात सामान्य अनुदान, अधिकृतता कोड वापरला. इतरांपेक्षा त्याचा फरक असा आहे की तो तीन-चरण आहे, म्हणजे. अतिरिक्त चाचणी सुरू आहे. प्रथम, वापरकर्ता अधिकृत परवानगीसाठी विनंती करतो, एक टोकन प्राप्त करतो - अधिकृतता कोड, नंतर या टोकनसह, जणू प्रवासाच्या तिकिटासह, प्रवेश टोकनची विनंती करतो. या अधिकृतता स्क्रिप्टचे सर्व मुख्य परस्परसंवाद अनुप्रयोग आणि अधिकृतता सर्व्हरमधील पुनर्निर्देशनावर आधारित आहेत. आपण या अनुदानाबद्दल अधिक वाचू शकता येथे.

OAuth या संकल्पनेचे पालन करते की अधिकृततेनंतर प्राप्त केलेले प्रवेश टोकन तात्पुरते असावेत आणि बदलले पाहिजेत, शक्यतो सरासरी दर 10 मिनिटांनी. ऑथोरायझेशन कोड ग्रँट हे रीडायरेक्टद्वारे तीन-चरण सत्यापन आहे, दर 10 मिनिटांनी असे पाऊल वळवणे, स्पष्टपणे, डोळ्यांसाठी सर्वात आनंददायी कार्य नाही. या समस्येचे निराकरण करण्यासाठी, आणखी एक अनुदान आहे - रीफ्रेश टोकन, जे आम्ही आमच्या देशात देखील वापरले. येथे सर्व काही सोपे आहे. दुसर्‍या अनुदानातून पडताळणी करताना, मुख्य प्रवेश टोकन व्यतिरिक्त, आणखी एक जारी केले जाते - रीफ्रेश टोकन, जे फक्त एकदाच वापरले जाऊ शकते आणि त्याचे आयुष्यमान जास्त असते. या रीफ्रेश टोकनसह, जेव्हा मुख्य प्रवेश टोकनचा TTL (टाइम टू लाइव्ह) संपतो, तेव्हा नवीन प्रवेश टोकनची विनंती दुसर्‍या अनुदानाच्या अंतिम बिंदूवर येईल. वापरलेले रीफ्रेश टोकन ताबडतोब शून्यावर रीसेट केले जाते. ही तपासणी द्वि-चरणीय आहे आणि पार्श्वभूमीत केली जाऊ शकते, वापरकर्त्याला अदृश्यपणे.

3) सानुकूल डेटा आउटपुट स्वरूप सेट करा

निवडलेल्या अनुदानांची अंमलबजावणी झाल्यानंतर, अधिकृतता कार्य करते, अंतिम वापरकर्त्याबद्दल डेटा मिळवणे हे उल्लेख करण्यासारखे आहे. यासाठी OIDC कडे वेगळा एंडपॉइंट आहे, जिथे तुम्ही तुमच्या सध्याच्या ऍक्सेस टोकनसह वापरकर्ता डेटाची विनंती करू शकता आणि तो अद्ययावत असल्यास. आणि जर वापरकर्त्याचा डेटा बर्‍याचदा बदलत नसेल आणि तुम्हाला सध्याच्या डेटाचे अनेक वेळा अनुसरण करावे लागेल, तर तुम्ही JWT टोकन्स सारख्या उपायावर येऊ शकता. हे टोकन देखील मानकांद्वारे समर्थित आहेत. JWT टोकनमध्येच तीन भाग असतात: शीर्षलेख (टोकनबद्दल माहिती), पेलोड (कोणताही आवश्यक डेटा) आणि स्वाक्षरी (स्वाक्षरी, टोकन सर्व्हरद्वारे स्वाक्षरी केलेले आहे आणि आपण नंतर त्याच्या स्वाक्षरीचा स्रोत तपासू शकता).

OIDC अंमलबजावणीमध्ये, JWT टोकनला id_token म्हणतात. सामान्य प्रवेश टोकनसह विनंती केली जाऊ शकते आणि फक्त स्वाक्षरी सत्यापित करणे बाकी आहे. ऑथोरायझेशन सर्व्हरकडे फॉरमॅटमध्ये सार्वजनिक कीजच्या गुच्छासह यासाठी वेगळा एंडपॉइंट आहे जे.डब्ल्यू.के.. आणि याबद्दल बोलणे, हे लक्षात घेण्यासारखे आहे की आणखी एक अंतिम बिंदू आहे, जो मानकांवर आधारित आहे आरएफसी 5785 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 हे खुले मानक असल्याने, आमच्याकडे विद्यमान प्रदाता किंवा सर्व्हर अंमलबजावणी निवडण्याचा पर्याय आहे. आम्ही कीक्लोक वापरून पाहिले, जे कॉन्फिगर करणे खूप सोयीचे ठरले, अनुप्रयोगाच्या बाजूने कनेक्शन कॉन्फिगरेशन सेट केल्यानंतर आणि बदलल्यानंतर, ते जाण्यासाठी तयार आहे. अनुप्रयोगाच्या बाजूने, फक्त कनेक्शन कॉन्फिगरेशन बदलणे बाकी आहे.

विद्यमान उपायांबद्दल बोलणे

आमच्या संस्थेमध्ये, पहिला OIDC सर्व्हर म्हणून, आम्ही आमची स्वतःची अंमलबजावणी एकत्र केली, जी आवश्यकतेनुसार पूरक होती. इतर तयार-तयार उपायांचे तपशीलवार पुनरावलोकन केल्यानंतर, आम्ही असे म्हणू शकतो की हा एक महत्त्वाचा मुद्दा आहे. त्यांच्या स्वतःच्या सर्व्हरची अंमलबजावणी करण्याच्या निर्णयाच्या बाजूने, आवश्यक कार्यक्षमतेच्या अनुपस्थितीत प्रदात्यांच्या बाजूने चिंता होती, तसेच जुन्या सिस्टमची उपस्थिती होती ज्यामध्ये काही सेवांसाठी भिन्न सानुकूल अधिकृतता होती आणि बरेच काही. कर्मचार्‍यांचा डेटा आधीच संग्रहित होता. तथापि, तयार केलेल्या अंमलबजावणीमध्ये, एकत्रीकरणासाठी सोयी आहेत. उदाहरणार्थ, कीक्लोकची स्वतःची वापरकर्ता व्यवस्थापन प्रणाली आहे आणि डेटा थेट त्यात संग्रहित केला जातो आणि तेथे आपल्या वापरकर्त्यांना मागे टाकणे कठीण होणार नाही. हे करण्यासाठी, कीक्लोकमध्ये एक API आहे जे आपल्याला सर्व आवश्यक हस्तांतरण क्रिया पूर्ण करण्यास अनुमती देईल.

प्रमाणित, मनोरंजक, माझ्या मते, अंमलबजावणीचे आणखी एक उदाहरण म्हणजे ओरी हायड्रा. हे मनोरंजक आहे कारण त्यात भिन्न घटक असतात. समाकलित करण्‍यासाठी, तुम्‍हाला तुमच्‍या वापरकर्ता व्‍यवस्‍थापन सेवेला त्‍यांच्‍या अधिकृतता सेवेशी लिंक करण्‍याची आवश्‍यकता असेल आणि आवश्‍यकतेनुसार वाढवावी लागेल.

कीक्लोक आणि ओरी हायड्रा हे एकमेव ऑफ-द-शेल्फ उपाय नाहीत. OpenID फाउंडेशन द्वारे प्रमाणित अंमलबजावणी निवडणे सर्वोत्तम आहे. या सोल्यूशन्समध्ये सहसा OpenID प्रमाणन बॅज असतो.

तसेच तुम्हाला तुमचा OIDC सर्व्हर ठेवायचा नसेल तर विद्यमान सशुल्क प्रदात्यांबद्दल विसरू नका. आज बरेच चांगले पर्याय आहेत.

पुढे काय

नजीकच्या भविष्यात, आम्ही अंतर्गत सेवांची वाहतूक वेगळ्या मार्गाने बंद करणार आहोत. आम्ही आमचा वर्तमान SSO बॅलन्सरवर OpenResty वापरून 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