2016-07-01 5 views
0

Hier ist die Situation: Ich versuche SSO in eine vorhandene .NET Webform/MVC/WebApi-Umgebung unter Verwendung von IdentiyServer3 zu integrieren. Da es kein zentralisiertes Rollenmanagement gibt, dient SSO nur der Identität. Jede Anwendung übernimmt ihre eigene Rolle und Berechtigung. Kann auch nicht zu viele Änderungen verlangen, also müssen alle Rolleninhalte von IsInrole, Authorize (Role = "") und Web.Config funktionieren.SSO mit anwendungsspezifischen Berechtigungsrollen und Autorisierung

Die Frage ist: wo stopf ich die Behauptung/Rolle? Ich habe versucht, es wie folgt hinzuzufügen, aber dann beginnen zwei Anwendungen, die Rollen des anderen zu sehen. Klingt nicht richtig.

Notifications = new OpenIdConnectAuthenticationNotifications { 
SecurityTokenValidated = async n => { 
    var id = n.AuthenticationTicket.Identity; 
    var nid = new ClaimsIdentity(id.AuthenticationType, 
     ClaimTypes.Email, ClaimTypes.Role); 

    nid.AddClaim(id.FindFirst(ClaimTypes.Email)); 
    nid.AddClaim(new Claim(ClaimTypes.Role, "admin")); 

Habe ich etwas Wichtiges vermisst? Tut mir leid, wenn es zu dumm klingt. Ich bin zu neu, um es besser zu wissen, und es gibt nicht genug gute Keywords, um es im Web einzugrenzen.

Zusammenfassend, ich brauche eine SSO-Lösung, wo jeder Client seinen eigenen Rollenanspruch und seine Berechtigung behandelt. Danke

+0

BTW, ich habe eine CustomClaimPriccal: ClaimPrincipal. Versuchen Sie, IsInRole zu überschreiben, das ist in Ordnung, funktioniert aber nicht mit [Authorize (Roles = "admin")]. Versuchen Sie auch, ein CustomAuthorizeAttribute zu erstellen, überschreiben Sie OnAuthorize ... ohne Erfolg. – Whoever

+0

Vielen Dank für die Frage hier zu bewegen. In der letzten Runde habe ich eine OwinMiddleware erstellt, nehme context.Authentication.User, erstelle ein neues CustomClaimPrincipal und stopf es zurück. Es klappt. Ich habe 3 Apps in 3 Tabs, jedes erhält seine eigenen Ansprüche von DI-injizierten Service bei jeder Aktualisierung der Seite. Aber ich bin mir immer noch nicht sicher, ob dies der richtige Ansatz ist. Irgendwelche Vorschläge? – Whoever

Antwort

0

Warten Sie eine Sekunde, ich denke, diese frühere Version von IdentityModel.Owin.ClaimsTransformation ist genau das, was ich getan habe. Meins ist natürlich nicht so poliert.

Ich war einfach nicht sicher, Authentifizierung zu ersetzen. Benutzer wie das ist sicher.

var transformedPrincipal = await _options.ClaimsTransformation(context.Authentication.User); 
context.Authentication.User = new ClaimsPrincipal(transformedPrincipal); 

aktualisieren:

über die ClaimsTransformation Middleware-up anpassen Ended von

public Func<ClaimsPrincipal, Task<ClaimsPrincipal>> ClaimsTransformation { get; set; } 

zu

public Func<string, Task<List<Claim>> ClaimsTransformation { get; set; } 

Futter ein ICustomClaimProvider es, die eine Liste von Benutzerrück Ansprüche von ID aus der Datenbank. Dann statt

context.Authentication.User = new ClaimsPrincipal(transformedPrincipal); 

diese

context.Authentication.User.AddIdentity(new ClaimsIdentity(claims, "appid")); 

Jetzt Benutzer hat zwei Identitäten, ein Original, enthält eine anwendungsspezifische Ansprüche. Scheint gut zu funktionieren, wenn ich es richtig verstehe.