dexidp/dexप्लग करने योग्य कनेक्टरों के साथ OpenID Connect (OIDC) पहचान और OAuth 2.0 प्रदाता
Dex एक पहचान सेवा है जो अन्य ऐप्स के लिए प्रमाणीकरण संचालित करने हेतु OpenID Connect का उपयोग करती है।
Dex "कनेक्टर्स." के माध्यम से अन्य पहचान प्रदाताओं के लिए एक पोर्टल के रूप में कार्य करता है। यह dex को प्रमाणीकरण को LDAP सर्वर, SAML प्रदाताओं, या GitHub, Google, और Active Directory जैसे स्थापित पहचान प्रदाताओं को स्थानांतरित करने देता है। क्लाइंट dex से बात करने के लिए अपनी प्रमाणीकरण लॉजिक एक बार लिखते हैं, फिर dex किसी दिए गए बैकएंड के लिए प्रोटोकॉल संभालता है।
आईडी टोकन OpenID Connect द्वारा पेश किया गया एक OAuth2 एक्सटेंशन और dex की प्राथमिक विशेषता हैं। आईडी टोकन JSON Web Tokens (JWT) होते हैं जो dex द्वारा हस्ताक्षरित होते हैं और OAuth2 प्रतिक्रिया के भाग के रूप में लौटाए जाते हैं जो अंतिम उपयोगकर्ता की पहचान की पुष्टि करते हैं। एक उदाहरण JWT कुछ इस प्रकार दिख सकता है:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg
आईडी टोकन में मानक दावे होते हैं जो यह प्रमाणित करते हैं कि किस क्लाइंट ऐप ने उपयोगकर्ता को लॉग इन किया, टोकन कब समाप्त होता है, और उपयोगकर्ता की पहचान।
{
"iss": "http://127.0.0.1:5556/dex",
"sub": "CgcyMzQyNzQ5EgZnaXRodWI",
"aud": "example-app",
"exp": 1492882042,
"iat": 1492795642,
"at_hash": "bi96gOXZShvlWYtal9Eqiw",
"email": "[email protected]",
"email_verified": true,
"groups": [
"admins",
"developers"
],
"name": "Jane Doe"
}
क्योंकि ये टोकन dex द्वारा हस्ताक्षरित होते हैं और मानक-आधारित दावे रखते हैं, अन्य सेवाएँ उन्हें सेवा-से-सेवा क्रेडेंशियल के रूप में उपभोग कर सकती हैं। जो सिस्टम पहले से dex द्वारा जारी OpenID Connect आईडी टोकन उपभोग कर सकते हैं उनमें शामिल हैं:
आईडी टोकन का अनुरोध या सत्यापन कैसे करें, इसके विवरण के लिए "dex का उपयोग करने वाले ऐप्स लिखना" देखें।
Dex कस्टम रिसोर्स डेफिनिशन का उपयोग करके किसी भी Kubernetes क्लस्टर के ऊपर मूल रूप से चलता है और OpenID Connect प्लगइन के माध्यम से API सर्वर प्रमाणीकरण को संचालित कर सकता है। क्लाइंट, जैसे kubelogin और kubectl, उन उपयोगकर्ताओं की ओर से कार्य कर सकते हैं जो dex द्वारा समर्थित किसी भी पहचान प्रदाता के माध्यम से क्लस्टर में लॉगिन कर सकते हैं।
जब कोई उपयोगकर्ता dex के माध्यम से लॉगिन करता है, तो उपयोगकर्ता की पहचान आमतौर पर किसी अन्य उपयोगकर्ता प्रबंधन प्रणाली में संग्रहीत होती है: एक LDAP निर्देशिका, एक GitHub संगठन, आदि। Dex एक क्लाइंट ऐप और अपस्ट्रीम पहचान प्रदाता के बीच एक शिम के रूप में कार्य करता है। क्लाइंट को dex से क्वेरी करने के लिए केवल OpenID Connect समझने की आवश्यकता होती है, जबकि dex अन्य उपयोगकर्ता प्रबंधन प्रणालियों को क्वेरी करने के लिए कई प्रोटोकॉल लागू करता है।
एक "कनेक्टर" dex द्वारा किसी अन्य पहचान प्रदाता के विरुद्ध उपयोगकर्ता को प्रमाणित करने के लिए उपयोग की जाने वाली रणनीति है। Dex ऐसे कनेक्टर्स लागू करता है जो GitHub, LinkedIn, और Microsoft जैसे विशिष्ट प्लेटफ़ॉर्म के साथ-साथ LDAP और SAML जैसे स्थापित प्रोटोकॉल को लक्षित करते हैं।
कनेक्टर्स की प्रोटोकॉल सीमाओं के आधार पर, dex रीफ़्रेश टोकन जारी करने या समूह सदस्यता दावे लौटाने से रोका जा सकता है। उदाहरण के लिए, क्योंकि SAML एसरशन को रीफ़्रेश करने का कोई गैर-इंटरैक्टिव तरीका प्रदान नहीं करता है, यदि कोई उपयोगकर्ता SAML कनेक्टर के माध्यम से लॉगिन करता है तो dex अपने क्लाइंट को रीफ़्रेश टोकन जारी नहीं करेगा। रीफ़्रेश टोकन समर्थन उन क्लाइंट्स के लिए आवश्यक है जिन्हें ऑफ़लाइन एक्सेस की आवश्यकता होती है, जैसे kubectl।
Dex निम्नलिखित कनेक्टर्स लागू करता है:
स्थिर, बीटा, और अल्फा को इस प्रकार परिभाषित किया गया है:
कनेक्टर सुविधाओं के सभी परिवर्तन या अप्रचलन रिलीज़ नोट्स में घोषित किए जाएंगे।
आरंभ करने, कॉन्फ़िगरेशन और उपयोग मार्गदर्शिकाओं के लिए आधिकारिक दस्तावेज़ीकरण देखें।
सुरक्षा भेद्यता रिपोर्ट करने के विवरण के लिए कृपया हमारी सुरक्षा नीति देखें।
विकास सेटअप, दिशानिर्देश और पुल रिक्वेस्ट कैसे सबमिट करें, इसके लिए कृपया CONTRIBUTING.md देखें।
यह परियोजना Apache License, Version 2.0 के तहत लाइसेंस प्राप्त है।
| नाम | रीफ़्रेश टोकन समर्थन | समूह दावा समर्थन | preferred_username दावा समर्थन | स्थिति | टिप्पणियाँ |
|---|
| LDAP | हाँ | हाँ | हाँ | स्थिर | |
| GitHub | हाँ | हाँ | हाँ | स्थिर | |
| SAML 2.0 | नहीं | हाँ | नहीं | स्थिर | चेतावनी: अनुरक्षित नहीं और संभवतः प्रमाणीकरण बायपास के लिए असुरक्षित (#1884) |
| GitLab | हाँ | हाँ | हाँ | बीटा | |
| OpenID Connect | हाँ | हाँ | हाँ | बीटा | Salesforce, Azure, आदि शामिल हैं। |
| OAuth 2.0 | नहीं | हाँ | हाँ | अल्फा | |
| हाँ | हाँ | हाँ | अल्फा | ||
| हाँ | नहीं | नहीं | बीटा | ||
| Microsoft | हाँ | हाँ | नहीं | बीटा | |
| AuthProxy | नहीं | हाँ | नहीं | अल्फा | प्रमाणीकरण प्रॉक्सी जैसे Apache2 mod_auth, आदि। |
| Bitbucket Cloud | हाँ | हाँ | नहीं | अल्फा | |
| OpenShift | हाँ | हाँ | नहीं | अल्फा | |
| Atlassian Crowd | हाँ | हाँ | हाँ * | बीटा | preferred_username दावा को config के माध्यम से कॉन्फ़िगर किया जाना चाहिए |
| Gitea | हाँ | नहीं | हाँ | बीटा | |
| OpenStack Keystone | हाँ | हाँ | नहीं | अल्फा |