Transformation de revendications simples pour un RP-STS à Genève

Question

Après avoir lu l'article MSDN ( http://msdn.microsoft .com / fr-us / magazine / 2009.01.genevests.aspx ) à propos de l’implémentation d’un STS personnalisé à l’aide du Microsoft Geneva Framework Je suis un peu perplexe devant l’un des scénarios abordés dans ce document. Ce scénario est illustré à la figure 13 de l'article cité en référence.

Mes questions sont de savoir comment le RP initie-t-il l'appel du RP-STS afin de transmettre les revendications déjà obtenues de l'IP-STS? Comment la méthode souhaitée, DeleteOrder (), devient-elle une demande de revendication pour la revendication Action du RP-STS qui répond par la demande Action avec une valeur Delete qui autorise l'appel? Je pense également que le chiffre est légèrement incorrect en ce que l'interaction entre le RP-STS et le moteur de politique doit avoir les revendications et les flèches dans le sens inverse.

Je peux voir la structure, mais on ne sait pas ce qui est fourni par Geneva / WCF et ce qui doit être fait dans le code à l'intérieur du RP, ce qui semblerait un peu étrange puisque nous ne pourrions pas protéger la méthode DeleteOrder avec une demande PrincipalPermission Supprimer " permission " mais il faudrait d’abord demander un rôle, puis obtenir la déclaration détaillée de l’action de suppression après ce moment.

Si j’ai manqué le point (car je ne trouve pas ce cas couvert facilement sur le Web), alors excuses-moi!

Merci d'avance.

Answer 1

J'ai posé la même question sur le Forum de Genève à http://social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required et j'ai eu cette réponse:

Bonjour Dokie,

Je me demandais la même chose quand j'ai lu cet article. Après avoir réfléchi à la mise en œuvre d'un tel scénario, j'ai proposé deux idées:

1. Le RP est en fait configuré pour exiger des demandes du RP-STS; le RP-STS nécessite un jeton de sécurité de la part de l'IP-STS. En conséquence, lorsque le sujet demande une ressource du RP, il le renvoie au RP-STS qui le renvoie à l’IP-STS. Après s'être authentifié, il est renvoyé au RP-STS. Les revendications centrées sur l'identité sont transformées en revendications nécessaires pour prendre une décision d'autorisation et renvoyées au RP.

2. Le RP est configuré pour avoir un intercepteur (par exemple, un AuthorizationPolicy s'il s'agit d'un service WCF) qui saisit l'appel, voit les revendications centrées sur l'identité, crée un RST (à l'aide du WSTrustClient), le transmet au RP-STS, ce service étend les revendications à un nouveau qui est renvoyé au RP, et le RP prend une décision d’autorisation.

Je n’ai jamais mis cela en pratique, mais si j’allais le faire, j’explorerais davantage ces deux idées.

HTH!

Cordialement,

Travis Spencer

Donc, je vais d'abord essayer l'option 2 et voir si cela fonctionne, puis formuler une réponse ici.

Answer 2

J'ai la situation 1 qui fonctionne bien. Dans mon cas, AD FS est le service d’identité et un STS personnalisé le STS de ressources.

Toutes les applications Web utilisent le même Resource STS, mais après qu'un utilisateur a visité une autre application, les revendications répétées par l'identité ne sont pas à nouveau ajoutées par AD FS, car l'utilisateur est déjà authentifié. Comment puis-je forcer ou demander à nouveau les réclamations de base à AD FS?

J'ai créé un appel à AD FS avec ActAs. À présent, il renvoie mes demandes d'identification. N'oubliez pas d'activer une règle autorisée par la délégation pour les informations d'identification utilisées pour appeler les services AD FS.

string stsEndpoint = "https://<ADFS>/adfs/services/trust/2005/usernamemixed";
     var trustChannelFactory = new WSTrustChannelFactory(new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential), stsEndpoint);

     trustChannelFactory.Credentials.UserName.UserName = @"DELEGATE";
     trustChannelFactory.Credentials.UserName.Password = @"PASSWORD";

     trustChannelFactory.TrustVersion = TrustVersion.WSTrustFeb2005;

     //// Prepare the RST.
     //var trustChannelFactory = new WSTrustChannelFactory(tokenParameters.IssuerBinding, tokenParameters.IssuerAddress);
     var trustChannel = (WSTrustChannel)trustChannelFactory.CreateChannel();

     var rst = new RequestSecurityToken(RequestTypes.Issue);

     rst.AppliesTo = new EndpointAddress(@"https:<RPADDRESS>");

     // If you're doing delegation, set the ActAs value.
     var principal = Thread.CurrentPrincipal as IClaimsPrincipal;
     var bootstrapToken = principal.Identities[0].BootstrapToken;

     // The bootstraptoken is the token received from the AD FS after succesfull authentication, this can be reused to call the AD FS the the users credentials
     if (bootstrapToken == null)
     {
        throw new Exception("Bootstraptoken is empty, make sure SaveBootstrapTokens = true at the RP");
     }

     rst.ActAs = new SecurityTokenElement(bootstrapToken);

     // Beware, this mode make's sure that there is no certficiate needed for the RP -> AD FS communication
     rst.KeyType = KeyTypes.Bearer;

     // Disable the need for AD FS to crypt the data to R-STS
     Scope.SymmetricKeyEncryptionRequired = false;

     // Here's where you can look up claims requirements dynamically.
     rst.Claims.Add(new RequestClaim(ClaimTypes.Name));
     rst.Claims.Add(new RequestClaim(ClaimTypes.PrimarySid));

     // Get the token and attach it to the channel before making a request.
     RequestSecurityTokenResponse rstr = null;
     var issuedToken = trustChannel.Issue(rst, out rstr);
     var claims = GetClaimsFromToken((GenericXmlSecurityToken)issuedToken);

 private static ClaimCollection GetClaimsFromToken(GenericXmlSecurityToken genericToken)
  {
     var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
     var token = handlers.ReadToken(new XmlTextReader(new StringReader(genericToken.TokenXml.OuterXml)));
     return handlers.ValidateToken(token).First().Claims;
  }