ASP.NET पहचान हमारे अपने वाहक सर्वर

Question

सभी के खिलाफ 2.0 प्रमाणित,

मैं एक सुरक्षा सर्वर जो एकमात्र उद्देश्य एक भी अंत बिंदु से वाहक टोकन प्रदान करना है मिल गया है: http://example.com/token

उदाहरण अनुरोध:

POST http://example.com/token HTTP/1.1 
User-Agent: Fiddler 
Content-Type: x-www-form-urlencoded 
Host: example.com 
Content-Length: 73 

grant_type=password&username=example@example.com&password=examplePassword 

उदाहरण प्रतिक्रिया:

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Pragma: no-cache 
Content-Type: application/json;charset=UTF-8 
Expires: -1 
Server: Microsoft-IIS/10.0 
X-Powered-By: ASP.NET 
Date: Tue, 16 Aug 2016 12:04:39 GMT 
{ 
    "access_token": "xxxx", 
    "token_type": "bearer", 
    "expires_in": 17999, 
    "refresh_token": "xxxx", 
    ".issued": "Tue, 16 Aug 2016 12:04:38 GMT", 
    ".expires": "Tue, 16 Aug 2016 17:04:38 GMT" 
} 

हम हवलदार ई एक कोणीय अनुप्रयोग जो प्रमाणीकरण के लिए इस एंडपॉइंट का उपयोग करता है, और यह ठीक है।

हम जो भी सफलता हासिल करने की कोशिश कर रहे हैं वह एक एमवीसी एप्लीकेशन बनाना है जो प्रमाणित करने के लिए उसी सर्वर का उपयोग करता है, हम कोड को पहचान 2.0 के शीर्ष पर बैठना चाहते हैं।

हमारे AccountController (उदाहरण के परियोजना) में हम अपने Login(LoginModel model) तरीका है जिसके लॉगिन संभालती है और इस तरह दिखता है (एक ही रूप में उदाहरण के प्रोजेक्ट टेम्पलेट):

var result = await _signInManager.PasswordSignInAsync(model.UserName, model.Password, model.RememberMe, shouldLockout: false); 

हम IUserStore, UserManager, SignInManager की अपनी अंतर्गत प्रयोग किया है।

मैं अधिभावी पर विचार किया है

public Task<SignInStatus> PasswordSignInAsync(string userName, string password, bool isPersistent, bool shouldLockout) on `SignInManager<,>` and make a web call across to the security server. 

PasswordSignInAsync कॉल की डिफ़ॉल्ट कार्यान्वयन UserManager.FindByNameAsync लेकिन इसका मतलब यह होगा कि मैं अपने सुरक्षा सर्वर पर एक देखने विधि का पर्दाफाश करने की पुष्टि के लिए एक उपयोगकर्ता नाम मौजूद है जो वास्तव में नहीं है होगा अच्छा प्रतीत होता है।

मुझे कुछ याद आना चाहिए और मुझे पता है कि यह जटिल नहीं होगा, हमारे एमवीसी ऐप को कुकी प्रमाणीकरण का उपयोग करने की आवश्यकता है, लेकिन हमारे अन्य संसाधन सर्वर के बाद के कॉल के लिए भालू टोकन को भी बनाए रखना है।

(मुझे सराहना है कि मैं यहां प्रौद्योगिकियों को मिश्रित कर सकता हूं, इसलिए सवाल)।

यह ओविन पर भी चल रहा है।

Answer 1

इस मामले में, मुझे नहीं लगता कि आपको अपने एमवीसी एप्लिकेशन में पहचान 2.0 का उपयोग करना चाहिए। आप अपने प्रमाणीकरण सर्वर कॉल करने के लिए एक AuthenticationClient बनाना चाहिए, तो आप भी इस पुस्तकालय इस्तेमाल कर सकते हैं इस तरह के एक ग्राहक https://www.nuget.org/packages/Thinktecture.IdentityModel.Client/

public class AuthenticationClient { 
    public ClaimsIdentity GetClaimsIdentity(string username, string password) { 
     //Call your authentication server to get your token and also claims associated with your identity. 
     //You can look at an example code how to do it: https://github.com/IdentityServer/IdentityServer3.Samples/blob/master/source/Clients/ConsoleResourceOwnerClient/Program.cs 
     //and create a ClaimsIdentity object out of those information 

     var identity = GetIdentity(); 

     //The key point here is to add AccessToken and RefreshToken as custom claims to your identity so you retrieve these tokens back on subsequent requests. 
     identity.AddClaim(new Claim("access_token", accessToken)); 
     identity.AddClaim(new Claim("refresh_token", refreshToken)); 
    } 
} 

यह अपनी आवश्यकताओं को पूरा करेगा निर्माण करने के लिए:

उपयोग कुकी प्रमाणीकरण लेकिन यह भी भालू को बनाए रखने हमारे अन्य संसाधन सर्वर के बाद की कॉल के लिए टोकन।

AccountController पर आपका Login विधि इस तरह होना चाहिए:

public ActionResult Login(LoginModel model) 
{ 
    var identity = authenticationClient.GetClaimsIdentity(model.UserName, model.Password); 

    if (identity == null) { 
     return new HttpUnauthorizedResult(); 
    } 
    //Sign in the user 
    var ctx = Request.GetOwinContext(); 
    var authenticationManager = ctx.Authentication; 
    authenticationManager.SignIn(identity); 

    return new HttpStatusCodeResult(HttpStatusCode.OK); 
} 

मुझे लगता है कि आप पहले से ही इस मिडलवेयर रजिस्टर कुकी प्रमाणीकरण का उपयोग करने के लिए: बाद के सभी अनुरोधों के लिए अब

public void ConfigureAuth(IAppBuilder app) 
{ 
    app.UseCookieAuthentication(new CookieAuthenticationOptions 
    { 
     AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
     LoginPath = new PathString("/Account/Login") 
    }); 
} 

, आप अपने संसाधन सर्वर को अपने दावे से कॉल करने के लिए पहुंच टोकन वापस पुनर्प्राप्त कर सकता है Identity:

User.Identity.Claims.FirstOrDefault(x => x.Type == "access_token");