👼🏾 👨🏿‍⚕️ 🍲 Xml- आधारित पहुँच नीति कॉन्फ़िगरेशन के साथ दावा-आधारित प्राधिकरण उदाहरण ⬛️ 🤱 👈🏿

परिचय

प्रमाणीकरण और प्राधिकरण का विषय हमेशा अधिकांश वेब अनुप्रयोगों के लिए प्रासंगिक होगा। कई .NET डेवलपर्स पहले से ही विंडोज आइडेंटिटी फाउंडेशन (WIF), इसके दृष्टिकोण और तथाकथित "पहचान-जागरूक" अनुप्रयोगों को लागू करने की क्षमताओं से परिचित होने में कामयाब रहे हैं। जिन लोगों ने WIF के साथ काम नहीं किया, उनके लिए MSDN के अगले भाग का अध्ययन करके पहले परिचित को शुरू किया जा सकता है। इस लेख में, मैं उपयोगकर्ता के प्राधिकरण के तथाकथित "दावे-आधारित" दृष्टिकोण पर एक अधिक विस्तृत नज़र रखने का प्रस्ताव करता हूं कि यह कैसे एक उदाहरण के साथ दिख सकता है।

दावे-आधारित प्राधिकरण

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

सामान्य तौर पर, उपरोक्त दृष्टिकोण डेवलपर्स को प्राधिकरण के तर्क से आवेदन के व्यापारिक तर्क को अलग करने के लिए प्रोत्साहित करता है, और यह वास्तव में सुविधाजनक है। तो यह व्यवहार में कैसे दिखता है? वास्तव में, चलो इसे करने के लिए नीचे उतरो।

समस्या का बयान

मान लीजिए कि आपको कुछ प्रकार की एपीआई सेवा बनाने की आवश्यकता है जो कई क्लाइंट अनुप्रयोगों के लिए उपलब्ध होगी। ग्राहक अनुप्रयोगों की कार्यक्षमता अलग है, उपयोगकर्ताओं को भी। यह संभव है कि अन्य क्लाइंट एप्लिकेशन भी अपने उपयोगकर्ताओं और एपीआई के साथ एक इंटरैक्शन स्कीम के साथ दिखाई देंगे, इसलिए हमें किसी विशेष एप्लिकेशन / उपयोगकर्ता के लिए एपीआई एक्सेस पॉलिसी को कॉन्फ़िगर करने के लिए किसी भी स्तर पर सक्षम होने के लिए एक लचीली प्राधिकरण प्रणाली होनी चाहिए। हमारे मामले में एपीआई ASP.NET वेब एपीआई 2.0 का उपयोग करके बनाया जाएगा, क्लाइंट अनुप्रयोग, उदाहरण के लिए, एक विंडोज फोन एप्लिकेशन और एक वेब साइट होगा।

उनके उपयोगकर्ताओं के अनुप्रयोगों और कार्यक्षमता पर अधिक विस्तार से विचार करें:

विंडोज फोन क्लाइंट

अपने आप में, यह केवल नए उपयोगकर्ताओं को पंजीकृत कर सकता है।
पंजीकृत उपयोगकर्ता:
- अपनी प्रोफ़ाइल देखें
- अपनी प्रोफ़ाइल अपडेट करें;
- अपना पासवर्ड बदलें;

वेब क्लाइंट

अपने आप में, एपीआई तक इसकी पहुंच नहीं है।
मोबाइल ग्राहक के साथ पंजीकृत उपयोगकर्ता:
- अपनी प्रोफ़ाइल देखें
- अपनी प्रोफ़ाइल अपडेट करें;
- अपना पासवर्ड बदलें;
सिस्टम प्रशासक कर सकते हैं:
- आपके खाते के उपयोगकर्ताओं के लिए सब कुछ वैसा ही है;
- किसी भी उपयोगकर्ता के खाते के लिए सभी उपयोगकर्ता के समान;
- सभी पंजीकृत उपयोगकर्ताओं की सूची देखें;
- उपयोगकर्ताओं को बनाएं / हटाएं;

इसलिए, हमें इस बात का अंदाजा है कि एपीआई के माध्यम से किस क्लाइंट को और किन नियमों के साथ कार्यक्षमता प्रदान की जानी चाहिए। खैर, चलो शुरू हो जाओ!

कार्यान्वयन

आइए भविष्य की सेवा एपीआई के इंटरफेस को परिभाषित करके शुरू करें:

public interface IUsersApiController { // List all users. IEnumerable<User> GetAllUsers(); // Lookup single user. User GetUserById(int id); // Create user. HttpResponseMessage Post(RegisterModel user); // Restore user's password. HttpResponseMessage RestorePassword(string email); // Update user. HttpResponseMessage Put(int id, UpdateUserModel value); // Delete user. HttpResponseMessage Delete(string email); }

एपीआई के प्रत्यक्ष कार्यान्वयन को इस लेख के कोष्ठक से बाहर छोड़ दिया जाएगा, कम से कम उदाहरण के लिए एक विकल्प जैसे यह करेगा:

  public class UsersController : ApiController { //... public HttpResponseMessage Post([FromBody]RegisterModel user) { if (ModelState.IsValid) { return Request.CreateResponse(HttpStatusCode.OK, "Created!"); } else { return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState); } } //... }

अगला कदम क्लेम्सऑथोराइज़ेशन मैनजेर वर्ग का उत्तराधिकारी बनाना और इसके कुछ तरीकों को ओवरराइड करना है। ClaimsAuthorizationManager वास्तव में WIF घटक है जो आपको एक ही स्थान पर आने वाले अनुरोधों को रोकने और मनमाने ढंग से तर्क निष्पादित करने की अनुमति देता है, जो वर्तमान उपयोगकर्ता के दावों के सेट के आधार पर * एक्सेस देने या अस्वीकार करने का निर्णय लेता है।

* - हम इस बारे में बात करेंगे कि यह सेट कहाँ थोड़ी देर बाद बनता है।

बहुत दूर जाने के बिना, हम इस लिंक पर MSDN से इसके कार्यान्वयन को उधार ले सकते हैं। जैसा कि हम उदाहरण अनुभाग से देखते हैं, निम्नलिखित विधियां ओवरराइड हैं:

  /// <summary> /// Overloads the base class method to load the custom policies from the config file /// </summary> /// <param name="nodelist">XmlNodeList containing the policy information read from the config file</param> public override void LoadCustomConfiguration(XmlNodeList nodelist) {...} /// <summary> /// Checks if the principal specified in the authorization context is authorized /// to perform action specified in the authorization context on the specified resource /// </summary> /// <param name="pec">Authorization context</param> /// <returns>true if authorized, false otherwise</returns> public override bool CheckAccess(AuthorizationContext pec) {...}

कार्यान्वयन और उस पर टिप्पणियों को देखते हुए, आप यह पता लगा सकते हैं कि क्या हो रहा है और मैं वहां नहीं रुकूंगा। मैं इस उदाहरण से केवल पहुंच नीति प्रारूप पर ध्यान देता हूं:

  ... <policy resource="http://localhost:28491/Developers.aspx" action="GET"> <or> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="developer" /> <claim claimType="http://schemas.xmlsoap.org/claims/Group" claimValue="Administrator" /> </or> </policy> <policy resource="http://localhost:28491/Administrators.aspx" action="GET"> <and> <claim claimType="http://schemas.xmlsoap.org/claims/Group" claimValue="Administrator" /> <claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country" claimValue="USA" /> </and> </policy> <policy resource="http://localhost:28491/Default.aspx" action="GET"> </policy> ...

यहां पहुंच नीति "नीति" अनुभागों का एक समूह है, जिनमें से प्रत्येक को "संसाधन" और "कार्रवाई" जैसी विशेषताओं से पहचाना जाता है। प्रत्येक ऐसे खंड के भीतर "दावे" सूचीबद्ध हैं जो संसाधन तक पहुंचने के लिए आवश्यक हैं। WebApi के मामले में, "संसाधन" नियंत्रक का नाम है, "कार्रवाई" क्रिया विधि का नाम है। इसके अलावा, तार्किक स्थितियों का उपयोग करके एक्सेस नियमों का निर्माण करना संभव है *।

* - प्रत्येक और सब कुछ बहुत अच्छा होगा यदि वर्तमान कार्यान्वयन में और या ब्लॉक के अंदर 2 से अधिक दावा तत्वों को कॉन्फ़िगर करना संभव था।

अभी के लिए, हम सभी "as-is" का उपयोग करते हैं, वारिस के नाम को छोड़कर, हम इसे XmlBasedAuthorizationManager बदल XmlBasedAuthorizationManager । यदि आप प्रोजेक्ट बनाने की कोशिश करते हैं, तो यह पता चलता है कि हमारे पास PolicyReader क्लास की कमी है, आप इसे MSDN उदाहरण के पूर्ण स्रोत कोड से ले सकते हैं।

नया कार्यान्वयन तैयार होने के बाद, हम इसे प्राधिकरण प्रबंधक के रूप में उपयोग करने के लिए WebAPI एप्लिकेशन को कॉन्फ़िगर करेंगे। ऐसा करने के लिए:

1. WIF को काम करने के लिए आवश्यक कॉन्फ़िगरेशन अनुभागों को पंजीकृत करें:

  <configSections> <section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" /> <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" /> <!-- Others sections--> </configSections>

2. हम इंगित करते हैं कि किस कार्यान्वयन को एक प्राधिकरण प्रबंधक के रूप में उपयोग किया जाना चाहिए:

  <system.identityModel> <identityConfiguration> <claimsAuthorizationManager type="YourProject.WebApi.Security.XmlBasedAuthorizationManager, YourProject.WebApi, Version=1.0.0.0, Culture=neutral"> <!-- Policies --> </claimsAuthorizationManager> <claimsAuthenticationManager type="YourProject.WebApi.Security.AuthenticationManager, YourProject.WebApi, Version=1.0.0.0, Culture=neutral" /> </identityConfiguration> </system.identityModel>

ठीक है, हमने WIF को बताया कि किस कार्यान्वयन का उपयोग करना है, लेकिन जैसा कि आपने देखा, दो विवरण ऊपर विन्यास में बने रहे:

xml- वर्गों "नीति" के एक सेट के बजाय हमारे पास खाली है;
एक xml तत्व " claimsAuthenticationManager " है, जिसका मैंने पहले उल्लेख नहीं किया था।

इन बिंदुओं पर विचार करें।

1. प्रवेश नीति विन्यास

समस्या के बयान पर लौटते हुए, और पहले से ही उपयोग की जाने वाली नीति के प्रारूप पर भी विचार करते हुए, हम अपने एपीआई के लिए एक विन्यास बनाने की कोशिश करेंगे। यह नियमों के निम्नलिखित सेट में परिणाम होगा:

  <policy resource="Users" action="GetAllUsers"> <and> <claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" /> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" /> </and> </policy> <policy resource="Users" action="Post"> <claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WPhoneApplication" /> </policy> <policy resource="Users" action="RestorePassword"> <claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WPhoneApplication" /> </policy> <policy resource="Users" action="GetUserById"> <or> <and> <claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" /> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" /> </and> <and> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="User" /> <!--    {0}     "request" ? --> <!-- <claim claimType="UserId" claimValue="{0}" /> --> </and> </or> </policy> <policy resource="Users" action="Put"> <or> <and> <claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" /> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" /> </and> <and> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="User" /> <!--    {0}     "request" ? --> <!-- <claim claimType="UserId" claimValue="{0}" /> --> </and> </or> </policy>

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

  <policy resource="Users" action="GetAllUsers"> <and> <claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" /> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" /> </and> </policy>

सब कुछ बहुत स्पष्ट है: उन उपयोगकर्ताओं के पास इस संसाधन तक पहुंच है, "दावों" के सेट में जिनमें "दावा" दोनों तत्व शामिल हैं।

अब एक और मुश्किल विकल्प पहचानकर्ता द्वारा उपयोगकर्ता के बारे में जानकारी प्राप्त करना है :

  <policy resource="Users" action="GetUserById"> <or> <and> <claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" /> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" /> </and> <and> <claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="User" /> <!--    {0}     "request" ? --> <!-- <claim claimType="UserId" claimValue="{0}" /> --> </and> </or> </policy>

आवश्यकताओं पर लौटते हुए, केवल वेब एप्लिकेशन व्यवस्थापक ही इस संसाधन तक पहुँच सकते हैं, साथ ही साथ उपयोगकर्ता, बशर्ते कि प्रत्येक उपयोगकर्ता केवल अपने खाते से डेटा प्राप्त कर सकता है। जैसा कि आप देख सकते हैं, हम आसानी से पहली .. ब्लॉक में पहली आवश्यकता स्थापित करते हैं। लेकिन उपयोगकर्ताओं के बारे में क्या?

दुर्भाग्यवश, वर्तमान कार्यान्वयन, जिसे हमने वैध रूप से कॉपी किया है, अब हमें इस स्थिति को कॉन्फ़िगर करने की अनुमति नहीं देता है। इसके अलावा, जैसा कि मैंने ऊपर उल्लेख किया है , यह तार्किक and/or " and/or " ब्लॉक के अंदर नेस्टेड तत्वों के उपयोग की अनुमति नहीं देता है। अत्यंत ईमानदार होने के लिए, यह कार्यान्वयन कठोरता से " and/or " and/or "ब्लॉक" के अंदर दो "बराबर" तत्वों की संख्या निर्धारित करता है।

इस शर्त के अनुसार "प्रत्येक व्यक्ति अपने खाते में केवल डेटा प्राप्त कर सकता है", मैं अगले लेख में अपना समाधान पेश करने की योजना बना रहा हूं। मैं अब इस तथ्य के साथ आने का प्रस्ताव करता हूं कि सभी उपयोगकर्ता एक दूसरे के बारे में जानकारी देख सकते हैं, क्योंकि यह संकलित कॉन्फ़िगरेशन को छोड़ देता है। विशेष रूप से जबकि throw new NotImplementedException() पद्धति का कार्यान्वयन throw new NotImplementedException() जैसा लगता है।

लेकिन सही तरीके से काम करने के लिए वर्तमान कॉन्फ़िगरेशन के लिए, हम PolicyReader वर्ग के कार्यान्वयन को थोड़ा बदल देंगे:

  /// <summary> /// Read the Or Node /// </summary> /// <param name="rdr">XmlDictionaryReader of the policy Xml</param> /// <param name="subject">ClaimsPrincipal subject</param> /// <returns>A LINQ expression created from the Or node</returns> private Expression<Func<ClaimsPrincipal, bool>> ReadOr(XmlDictionaryReader rdr, ParameterExpression subject) { Expression defaultExpr = Expression.Invoke((Expression<Func<bool>>)(() => false)); while (rdr.Read()) { if (rdr.NodeType != XmlNodeType.EndElement && rdr.Name != "or") { defaultExpr = Expression.OrElse(defaultExpr, Expression.Invoke(ReadNode(rdr, subject), subject)); } else break; } rdr.ReadEndElement(); Expression<Func<ClaimsPrincipal, bool>> resultExpr = Expression.Lambda<Func<ClaimsPrincipal, bool>>(defaultExpr, subject); return resultExpr; } /// <summary> /// Read the And Node /// </summary> /// <param name="rdr">XmlDictionaryReader of the policy Xml</param> /// <param name="subject">ClaimsPrincipal subject</param> /// <returns>A LINQ expression created from the And node</returns> private Expression<Func<ClaimsPrincipal, bool>> ReadAnd(XmlDictionaryReader rdr, ParameterExpression subject) { Expression defaultExpr = Expression.Invoke((Expression<Func<bool>>)(() => true)); while (rdr.Read()) { if (rdr.NodeType != XmlNodeType.EndElement && rdr.Name != "and") { defaultExpr = Expression.AndAlso(defaultExpr, Expression.Invoke(ReadNode(rdr, subject), subject)); } else break; } rdr.ReadEndElement(); Expression<Func<ClaimsPrincipal, bool>> resultExpr = Expression.Lambda<Func<ClaimsPrincipal, bool>>(defaultExpr, subject); return resultExpr; }

खैर, हमने अपने एपीआई के संसाधनों के लिए एक्सेस पॉलिसी को कॉन्फ़िगर किया, एक प्राधिकरण प्रबंधक का कार्यान्वयन बनाया जो हमारे कॉन्फ़िगरेशन के साथ काम कर सकता है। अब आप प्रमाणीकरण पर जा सकते हैं - वह चरण जो प्राधिकरण से पहले होता है।

2. प्रमाणीकरण और दावे

यह तय करने से पहले कि उपयोगकर्ता के पास संसाधन तक पहुंच है या नहीं, पहले प्रमाणीकरण होना चाहिए, और यदि यह सफल है, तो उपयोगकर्ता के “दावे” को भरें।

प्रमाणीकरण के लिए, हम मूल प्रमाणीकरण का उपयोग करेंगे और, उदाहरण के लिए, थिंकट्रेक्चर में इसका कार्यान्वयन ।dentityModel.45 । ऐसा करने के लिए, NuGet कंसोल में, कमांड निष्पादित करें:

 Install-Package Thinktecture.IdentityModel

WebApiConfig वर्ग के लिए कोड को लगभग इस प्रकार WebApiConfig गया है:

  public static class WebApiConfig { public static void Register(HttpConfiguration config) { var authentication = CreateAuthenticationConfiguration(); config.MessageHandlers.Add(new AuthenticationHandler(authentication)); config.MapHttpAttributeRoutes(); config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); config.EnableSystemDiagnosticsTracing(); config.Filters.Add(new ClaimsAuthorizeAttribute()); } private static AuthenticationConfiguration CreateAuthenticationConfiguration() { var authentication = new AuthenticationConfiguration { ClaimsAuthenticationManager = new AuthenticationManager(), RequireSsl = false //only for testing }; #region Basic Authentication authentication.AddBasicAuthentication((username, password) => { var webSecurityService = ServiceLocator.Current.GetInstance<IWebSecurityService>(); return webSecurityService.Login(username, password); }); #endregion return authentication; } }

यहां मैं केवल यह नोट करूंगा कि मैं अनुरोध से आए क्रेडेंशियल्स की जांच करने के लिए एक निश्चित IWebSecurityService का उपयोग करता हूं। आप यहां अपने तर्क का उपयोग कर सकते हैं, उदाहरण के लिए: ~~return username == password;~~

अब, किसी भी संसाधन के लिए हर अनुरोध के साथ, एक प्रमाणीकरण जांच की जाएगी, लेकिन हमें वर्तमान उपयोगकर्ता के "दावों" के मूल सेट को भी बदलना होगा। यह ClaimsAuthenticationManager , या इस वर्ग के हमारे वंशज हैं, जिसे हमने पहले ही पंजीकृत कर लिया है :

  public class AuthenticationManager : ClaimsAuthenticationManager { public override ClaimsPrincipal Authenticate(string resourceName, ClaimsPrincipal incomingPrincipal) { if (!incomingPrincipal.Identity.IsAuthenticated) { return base.Authenticate(resourceName, incomingPrincipal); } var claimsService = ServiceLocator.Current.GetInstance<IUsersClaimsService>(); var claims = claimsService.GetUserClaims(incomingPrincipal.Identity.Name); foreach (var userClaim in claims) { incomingPrincipal.Identities.First().AddClaim(new Claim(userClaim.Type, userClaim.Value)); } return incomingPrincipal; } }

जैसा कि आप देख सकते हैं, यदि उपयोगकर्ता प्रमाणित है, तो उनका "दावा" सेट प्राप्त होता है, डेटाबेस से कहते हैं, IUsersClaimsService के नए बनाए गए उदाहरण का उपयोग करते हुए। "परिवर्तन" के बाद, ClaimsPrincipal उदाहरण बाद में उपयोग के लिए पाइपलाइन में वापस आ जाता है , उदाहरण के लिए, प्राधिकरण द्वारा।

परिणाम का सत्यापन

यह हमारे समाधान के प्रदर्शन का परीक्षण करने का समय है। ऐसा करने के लिए, हमें स्वाभाविक रूप से एक या दूसरे "दावों" वाले उपयोगकर्ताओं की आवश्यकता होगी। हम लंबे समय तक कल्पना नहीं करेंगे कि उन्हें कहां से मिलेगा और हम परीक्षण उद्देश्यों के लिए AuthenticationManager को थोड़ा संशोधित करेंगे। IUsersClaimsService का उपयोग IUsersClaimsService बजाय IUsersClaimsService निम्न कोड IUsersClaimsService :

  public class AuthenticationManager : ClaimsAuthenticationManager { public override ClaimsPrincipal Authenticate(string resourceName, ClaimsPrincipal incomingPrincipal) { ... if (incomingPrincipal.Identity.Name.ToLower().Contains("user")) { incomingPrincipal.Identities.First().AddClaim(new Claim(ClaimTypes.Role, "User")); } return incomingPrincipal; } }

खैर, अब सभी उपयोगकर्ता जिनके लॉगिन में "उपयोगकर्ता" शब्द है, उनमें वांछित "दावा" शामिल होगा।
प्रोजेक्ट को चलाएं और लिंक लोकलहोस्ट का पालन करें: [पोर्ट] / एपीआई / उपयोगकर्ता

हम पोषित उपयोगकर्ता नाम और पासवर्ड दर्ज करते हैं, हमारा सरल प्राधिकरण उन्हें समानता के लिए जाँचता है, और प्राधिकरण प्रबंधक "दावों" के सेट को बदल देता है:

हम निष्पादन जारी रखते हैं और सुनिश्चित करते हैं कि एक मात्र नश्वर सभी उपयोगकर्ताओं की सूची नहीं देख सकता है:

अब याद करते हैं कि एक्सेस पॉलिसी को कॉन्फ़िगर करने के चरण में, हमें सभी उपयोगकर्ताओं को कुछ समय के लिए एक-दूसरे के बारे में जानकारी देखने की अनुमति देनी थी, और हम इसका उपयोग करेंगे। आइए ~ ~ एपीआई / उपयोगकर्ताओं / 100 लिंक पर क्लिक करके आईडी = 100 के साथ एक उपयोगकर्ता के बारे में जानने की कोशिश करें:

और अब हम देखते हैं कि एक निश्चित कार्यान्वयन जो किसी भी उपयोगकर्ता के बारे में जानकारी देता है।

निष्कर्ष

इसलिए हम WIF की कुछ विशेषताओं से परिचित हो गए, एक ऐसा उदाहरण छांट दिया, जहाँ से एक लचीली प्राधिकरण प्रणाली का निर्माण शुरू किया जा सकता है, और "कोडित" भी।

आपका ध्यान देने के लिए धन्यवाद।

Xml- आधारित पहुँच नीति कॉन्फ़िगरेशन के साथ दावा-आधारित प्राधिकरण उदाहरण