2014-11-28 14 views
11

Mam pytania dotyczące korzystania z nowej platformy ASP.Net OpenID Connect podczas dodawania nowych roszczeń podczas procesu uwierzytelniania, jak pokazano w poniższym kodzie. Nie jestem pewien, ile "magii" dzieje się za kulisami. Myślę, że większość moich pytań koncentruje się na nieznajomości oprogramowania pośredniczącego OWIN w przeciwieństwie do OpenID Connect.Jak ustawić roszczenia z komponentów OWIN ASP.Net OpenID Connect?

Q1. Czy muszę ręcznie ustawić HttpContext.Current.User i Thread.CurrentPrincipal z OwinContext.Authentication.User?

Q2. Chcę możliwość dodawania typów obiektów do roszczeń, takich jak w przypadku System.IdentityModel.Claims.Claim. Nowa klasa System.Security.Claims.Claim akceptuje tylko wartości łańcuchowe?

Q3. Czy muszę używać nowego opakowania SessionSecurityToken do mojego ClaimsPrincipal w System.Security.Claims.CurrentPrincipal do serializowania do pliku cookie - używam app.UseCookieAuthentication(new CookieAuthenticationOptions());, ale teraz jestem pewien, co to dokładnie robi w zakresie utrzymania jakichkolwiek dodatkowych roszczeń dodanych podczas zdarzenia SecurityTokenValidated?

public void ConfigureAuth(IAppBuilder app) 
    { 
     app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType); 
     app.UseCookieAuthentication(new CookieAuthenticationOptions()); 
     app.UseOpenIdConnectAuthentication(
      new OpenIdConnectAuthenticationOptions 
      { 
       ClientId = clientId, 
       Authority = authority, 
       PostLogoutRedirectUri = postLogoutRedirectUri, 

       Notifications = new OpenIdConnectAuthenticationNotifications() 
       { 
        SecurityTokenValidated = (context) => 
        { 
         // retriever caller data from the incoming principal 
         var UPN = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.Name).Value; 
         var db = new SOSBIADPEntities(); 

         var user = db.DomainUser.FirstOrDefault(b => (b.EntityName == UPN)); 

         if (user == null) 
         { 
          // the caller was not a registered user - throw to block the authentication flow 
          throw new SecurityTokenValidationException(); 
         } 

         var applicationUserIdentity = new ClaimsIdentity(); 
         applicationUserIdentity.AddClaim(new Claim(ClaimTypes.Name, UPN, "")); 
         applicationUserIdentity.AddClaim(new Claim(ClaimTypes.Sid, user.ID.ToString(CultureInfo.InvariantCulture))); 


         var applications = 
          db.ApplicationUser 
          .Where(x => x.ApplicationChild != null && x.DomainUser.ID == user.ID) 
          .Select(x => x.ApplicationChild).OrderBy(x => x.SortOrder); 

         applications.ForEach(x => 
          applicationUserIdentity.AddClaim(new Claim(ClaimTypes.System, x.ID.ToString(CultureInfo.InvariantCulture)))); 

         context.OwinContext.Authentication.User.AddIdentity(applicationUserIdentity); 

         var hasOutlook = context.OwinContext.Authentication.User.HasClaim(ClaimTypes.System, "1"); 

         hasOutlook = hasOutlook; 

         HttpContext.Current.User = context.OwinContext.Authentication.User; 
         Thread.CurrentPrincipal = context.OwinContext.Authentication.User; 

         var usr = HttpContext.Current.User; 

         var c = System.Security.Claims.ClaimsPrincipal.Current.Claims.Count(); 


         return Task.FromResult(0); 
        }, 
       } 
      } 
     ); 
    } 

Odpowiedz

15

Czy istnieje szczególny powód, dla którego dodajesz nowy numer ClaimsIdentity?

Najprostszym sposobem zrobienia tego, do czego dążysz, jest odzyskanie ClaimsIdentity wygenerowanego przez sprawdzenie przychodzącego tokena poprzez ClaimsIdentity claimsId = context.AuthenticationTicket.Identity; po jego uzyskaniu, wystarczy dodać do niego roszczenia. Reszta oprogramowania pośredniczącego zajmie się serializowaniem go w pliku cookie sesji wraz ze wszystkim innym, umieszczeniem wyniku w bieżącym ClaimsPrincipal i wszystkich innych rzeczach, które wydają się próbować wykonywać ręcznie.
HTH
V.