Asp.net WebApi में कस्टम प्राधिकरण - क्या गड़बड़ है?


113

मैं WebApi में प्राधिकरण के बारे में कई संसाधनों (पुस्तकों और SO उत्तरों) से पढ़ रहा हूं।

मान लीजिए मैं कस्टम विशेषता जोड़ना चाहता हूं जो केवल कुछ उपयोगकर्ताओं के लिए उपयोग की अनुमति देता है:

मामला एक

मैंने ओवरराइडिंग के इस दृष्टिकोण को देखा है OnAuthorization, जो कुछ गलत होने पर प्रतिक्रिया सेट करता है

public class AllowOnlyCertainUsers : AuthorizeAttribute
{
 public override void OnAuthorization(HttpActionContext actionContext)
  {
   if ( /*check if user OK or not*/)
   {
     actionContext.Response = new HttpResponseMessage(HttpStatusCode.Unauthorized);
   }
  }
}

केस # 2

लेकिन मैंने इस तरह के उदाहरण को भी देखा है जो ओवरराइडिंग भी है OnAuthorizationलेकिन कॉलिंग के साथ base:

public override void OnAuthorization(HttpActionContext actionContext) 
{ 
  base.OnAuthorization(actionContext);

    // If not authorized at all, don't bother

    if (actionContext.Response == null)  
     {
      //...
     }
}

फिर, आप जांचें कि HttpActionContext.Responseक्या सेट है या नहीं। यदि यह सेट नहीं है, तो इसका मतलब है कि अनुरोध अधिकृत है और उपयोगकर्ता ठीक है

केस # 3

लेकिन मैंने ओवरराइडिंग के इस दृष्टिकोण को भी देखा है IsAuthorized :

public class AllowOnlyCertainUsers : AuthorizeAttribute
{
 protected override bool IsAuthorized(HttpActionContext context)
  {
   if ( /*check if user OK or not*/)
   {
    return true;// or false
   }
  }
}

केस # 4

और फिर मैंने एक समान उदाहरण देखा, लेकिन कॉलिंग बेस के साथ। सामान्यीकृत (संदर्भ):

protected override bool IsAuthorized(HttpActionContext context)
{
 if (something1 && something2 && base.IsAuthorized(context)) //??
 return true;
 return false;
}

एक और चीज़

और अंत में डोमिनिक ने यहां कहा :

आपको OnAuthorization को ओवरराइड नहीं करना चाहिए - क्योंकि आप [AllowAnonymous] हैंडलिंग को मिस कर रहे होंगे।

प्रशन

  • 1) मुझे किन विधियों का उपयोग करना चाहिए: IsAuthorizedया OnAuthorization? (या कब कौन सा उपयोग करें)

  • 2) मुझे आधार कब कहा जाना चाहिए base.IsAuthorized or

  • 3) क्या उन्होंने इसे बनाया है? कि अगर प्रतिक्रिया शून्य है तो सब कुछ ठीक है? (मामला # 2)

एनबी

कृपया ध्यान दें, मैं उपयोग कर रहा हूं (और उपयोग करना चाहता हूं) केवल AuthorizeAttributeजो पहले से ही विरासत में मिला है AuthorizationFilterAttribute

क्यों ?

ब्यूसेज़ मैं पहले चरण में हूँ: http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api

यहां छवि विवरण दर्ज करें

वैसे भी Im अधिकृत विशेषता के माध्यम से पूछ रहा हूँ।


अधिकृत विशेषता को ओवरराइड करने के लिए आपको क्या चाहिए? आप हमें क्या हासिल करना चाहते हैं? यदि आपको कुछ उपयोगकर्ताओं के लिए उपयोग करने की अनुमति देने की आवश्यकता है, तो इस तरह से अधिकृत [उपयोगकर्ता (उपयोगकर्ता = "व्यवस्थापक") का उपयोग क्यों न करें?
तैइसर जौडेह

1
@TaiseerJoudeh उदाहरण के लिए 10:00 से 12:00 (कॉन्फ़िगर करने योग्य) के बीच उपयोगकर्ताओं को अधिकृत करने का प्रयास करें। आप सादे भूमिकाओं और अधिकृत attr के साथ ऐसा नहीं कर सकते। आपको अपना तर्क देना होगा
रॉय नमिर

जवाबों:


93

मुझे किन विधियों का उपयोग करना चाहिए: IsAuthorized या OnAuthorization? (या कब कौन सा उपयोग करें)

AuthorizationFilterAttributeयदि आपका प्राधिकरण तर्क स्थापित पहचान और भूमिकाओं पर निर्भर नहीं है तो आप विस्तार करेंगे । उपयोगकर्ता संबंधित प्राधिकरण के लिए, आप विस्तार और उपयोग करेंगे AuthorizeAttribute। पूर्व मामले के लिए, आप ओवरराइड करेंगे OnAuthorization। उत्तरार्द्ध मामले के लिए, आप ओवरराइड करेंगे IsAuthorized। जैसा कि आप इन विशेषताओं के स्रोत कोड से देख सकते हैं, OnAuthorizationयदि आप इससे प्राप्त करते हैं तो आपको ओवरराइड करने के लिए आभासी चिह्नित किया गया है AuthorizationFilterAttribute। दूसरी ओर, IsAuthorizedविधि आभासी में चिह्नित है AuthorizeAttribute। मेरा मानना ​​है कि यह इच्छित उपयोग के लिए एक अच्छा सूचक है।

मुझे कब कॉल करना चाहिए। मुझे आधार या आधार कहा जाए।

इस सवाल का जवाब ओओ आमतौर पर कैसे काम करता है। यदि आप एक विधि को ओवरराइड करते हैं, तो आप माता-पिता द्वारा प्रदान किए गए कार्यान्वयन पर या तो पूरी तरह से एक नया कार्यान्वयन या गुल्लक प्रदान कर सकते हैं और व्यवहार को बढ़ा सकते हैं। उदाहरण के लिए, का मामला लें IsAuthorized(HttpActionContext)। आधार वर्ग व्यवहार उपयोगकर्ता / भूमिका की जाँच करने के लिए है जो फ़िल्टर बनाम निर्दिष्ट पहचान में निर्दिष्ट है। कहो, आप वह सब करना चाहते हैं लेकिन इसके अलावा, आप कुछ और जांचना चाहते हैं, एक अनुरोध हेडर या कुछ पर आधारित हो सकता है। उस स्थिति में, आप इस तरह एक ओवरराइड प्रदान कर सकते हैं।

protected override bool IsAuthorized(HttpActionContext actionContext)
{
    bool isAuthroized = base.IsAuthorized(actionContext);
    // Here you look at the header and do your additional stuff based on actionContext
    // and store the result in isRequestHeaderOk
    // Then, you can combine the results
    // return isAuthorized && isRequestHeaderOk;
}

मुझे खेद है, लेकिन अपने Q3 को समझ नहीं पा रहा हूं। BTW, प्राधिकरण फ़िल्टर लंबे समय से आसपास है और लोग इसका उपयोग सभी प्रकार की चीजों के लिए करते हैं और कभी-कभी गलत तरीके से भी करते हैं।

एक और चीज़। और अंत में यहाँ यह लड़का था जिसने कहा था: आपको OnAuthorization को ओवरराइड नहीं करना चाहिए - क्योंकि आप लापता होंगे [AllowAnonymous] हैंडलिंग।

वह आदमी जिसने कहा था कि पहुँच नियंत्रण का देवता है - डोमिनिक। जाहिर है कि यह सही होगा। यदि आप OnAuthorization(नीचे कॉपी की गई) के कार्यान्वयन को देखते हैं ,

public override void OnAuthorization(HttpActionContext actionContext)
{
    if (actionContext == null)
    {
        throw Error.ArgumentNull("actionContext");
    }

    if (SkipAuthorization(actionContext))
    {
        return;
    }

    if (!IsAuthorized(actionContext))
    {
        HandleUnauthorizedRequest(actionContext);
    }
}

कॉल SkipAuthorizationवह हिस्सा है जो यह सुनिश्चित करता है कि AllowAnonymousफ़िल्टर लागू किए गए हैं, अर्थात प्राधिकरण को छोड़ दिया गया है। यदि आप इस विधि को ओवरराइड करते हैं, तो आप उस व्यवहार को ढीला कर देते हैं। वास्तव में, यदि आप अपने प्राधिकरण को उपयोगकर्ताओं / भूमिकाओं पर आधारित करने का निर्णय लेते हैं, तो उस बिंदु पर आपने प्राप्त करने का निर्णय लिया होगा AuthorizeAttribute। उस बिंदु पर आपके लिए केवल सही विकल्प ही ओवरराइड होगा IsAuthorizedऔर पहले से ही ओवरराइड नहीं होगा OnAuthorization, हालांकि यह तकनीकी रूप से भी संभव है।

पुनश्च। ASP.NET वेब एपीआई में, प्रमाणीकरण फिल्टर नामक एक और फिल्टर है। आइडिया यह है कि आप प्रमाणीकरण के लिए और प्राधिकरण फ़िल्टर के लिए उपयोग करते हैं, जैसा कि नाम इंगित करता है। हालांकि, ऐसे कई उदाहरण हैं जहां इस सीमा को ठग लिया जाता है। बहुत सारे ऑथराइजेशन फिल्टर उदाहरण किसी तरह का प्रमाणीकरण करेंगे। वैसे भी, यदि आपके पास समय है और थोड़ा और समझना चाहते हैं, तो इस MSDN लेख पर एक नज़र डालें । डिस्क्लेमर: यह मेरे द्वारा लिखा गया था।


धन्यवाद फिर से, लेकिन अगर मैं लाइनों के बीच पढ़ता हूं, IsAuthenticated को OnAuthirization द्वारा कॉल किया जाता है, तो क्यों नहीं OnAuthorization को ओवरराइड करें और आधार को कॉल करें। एकऑथराइजेशन और फिर प्रतिक्रिया की जांच करें?
रॉय नमिर

आप सुनिश्चित कर सकते हैं, अगर ऐसा है जो आप चाहते हैं।
बद्री

मेरे तीसरे प्रश्न में मेरा मतलब था: आधार फ़ंक्शन चलाने के बाद - आधार। उदाहरण के लिए आधार। यह जांच करने का एकमात्र तरीका है कि क्या यह सफल रहा- रिस्पांस प्रॉपर्टी का निरीक्षण करना है ?, उदाहरण आपकी पुस्तक से हैं :-)
रॉय नमिर?

हां, आमतौर पर आप 401 स्थिति कोड की तलाश करते हैं, लेकिन अशक्त नहीं, जहां तक ​​मुझे पता है। BTW, मुझे OnAuthorizationअपनी पुस्तक में ओवरराइडिंग के बारे में लिखना याद नहीं है । मुझे यकीन है कि मैंने अशक्त के लिए प्रतिक्रिया की जाँच के बारे में नहीं लिखा होगा, coz यह पहली बार है जब मैं इसके बारे में सुन रहा हूँ :)
बद्री

हां मैं दूसरी किताब में उलझ गया। मैं 3 किताबें एक साथ पढ़ रहा हूं: securty (तुम्हारा), प्रैक्टिकल (तुम्हारा) और webapi समर्थक (टुगर्कक, ज़िट्लर, अली)। जैसा कि आप देख सकते हैं - उन्होंने इसे वहां किया: i.stack.imgur.com/LNGi4.jpg - उन्होंने बस चेक किया कि क्या अशक्त है, इसलिए मुझे अशक्त या त्रुटि कोड की जांच करनी चाहिए?
रॉय नमिर

18

ठीक है, मेरा सुझाव यह मानते हुए है कि आप अपने वेब एपीआई की सुरक्षा के लिए OAuth बियरर टोकन का उपयोग कर रहे हैं और जब आप टोकन जारी करते हैं तो आप उपयोगकर्ता के लिए दावा के रूप में अनुमत समय निर्धारित कर रहे हैं। आप टोकन आधारित प्रमाणीकरण के बारे में अधिक यहाँ पढ़ सकते हैं

  1. CustomAuthorizeAttribute बनाएँ जो प्राधिकरण से प्राप्त होता है
  2. ओवरराइड विधि OnAuthorizationAsyncऔर नीचे दिए गए नमूना कोड का उपयोग करें:

     public class CustomAuthorizeAttribute : AuthorizationFilterAttribute
    {
    
        public override Task OnAuthorizationAsync(HttpActionContext actionContext, System.Threading.CancellationToken cancellationToken)
        {
    
            var principal = actionContext.RequestContext.Principal as ClaimsPrincipal;
    
            if (!principal.Identity.IsAuthenticated)
            {
                return Task.FromResult<object>(null);
            }
    
            var userName = principal.FindFirst(ClaimTypes.Name).Value;
            var userAllowedTime = principal.FindFirst("userAllowedTime").Value;
    
            if (currentTime != userAllowedTime)
            {
                actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized, "Not allowed to access...bla bla");
                return Task.FromResult<object>(null);
            }
    
            //User is Authorized, complete execution
            return Task.FromResult<object>(null);
    
        }
    }
  3. अब आपके नियंत्रकों में आप इस प्राधिकरण तर्क का उपयोग करके अपने नियंत्रकों की सुरक्षा के लिए CustomAuthorize विशेषता का उपयोग करते हैं।

1
धन्यवाद। लेकिन मैं वर्तमान में उपयोग कर रहा हूँ AuthorizeAttributeजो AuthorizationFilterAttributeसीखने के लिए विरासत और -लो के लिए है, मैंने विशेष रूप से पूछा कि मुझे किस विधि का उपयोग करना चाहिए और प्रतिक्रिया के बारे में सामग्री है या नहीं ...
रॉय नामी

3

ASP.NET v5 ने एक पूरी तरह से नया प्राधिकरण सिस्टम पेश किया। जो लोग .NET .NET का उपयोग करने जा रहे हैं उनके लिए मैं Microsoft.AspNet.Authorization में जाने का सुझाव दूंगा।

काफी यह दोनों रखने की वजह से गंदगी लपेटता System.Web.Http.Authorizeऔर System.Web.Mvc.Authorizeऔर अन्य पुराने प्रमाणीकरण कार्यान्वयन।

यह एक्शन टाइप्स (क्रिएट, रीड, अपडेट, डिलीट), रिसोर्स, रोल्स, क्लेम, व्यू, कस्टम रिक्वायरमेंट का बहुत अच्छा एब्स्ट्रैक्शन प्रदान करता है और ऊपर दिए गए किसी भी संयोजन को कस्टम हैंडलर बनाने की अनुमति देता है। इसके अलावा उन हैंडलर का उपयोग संयोजन में भी किया जा सकता है।

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


14
जानने के लिए अच्छा है, लेकिन सवाल का जवाब नहीं है।
जीरो 3
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.