ओपनआईडी जडान: अनुकूलनबाट मानकमा आन्तरिक अनुप्रयोगहरूको प्राधिकरण

केही महिना अघि, मैले हाम्रा सयौं आन्तरिक अनुप्रयोगहरूको पहुँच व्यवस्थापन गर्न OpenID जडान सर्भर लागू गरिरहेको थिएँ। हाम्रा आफ्नै विकासहरूबाट, सानो स्तरमा सुविधाजनक, हामी सामान्यतया स्वीकृत मानकमा सरेका छौं। केन्द्रीय सेवा मार्फत पहुँचले नीरस कार्यहरू धेरै सरल बनाउँछ, प्राधिकरणहरू कार्यान्वयनको लागत घटाउँछ, तपाईंलाई धेरै तयार समाधानहरू फेला पार्न अनुमति दिन्छ र नयाँहरू विकास गर्दा तपाईंको दिमागलाई र्याक गर्दैन। यस लेखमा, म यो संक्रमण र हामीले भर्न व्यवस्थित गरेका बम्पहरूको बारेमा कुरा गर्नेछु।

धेरै पहिले ... यो सबै कसरी सुरु भयो

केही वर्ष पहिले, जब त्यहाँ म्यानुअल नियन्त्रणको लागि धेरै आन्तरिक अनुप्रयोगहरू थिए, हामीले कम्पनी भित्र पहुँच नियन्त्रण गर्न एउटा आवेदन लेख्यौं। यो एक साधारण रेल अनुप्रयोग थियो जुन कर्मचारीहरूको बारेमा जानकारीको साथ डेटाबेसमा जडान भएको थियो, जहाँ विभिन्न प्रकार्यहरूमा पहुँच कन्फिगर गरिएको थियो। उही समयमा, हामीले पहिलो SSO उठायौं, जुन ग्राहक र प्राधिकरण सर्भरको पक्षबाट टोकनहरूको प्रमाणिकरणमा आधारित थियो, टोकन धेरै प्यारामिटरहरूसँग एन्क्रिप्टेड फारममा प्रसारित गरिएको थियो र प्राधिकरण सर्भरमा प्रमाणित गरिएको थियो। यो सबै भन्दा सुविधाजनक विकल्प थिएन, किनकि प्रत्येक आन्तरिक अनुप्रयोगले तर्कको पर्याप्त तह वर्णन गर्नुपर्दछ, र कर्मचारी डाटाबेसहरू प्राधिकरण सर्भरसँग पूर्ण रूपमा सिंक्रोनाइज गरिएको थियो।

केही समय पछि, हामीले केन्द्रीकृत प्राधिकरणको कार्यलाई सरल बनाउने निर्णय गर्यौं। SSO ब्यालेन्सरमा हस्तान्तरण गरिएको थियो। OpenResty को मद्दतले, लुआमा एउटा टेम्प्लेट थपियो जसले टोकनहरू जाँच गर्‍यो, कुन अनुप्रयोगमा अनुरोध जाँदैछ भनेर थाहा थियो, र त्यहाँ पहुँच छ कि छैन भनेर जाँच गर्न सक्छ। यस दृष्टिकोणले आन्तरिक अनुप्रयोगहरूमा पहुँच नियन्त्रण गर्ने कार्यलाई धेरै सरल बनायो - प्रत्येक अनुप्रयोगको कोडमा, यो अब थप तर्क वर्णन गर्न आवश्यक थिएन। नतिजाको रूपमा, हामीले बाह्य रूपमा ट्राफिक बन्द गर्यौं, र एप्लिकेसनलाई प्राधिकरणको बारेमा केही थाहा थिएन।

तर, एउटा समस्या समाधान हुन सकेको छैन । कर्मचारीहरूको बारेमा जानकारी चाहिने अनुप्रयोगहरूको बारेमा के हो? प्राधिकरण सेवाको लागि एपीआई लेख्न सम्भव थियो, तर त्यसोभए तपाईंले प्रत्येक यस्तो अनुप्रयोगको लागि थप तर्क थप्नुपर्नेछ। थप रूपमा, हामी हाम्रो आन्तरिक प्राधिकरण सर्भरमा, हाम्रो स्व-लिखित अनुप्रयोगहरू मध्ये एकमा निर्भरताबाट छुटकारा पाउन चाहन्छौं, जुन पछि 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 टोकनलाई id_token भनिन्छ। यसलाई नियमित पहुँच टोकनको साथ अनुरोध गर्न सकिन्छ र केवल हस्ताक्षर प्रमाणित गर्न बाँकी छ। प्राधिकरण सर्भरसँग ढाँचामा सार्वजनिक कुञ्जीहरूको गुच्छाको साथ यसको लागि छुट्टै अन्तिम बिन्दु छ J.W.K.। र यसको कुरा गर्दा, यो उल्लेखनीय छ कि त्यहाँ अर्को अन्त बिन्दु हो, जुन मानकमा आधारित छ RFC5785 OIDC सर्भरको हालको कन्फिगरेसन प्रतिबिम्बित गर्दछ। यसमा सबै अन्तबिन्दु ठेगानाहरू (हस्ताक्षरका लागि प्रयोग गरिएको सार्वजनिक कुञ्जी रिंगको ठेगाना सहित), समर्थित ब्रान्डहरू र स्कोपहरू, प्रयोग गरिएको इन्क्रिप्शन एल्गोरिदमहरू, समर्थित अनुदानहरू, आदि समावेश छन्।

उदाहरणका लागि गुगलमा:

{
 "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 सर्भरको रूपमा, हामीले हाम्रो आफ्नै कार्यान्वयनलाई भेला गर्यौं, जुन आवश्यकता अनुसार पूरक थियो। अन्य तयार समाधानहरूको विस्तृत समीक्षा पछि, हामी भन्न सक्छौं कि यो एक मूट बिन्दु हो। आफ्नै सर्भर लागू गर्ने निर्णयको पक्षमा, आवश्यक कार्यक्षमताको अभावमा प्रदायकहरूको पक्षमा चिन्ताहरू थिए, साथै पुरानो प्रणालीको उपस्थिति थियो जसमा केही सेवाहरूको लागि फरक कस्टम प्राधिकरणहरू थिए र धेरै धेरै। कर्मचारीहरूको बारेमा डाटा पहिले नै भण्डार गरिएको थियो। यद्यपि, तयार कार्यान्वयनमा, एकीकरणका लागि सुविधाहरू छन्। उदाहरणका लागि, Keycloak को आफ्नै प्रयोगकर्ता व्यवस्थापन प्रणाली छ र डाटा सीधै यसमा भण्डार गरिएको छ, र त्यहाँ तपाइँका प्रयोगकर्ताहरूलाई ओभरटेक गर्न गाह्रो हुनेछैन। यो गर्नको लागि, कीक्लोकसँग एपीआई छ जसले तपाईंलाई सबै आवश्यक स्थानान्तरण कार्यहरू पूरा गर्न अनुमति दिन्छ।

एक प्रमाणित, रोचक, मेरो विचार मा, कार्यान्वयन को अर्को उदाहरण Ory Hydra हो। यो रोचक छ किनभने यो विभिन्न घटक समावेश गर्दछ। एकीकृत गर्न, तपाईंले आफ्नो प्रयोगकर्ता व्यवस्थापन सेवालाई तिनीहरूको प्राधिकरण सेवामा लिङ्क गर्न र आवश्यकता अनुसार विस्तार गर्न आवश्यक छ।

कीक्लोक र ओरी हाइड्रा मात्र अफ-द-शेल्फ समाधानहरू होइनन्। OpenID फाउन्डेशन द्वारा प्रमाणित कार्यान्वयन छनौट गर्नु उत्तम हुन्छ। यी समाधानहरूमा सामान्यतया OpenID प्रमाणीकरण ब्याज हुन्छ।

यदि तपाईं आफ्नो OIDC सर्भर राख्न चाहनुहुन्न भने अवस्थित सशुल्क प्रदायकहरूको बारेमा पनि नबिर्सनुहोस्। आज त्यहाँ धेरै राम्रो विकल्पहरू छन्।

अब के

निकट भविष्यमा, हामी अर्को तरिकाले आन्तरिक सेवाहरूमा ट्राफिक बन्द गर्न जाँदैछौं। हामी OAuth मा आधारित प्रोक्सीमा OpenResty प्रयोग गरेर ब्यालेन्सरमा हाम्रो हालको SSO स्थानान्तरण गर्ने योजना बनाउँछौं। यहाँ पहिले नै धेरै तयार समाधानहरू छन्, उदाहरणका लागि:
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