Transformación de reclamaciones simples para un RP-STS en el marco de Ginebra

Question

Después de leer el artículo de MSDN ( http://msdn.microsoft .com / en-us / magazine / 2009.01.genevests.aspx ) sobre la implementación de un STS personalizado utilizando Microsoft Geneva Framework Estoy un poco confundido acerca de uno de los escenarios que se cubren allí. Este escenario se muestra en la figura 13 del artículo mencionado anteriormente.

Mis preguntas son acerca de cómo el RP inicia la llamada al RP-STS para pasar las reclamaciones ya obtenidas del IP-STS. ¿Cómo se convierte el método deseado DeleteOrder () en una solicitud de reclamo para el reclamo de acción del RP-STS que responde con el reclamo de acción con un valor de borrado que autoriza la llamada? También creo que la cifra es ligeramente incorrecta, ya que la interacción entre el RP-STS y el Motor de Políticas debería tener las Reclamaciones y las flechas al revés.

Puedo ver la estructura pero no está claro qué es lo que proporciona Geneva / WCF y qué se debe hacer en el código dentro del RP, lo que parece un poco extraño ya que no pudimos proteger el método DeleteOrder con una demanda de Permiso de Autorización Principal para el permiso " permiso " pero tendría que exigir un rol primero y luego obtener el reclamo detallado de la acción de eliminación después de ese punto.

Si me he perdido el punto (ya que no puedo encontrar este caso cubierto fácilmente en la Web), ¡disculpas!

Gracias de antemano.

Answer 1

Hice la misma pregunta en el Foro de Ginebra en http://social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required y obtuve esta respuesta:

Hola Dokie,

Me pregunté esto mismo cuando leí ese artículo. Como he reflexionado sobre cómo se implementaría tal escenario, surgieron dos ideas:

1. El RP está realmente configurado para requerir reclamaciones del RP-STS; el RP-STS requiere un token de seguridad del IP-STS. Como resultado, cuando el sujeto solicita un recurso del RP, lo envía al RP-STS, quien lo hace al IP-STS. Después de autenticarse allí, se devuelve al RP-STS, las reclamaciones centradas en la identidad se transforman en las necesarias para tomar una decisión de autorización y se devuelven al RP.

2. El RP está configurado para tener un interceptor (por ejemplo, una Política de Autorización si es un servicio de WCF) que capta la llamada, ve las reclamaciones centradas en la identidad, crea un RST (usando el WSTrustClient), lo pasa al RP-STS, ese servicio expande las reclamaciones a una nueva que se devuelven al RP, y el RP toma una decisión de autorización.

Nunca implementé esto, pero, si lo fuera, exploraría esas dos ideas más.

HTH!

---

Saludos,

Travis Spencer

Primero probaré la opción 2 y veré si funciona, entonces formule una respuesta aquí.

Answer 2

Tengo una situación que funciona bien. En mi caso, AD FS es el servicio de identidad y un STS personalizado es el recurso STS.

Todas las aplicaciones web utilizan el mismo recurso STS, pero después de que un usuario visita otra aplicación, AD AD no vuelve a agregar las reclamaciones de Identidad ya que el usuario ya está autenticado. ¿Cómo puedo forzar o solicitar las reclamaciones básicas de AD FS nuevamente?

He creado una llamada a AD FS con ActAs, ahora devuelve mis reclamos de identificación. Recuerde habilitar una regla de Delegación permitida para las credenciales utilizadas para llamar a 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;
  }