दावा-आधारित पहचान का परिचय

Microsoft स्टैक पर एप्लिकेशन विकसित करते समय, वर्तमान उपयोगकर्ता के बारे में जानकारी प्राप्त करने के लिए अक्सर (अधिक सटीक लगभग हमेशा), आप ऐसे कोड के कोड या रैपर को उनके ऊपर पा सकते हैं:

HttpContext.User.Identity.Name
HttpContext.User.IsInRole(...)


या

Thread.CurrentPrincipal.Identity.Name
Thread.CurrentPrincipal.IsInRole(...)


इन कॉल का उद्देश्य किसी फ़ंक्शन या विधि को कॉल के प्राधिकरण पर निर्णय लेने की आवश्यकता हो सकती है, वर्तमान उपयोगकर्ता के बारे में जानकारी प्रदर्शित कर सकते हैं, आदि।

उपयोगकर्ता जानकारी इन वर्गों में अलग-अलग तरीकों से दिखाई देती है: डेटाबेस से डेटा पढ़ना, प्रपत्र प्रमाणीकरण, एनटीएलएम टोकन, केर्बरोस टोकन। प्रत्येक मामले में, उपयोगकर्ता के बारे में जानकारी प्राप्त करने, उसके प्रमाणीकरण और अतिरिक्त जानकारी प्राप्त करने के लिए कार्य को हल किया गया था।

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

[Authorize("Administrators")]
public ActionResult DoSomeHardcoreAdminStuff()
{
...
}


और एक साल के बाद, व्यवसाय ने फैसला किया कि अलग-अलग स्तरों के साथ कई अलग-अलग उपयोगकर्ता समूहों के लिए अच्छा होगा, और सब कुछ (अच्छी तरह से, इस स्थिति के पूरे नाटक को समझने के लिए) के लिए SystemAdministrator और SecurityDirectator प्रशासकों के अधिकारों में अंतर करना। और यह सीमा नहीं है, क्योंकि ये आवश्यकताएं केवल व्यवसाय की कल्पना से सीमित हैं।

डेवलपर के दृष्टिकोण से, यह सब प्रौद्योगिकियों और बैसाखी के एक चिड़ियाघर के परिणामस्वरूप हुआ। प्रत्येक एप्लिकेशन अपने तरीके से उपयोगकर्ताओं को प्रमाणित करता है। उपयोगकर्ता OAuth, प्रपत्र, विंडोज, या कुछ और का उपयोग करके प्रमाणित कर सकता है। प्रत्येक विशेष मामले में, मुझे अपना प्रमाणीकरण और प्राधिकरण तर्क लिखना था, और यदि आपके पास एपी था, तो इसके लिए एक साइकिल भी बनाएं।

जवाब में, 2008 में, विंडोज आइडेंटिटी फाउंडेशन (WIF) की पहली रिलीज माइक्रोसॉफ्ट की गहराई से जारी की गई थी और दावा-आधारित पहचान की अवधारणा पेश की गई थी। इस ढांचे का लक्ष्य उपयोगकर्ता के लिए उनकी आवश्यकताओं को व्यक्त करने के लिए एक सार तंत्र प्रदान करना है, बिना इस विवरण के कि यह कैसे काम करता है।

संक्षेप में, WIF के विचार को काफी सरल जीवन उदाहरण के साथ वर्णित किया जा सकता है:
आप 18 साल के हो गए और आपने सिनेमा में जाने का फैसला किया। वयस्क फिल्म। लेकिन, दुर्भाग्य से, उन्होंने अब तक पासपोर्ट (या कोई अन्य पहचान पत्र प्राप्त करने का प्रबंधन नहीं किया था (अच्छी तरह से, या यह बहुत आलसी था)। आप पासपोर्ट कार्यालय जा रहे हैं और कुछ समय बाद, आपको पासपोर्ट मिल जाएगा और अपना पासपोर्ट प्रस्तुत करने के लिए, बेझिझक अपना क़ीमती टिकट खरीद सकते हैं और सत्र में जा सकते हैं। और यहाँ यह WIF के दृष्टिकोण से दिखता है:



विषय, यानी आप आइडेंटिटी प्रोवाइडर (पासपोर्ट कार्यालय) जाते हैं और जन्म प्रमाण पत्र के आधार पर आपको पासपोर्टपोर्ट प्राप्त होता है। फिर, इस PassportToken के साथ, आप Relying पार्टी (सिनेमा) पर जाएं और अपनी उम्र की पुष्टि करने के बाद, सेवा तक पहुंच प्राप्त करें।

मुख्य विचार जो इस उदाहरण से लिए जा सकते हैं:

1. आपको अधिकृत करने के लिए, एक वयस्क सत्र के आगंतुक के रूप में, सिनेमा को अपने ग्राहक आधार को बनाए रखने या कहीं भी जाने की आवश्यकता नहीं है। उसे केवल आपके आईडी कार्ड की आवश्यकता होती है, जिस पर वह भरोसा करता है (पासपोर्ट, सैन्य आईडी, अधिकार)।

2. पासपोर्ट कार्यालय को यह नहीं पता होता है कि आप अपना पासपोर्ट कहां प्रस्तुत करेंगे। (WIF के दृष्टिकोण से, मुझे अभी भी थोड़ा जानना आवश्यक है, लेकिन यह आवश्यक नहीं है)।

3. पासपोर्ट के साथ, आप सिनेमा में जाने के बाद खुद को अच्छी व्हिस्की खरीद सकते हैं, किसी भी संस्था में बंधक या कुछ और ले सकते हैं जो राज्य द्वारा जारी किए गए दस्तावेजों पर भरोसा करता है। संस्था।

किसी ने पहले से ही OAuth, WS-Trust और WS-Fed, SAML-P जैसे प्रोटोकॉल के साथ काम किया है और यह सहभागिता योजना उनसे परिचित होगी। संक्षेप में, आपको एक निश्चित प्रारूप के टोकन के रूप में एक विश्वसनीय पहचान प्रदाता से उपयोगकर्ता के बारे में जानकारी मिलती है और अपने आवेदन में किसी भी निर्णय लेने के लिए इसका उपयोग करते हैं। एक पतित मामले में, उदाहरण के लिए प्रमाणीकरण, आप स्वयं इस प्रमाणित पार्टी हैं और स्वयं इस जानकारी का उपयोग करते हैं। WIF ऐसे परिदृश्यों की अनुमति देता है। WIF सभी प्रकार के परिदृश्यों का समर्थन करने के लिए पर्याप्त लचीला है।

WIF आपको एक विश्वसनीय पार्टी को प्रमाणीकरण प्रक्रिया को "आउटसोर्स" करने की अनुमति देता है और प्रमाणीकरण और प्राधिकरण प्रक्रिया में डेवलपर के हस्तक्षेप की आवश्यकता को कम करता है। आपके आवेदन पर प्रस्तुत की जाने वाली सभी पहचानों को ClaimsPrincipal और ClaimsIdentity प्रकारों में डाला जाता है। ये प्रकार मानक * प्रिंसिपल और * आइडेंटिटी के समान हैं, वे IPrincipal और IIdentity इंटरफेस को भी लागू करते हैं, लेकिन उनके पास एक अतिरिक्त संपत्ति है, जो उन सभी कथनों का एक संग्रह है जो वर्तमान उपयोगकर्ता के बारे में आपके लिए उपलब्ध हैं। इसके अलावा, संगतता के लिए, IIdentity और IClaimsPrincipal के साथ काम करने के विभिन्न मौजूदा तरीकों का समर्थन किया जाता है, उदाहरण के लिए:

[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]
static void CheckAdministrator()
{
Console.WriteLine("User is an administrator");
}


इसके लिए, उपयोगकर्ता के लिए भूमिका प्रकार का एक स्टेटमेंट होना चाहिए (आप उस प्रकार के स्टेटमेंट को कॉन्फ़िगर कर सकते हैं जिसका उपयोग भूमिकाओं के रूप में किया जाएगा) "एडमिनिस्ट्रेटर" मान के साथ।

ASP.NET MVC अनुप्रयोग में, यह इस तरह दिख सकता है:

[ClaimsAuthorize(ClaimTypes.Role, "Administrators")]
public ActionResult DoSomeHardcoreAdminStuff()
{
...
}


या तो:

[ClaimsAuthorize(ClaimTypes.Permission, "DoSomeHardcoreAdminStuff")]
public ActionResult DoSomeHardcoreAdminStuff()
{
...
}


किसी विशेष संसाधन तक पहुँच की जाँच करने या उपयोगकर्ता की आयु, उसका मेलिंग पता, होम फ़ोन नंबर प्राप्त करने के लिए अधिक जटिल परिदृश्य हैं।

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

वर्तमान में, Microsoft प्लेटफार्मों पर इस तरह के दृष्टिकोण के लिए दो मुख्य समाधान हैं: ADFS (एक्टिव डायरेक्टरी फेडरेशन सर्विसेज) और एज़्योर एसीएस। यदि न तो एक या दूसरे ने आपको सूट किया है, तो आप अपनी खुद की सेवा लिखने के लिए स्वतंत्र हैं, क्योंकि एक उदाहरण के साथ एक टेम्पलेट स्टूडियो में बॉक्स के बाहर रखा गया है। एक खुला स्रोत IdentityServer सर्वर भी है जिसके आधार पर आप अपना उत्पाद विकसित कर सकते हैं।

कुछ तथ्य:

बॉक्स से बाहर, WIF निम्नलिखित प्रोटोकॉल का समर्थन करता है:
1. डब्ल्यूएस-फेडरेशन
2. डब्ल्यूएस-ट्रस्ट
3. WS- सुरक्षा
4. WS-SecurityPolicy
5. डब्ल्यूएस-एड्रेसिंग

SAML-P प्रोटोकॉल सपोर्ट CTP अवस्था में है। आरटीएम संस्करण के बारे में अभी तक कोई जानकारी नहीं है। OAuth2 एक्सटेंशन भी हैं।

SAML1.1 और SAML2 क्रेडेंशियल मानक रूप से समर्थित हैं। लेकिन पहले से ही काफी विकसित पुस्तकालय हैं जो SWT और यहां तक ​​कि JWT (Json Web Token) के लिए समर्थन जोड़ते हैं।

यह System.Security नाम स्थान में क्या हो रहा है में एक बहुत छोटा विषयांतर था। परिचयात्मक पद के हिस्से के रूप में, मैं विवरण में नहीं जाना चाहूंगा
वैसे, .Net में 4.5 दावे आधारित पहचान और WIF पर्वत के राजा बन जाते हैं। सभी प्रकार * प्रिंसिपल को क्लेम्सप्रिंसिपल से विरासत में मिलेगा, केर्बरोस टोकन के अंदर बयानों का एक सेट होगा और बहुत कुछ। अगर किसी को इस विषय में दिलचस्पी है, तो अपनी इच्छाओं को टिप्पणियों में लिखें, क्योंकि मैं निश्चित रूप से समय लिखने की कोशिश करूंगा।

उपयोगी लिंक:
1. एमएसडीएन पर msdn.microsoft.com/en-us/security/aa570351.aspx - पेज।
2. Claid.codeplex.com - कोड उदाहरण और एक मुफ्त पुस्तक।
3. कम से कम । Com - डोमिनिक बैकर ब्लॉग।
4. github.com/thinktecture/Thinktecture.IdentityServer - खुला स्रोत पहचान सर्वर।

पुनश्च। समीक्षा के लिए XaocCPS का धन्यवाद।