Trasformazione di richieste semplici per un RP-STS nel framework di Ginevra

Question

Dopo aver letto l'articolo MSDN ( http://msdn.microsoft .com / it-it / magazine / 2009.01.genevests.aspx ) sull'implementazione di un STS personalizzato utilizzando Microsoft Geneva Framework Sono un po 'perplesso su uno degli scenari trattati. Questo scenario è mostrato nella figura 13 dell'articolo sopra citato.

Le mie domande riguardano il modo in cui l'RP avvia la chiamata all'RP-STS per trasmettere i reclami già ottenuti dall'IP-STS? In che modo il metodo desiderato DeleteOrder () viene trasformato in una richiesta di reclamo per il reclamo di azione dall'RP-STS che risponde al reclamo di azione con un valore Elimina che autorizza la chiamata? Penso anche che la cifra sia leggermente errata in quanto l'interazione tra RP-STS e Policy Engine dovrebbe avere i reclami e le frecce al contrario.

Riesco a vedere la struttura ma non è chiaro cosa sia fornito da Geneva / WCF e cosa debba essere fatto nel codice all'interno del RP, il che sembrerebbe un po 'strano dal momento che non potevamo proteggere il metodo DeleteOrder con una richiesta PrincipalPermission per Elimina " permesso " ma prima dovrebbe richiedere un ruolo, quindi ottenere la rivendicazione fine dell'azione Elimina dopo quel punto.

Se ho perso il punto (dal momento che non riesco a trovare facilmente questo caso coperto sul Web), allora mi scuso!

Grazie in anticipo.

Answer 1

Ho fatto la stessa domanda sul forum di Ginevra a http://social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required e ho ottenuto questa risposta:

Ciao Dokie,

Mi sono chiesto questa stessa cosa quando ho letto quell'articolo. Mentre riflettevo su come sarebbe stato implementato uno scenario del genere, ho avuto due idee:

1. L'RP è effettivamente configurato per richiedere reclami dall'RP-STS; RP-STS richiede un token di sicurezza da IP-STS. Di conseguenza, quando il soggetto richiede una risorsa dell'RP, lo rimbalza sull'RP-STS che lo rimbalza sull'IP-STS. Dopo essersi autenticato lì, viene riportato a RP-STS, le rivendicazioni incentrate sull'identità vengono trasformate in richieste necessarie per prendere una decisione di autorizzazione e restituite a RP.

2. L'RP è configurato per avere un intercettore (ad es. un AuthorizationPolicy se si tratta di un servizio WCF) che prende la chiamata, vede i reclami incentrati sull'identità, crea un RST (usando WSTrustClient), lo passa al RP-STS, quel servizio espande i reclami in nuovi che vengono restituiti al RP e il RP prende una decisione di autorizzazione.

Non l'ho mai implementato, ma, se lo avessi fatto, esplorerei ulteriormente queste due idee.

HTH!

---

Saluti,

Travis Spencer

Quindi proverò prima l'opzione 2 e vedrò se funzionerà, quindi formulo una risposta qui.

Answer 2

La situazione uno funziona bene. Nel mio caso AD FS è il servizio di identità e un STS personalizzato il STS delle risorse.

Tutti i webapp usano lo stesso STS di risorse, ma dopo che un utente visita un'altra applicazione, le rivendicazioni ritirate da Identity non vengono nuovamente aggiunte da ADFS poiché l'utente è già autenticato. Come posso forzare o richiedere nuovamente i reclami di base all'AD FS?

Ho creato una chiamata all'AD FS con ActAs, ora restituisce i miei reclami di identificazione. Ricordarsi di abilitare una regola di delega consentita per le credenziali utilizzate per chiamare ADFS.

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;
  }