2016-02-23 6 views
10

डब्ल्यूआईएफ से पहले, Application_PostAcquireRequestState एक कस्टम पहचान बनाने के लिए एक अच्छी जगह थी, लेकिन यह सुनिश्चित करने के लिए बहुत सारे ढांचे की आवश्यकता थी कि आप जिस प्रकार के प्रमाणीकरण को कर रहे थे वह उचित रूप से मैप किया गया था। कस्टम पहचान से, मेरा मतलब है पहचान से वंचित वर्ग, जैसे कि नीचे कुछ निश्चितता, ताकि हम एक विशिष्ट संपत्ति प्राप्त कर सकें जिसके लिए हमें सभी प्रमाणीकृत उपयोगकर्ताओं की आवश्यकता हो सकती है।एमवीसी आवेदन में डब्ल्यूआईएफ के साथ कस्टम पहचान कहां बनाएं?

PostAququirerequestState अभी भी उपलब्ध है, लेकिन नए तरीके हैं जिनके साथ आप प्रमाणीकरण में हुक कर सकते हैं। इसके अतिरिक्त, कई प्रमाणीकरण विधियों का समर्थन करते समय पुराने तरीके जटिल हो जाते हैं।

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

मेरा एमवीसी प्रोजेक्ट AccountController के साथ आया था जिसमें ExternalLoginCallback था जो बाहरी प्रमाणीकरण पूरा होने पर लागू किया गया नाम एक अच्छा हुक हो सकता है (जो मुझे SAML एक "बाहरी" प्रमाणीकरण है)। हालांकि, यह किसी SAML प्रमाणीकरण के दौरान/उसके बाद किसी भी बिंदु पर हिट नहीं लग रहा है।

यह जवाब हो सकता है कि हमें अभी भी इसे अपने आप को पुराने तरीके से टुकड़ा करने की जरूरत है, लेकिन मुझे उम्मीद थी कि डब्ल्यूआईएफ के पास यह आसान बनाने के लिए कुछ बेहतर ढांचे के हुक थे।

public sealed class SomeIdentity : Identity 
{ 
    ... 
    // Some custom properties 
    public string SomeProperty { get;set;} 
} 

protected void Application_PostAcquireRequestState(object sender, EventArgs e) 
{ 
    ... 
    identity = new SomeIdentity(id, userId); 
    // map a claim to a specific property 
    identity.SomeProperty = ...Claims[IdpSomePropertyKey]; 
    ///... 

    GenericPrincipal newPrincipal = new GenericPrincipal(identity , null); 
    HttpContext.Current.User = newPrincipal; 
    System.Threading.Thread.CurrentPrincipal = newPrincipal; 
} 

अब जब कि मैं WIF उपयोग कर रहा हूँ, जहाँ मैं कोड है कि एक विशेष प्रमाणीकरण प्रकार (अर्थात। Kentor.AuthServices SAML) जो एक कस्टम SomeIdentity बनाता है के लिए विशिष्ट है डाल किया जाना चाहिए?

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

+0

आप सरल उदाहरण के लिए देखने के लिए कोशिश की है? https://github.com/valkovnet/IdentityServer, https://github.com/IdentityServer/IdentityServer2। वास्तव में, मुख्य चाल Web.config में पहचान सर्वर को कॉन्फ़िगर करना है। यह आपको संघीय प्रमाणीकरण पहुंच प्रदान करेगा – deeptowncitizen

+0

सरल उदाहरण आमतौर पर कस्टम पहचान के बिना सरल वेब.कॉन्फिग आधारित कॉन्फ़िगरेशन होते हैं। मैंने valkovnet उदाहरण देखा और यह एक समाधान है जब आप एक नई परियोजना उत्पन्न करते हैं और फिर web.config में WIF सेट करते हैं। वास्तव में कोई प्रोग्रामेटिक कॉन्फ़िगरेशन या पहचान की सेटिंग नहीं थी जो मुझे तब तक मिल सकती थी जब तक कि मैं सही जगह पर नहीं देख रहा था। – AaronLS

+0

क्या यह एक ओविन ऐप है? क्या आपके पास App_Start फ़ोल्डर है? –

उत्तर

4

ठीक है, मैं इस पर एक स्टैब लेने जा रहा हूं, और उम्मीद है कि मैं आपका प्रश्न समझ रहा हूं और आपके कोड के बारे में बहुत अधिक धारणा नहीं कर रहा हूं। जिन धारणाओं को मैं करने जा रहा हूं वह यह है कि "नो प्रमाणीकरण" विकल्प के साथ विजुअल स्टूडियो एएसपी.NET 4.6 टेम्पलेट का उपयोग करके बनाया गया एक नया नया एमवीसी ऐप है (जो आप अपनी स्थिति के बारे में समझते हैं, उसके आधार पर, आप इस डेटा को स्टोर नहीं करना चाहते हैं जितना ज्यादा इसे दावों से पढ़ा जाए)।

, अपनी परियोजना

using Microsoft.Owin; 
using Owin; 

[assembly: OwinStartup(typeof(WebApplication1.Startup))] 

namespace WebApplication1 
{ 
    public partial class Startup 
    { 
     public void Configuration(IAppBuilder app) 
     { 
      ConfigureAuth(app); 
     } 
    } 
} 

अब इस, को चलाने के लिए जैसा कि आप शायद अनुमान लगा सकते हैं जा रहा है के मार्ग पर एक वर्ग शुरू किया बुलाया जोड़ें "प्रारंभ करेंगे" एक global.asax.cs फ़ाइल की तरह ही होता है पर।

अब हमें वास्तव में ConfigureAuth() विधि बनाने की आवश्यकता है। यह आमतौर पर App_Start फ़ोल्डर में "Startup.Auth.cs" नामक फ़ाइल के साथ किया जाता है।इस फ़ाइल में वर्तमान में मौजूद नहीं है, इसलिए आगे जाना है और इस टेम्पलेट

using Owin; 
using Kentor.AuthServices.Owin; 

namespace WebApplication1 
{ 
    public partial class Startup 
    { 
     private void ConfigureAuth(IAppBuilder app) 
     { 
     } 
    } 
} 

साथ इसे बनाने यह वह जगह है जहां हम अपने प्रमाणीकरण तर्क/सेटिंग्स क्या करने जा रहे हैं। ओविन बॉक्स के बाहर कुछ प्रमाणीकरण रणनीतियों के साथ आता है, और कुछ और पुस्तकालय भी हैं। यदि आप अपना खुद का लिखने जा रहे हैं तो मैं OwinOAuthProviders पर एक नज़र डालने की सलाह देता हूं।

आगे बढ़ें और NuGet पैकेज Kentor.AuthServices.Owin पैकेज और निर्भरताओं को स्थापित करें। इस समय आपके पास मौजूद किसी भी संकलन त्रुटियों को ठीक करना चाहिए। आपको बाद में अपने प्रोजेक्ट में System.IdentityModel का संदर्भ जोड़ने की भी आवश्यकता होगी।

अब, Startup.Auth.cs के अंदर अपनी कॉन्फ़िगरएथ विधि में, आप निम्न कार्य करके अपने ऐप में केंटोर जोड़ सकते हैं।

Public void ConfigureAuth(IAppBuilder app) 
{ 
    var kentorOptions = new KentorAuthServicesAuthenticationOptions(true); 
} 

अब आप अपने चर kentorOptions के बाद से मैं पारित कर दिया है कि यह सच है, अपने WebConfig से अपनी सेटिंग्स में पढ़ा जाएगा। हालांकि आप उन्हें यहां मैन्युअल रूप से कॉन्फ़िगर भी कर सकते हैं।

जिस भाग में हम रुचि रखते हैं वह है kentorOptions.SPOptions.SystemIdentityModelIdentityConfiguration.Claims प्रमाणीकरण प्रबंधक संपत्ति। आने वाले दावों के आधार पर पहचान प्रदान करने के लिए हम एक कस्टम दावा प्रमाणीकरण प्रबंधक बनाना चाहते हैं।

एक नया वर्ग है कि यही कारण है कि जहां आप अपनी पहचान कोड है ClaimsAuthenticationManager

using System.Security.Claims; 

namespace WebApplication5 { 
    public class CustomClaimsAuthManager : ClaimsAuthenticationManager { 
     public override ClaimsPrincipal Authenticate(string resourceName, ClaimsPrincipal incomingPrincipal) { 
      ClaimsIdentity ident = (ClaimsIdentity) incomingPrincipal.Identity; 
      //Use incomingPrincipal.Identity.AuthenticationType to determine how they got auth'd 
      //Use incomingPrincipal.Identity.IsAuthenticated to make sure they are authenticated. 
      //Use ident.AddClaim to add a new claim to the user 
      ... 
      identity = new SomeIdentity(id, userId); 
      // map a claim to a specific property 
      identity.SomeProperty = ...Claims[IdpSomePropertyKey]; 
      ///... 

      GenericPrincipal newPrincipal = new GenericPrincipal(identity, null); 
      return newPrincipal; 
     } 
    } 
} 

से विरासत करें। अब आखिर में हमें दावा करने के लिए दावे प्रमाणीकरण प्रबंधक के रूप में सेट करने की आवश्यकता है, और ओपन पाइपलाइन में केंटोर का उपयोग करने के लिए अपने ऐप को बताएं। यह सब वापस Startup.Auth.cs फ़ाइल में है।

private void ConfigureAuth(IAppBuilder app) { 
      var kentorOptions = new KentorAuthServicesAuthenticationOptions(true); 
      kentorOptions.SPOptions.SystemIdentityModelIdentityConfiguration.ClaimsAuthenticationManager = new WebApplication5.CustomClaimsAuthManager(); 
      app.UseKentorAuthServicesAuthentication(kentorOptions); 
     } 

Annnndd जो उम्मीद करनी चाहिए! अन्य प्रमाणीकरण प्रदाताओं के लिए, OwinOAuthProviders से लोगों की तरह, आप भी बातें options.Provider तरीकों अधिभावी इसलिए की तरह अलग अलग घटनाओं पर काम करने के लिए, द्वारा हेरफेर कर सकते हैं:

var cookieOptions = new CookieAuthenticationOptions { 
       AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
       LoginPath = new PathString("/Auth/Login"), 
       CookieName = "cooooookiees", 
       ExpireTimeSpan = new TimeSpan(10000, 0, 0, 0, 0), 
       Provider = new CookieAuthenticationProvider { 
        OnException = context => { 
         var x = context; 
        }, 
        OnValidateIdentity = async context => { 
         var invalidateBySecurityStamp = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
         validateInterval: TimeSpan.FromMinutes(15), 
         regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager)); 
         await invalidateBySecurityStamp.Invoke(context); 

         if (context.Identity == null || !context.Identity.IsAuthenticated) { 
          return; 
         } 
         var newResponseGrant = context.OwinContext.Authentication.AuthenticationResponseGrant; 
         if (newResponseGrant != null) { 
          newResponseGrant.Properties.IsPersistent = true; 
         } 

        } 
       } 
      }; 
      app.UseCookieAuthentication(cookieOptions); 
+0

ऐसा लगता है कि यह वही है जो मुझे चाहिए। मुख्य बात यह है कि मैंने दावे ** प्राधिकरण ** प्रबंधक ट्यूटोरियल्स को देखा था, यह निर्धारित किया कि गलत बात थी, और कभी दावा नहीं किया ** प्रमाणीकरण ** प्रबंधक। एक बार सत्यापित होने के बाद मैं बक्षीस और पुरस्कार प्रस्तुत करूंगा। – AaronLS

+0

@AaronLS हाँ, जो मुझे एक से भी अधिक बार फिसल गया है। प्रमाणीकरण वह जगह है जहां आप दावों को असाइन करना चाहते हैं, प्राधिकरण वह स्थान है जहां आप उन दावों के आधार पर अस्वीकार करना या पहुंच देना चाहते हैं। मैं खुशी से मदद कर सकता है! मुझे पता है कि मुझे इससे पहले एक बार सामना करना पड़ा था, उम्मीद है कि यह कुछ सीखने के दर्द से कुछ बचाता है। –

+0

यह काम कर रहा है जहां प्रमाणीकृत सफलतापूर्वक सेट किया जा रहा है।हालांकि, मैं एक जेनेरिक प्रिंसिपल को एक कस्टम इडेंटिटी कार्यान्वयन IIDentity के साथ लौट रहा हूं, लेकिन ** ** दावों से वंशानुगत नहीं है। ग्लोबल असैक्स में, PostAququireRequestState अभी भी दावा दावे और दावे प्रिंसिपल दिखाता है। मैं इसे स्पष्ट रूप से 'HttpContext.Current.User' और' System.Threading.Thread.CurrentPrincipal 'पर भी सेट कर रहा हूं लेकिन कुछ खाली दावों के साथ कहीं और इन पर दावा करता है कि यह किसी भी अन्य पर दावा करता है, लेकिन यह मान्यता प्राप्त सत्य पर चलता है। हो सकता है कि गैर-दावा Identity अच्छी तरह से समर्थित नहीं है? – AaronLS

संबंधित मुद्दे