Reivindicações simples transformação para um RP-STS em Genebra quadro

Question

Depois de ler o artigo do MSDN ( http://msdn.microsoft .com / en-us / revista / 2009.01.genevests.aspx ) na implementação de um STS personalizado usando o Microsoft Geneva Framework estou um pouco confuso sobre um dos cenários coberto lá. Este cenário é mostrado na figura 13 do artigo acima referenciado.

As minhas perguntas são em torno de como é que o RP iniciar a chamada para o RP-STS, a fim de passar as reivindicações já obtido a partir do IP-STS? Como o DeleteOrder método desejado () se transformou em um Pedido de reivindicação para a afirmação de Ação de RP-STS que responde com a alegação de ação com um valor Apagar que autoriza a chamada? Eu também acho que o valor é ligeiramente incorreto em que a interação entre as RP-STS e o motor de política devem ter as reivindicações e flechas o contrário.

Eu posso ver a estrutura, mas não está claro o que é fornecido pela Genebra / WCF eo que tem de ser feito em código dentro do RP, o que parece um pouco estranho, uma vez que não podia proteger o método DeleteOrder com uma demanda PrincipalPermission para a "permissão" Excluir mas teria que exigem um papel de primeiro e depois obter a alegação de grão fino da ação de exclusão após esse ponto.

Se eu ter perdido o ponto (já que não posso encontrar este caso coberto facilmente na Web), então desculpas!

Agradecemos antecipadamente.

Answer 1

Eu fiz a mesma pergunta sobre o Fórum Genebra http://social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required e obteve a seguinte resposta:

Hi Dokie,

Eu me perguntava a mesma coisa quando eu li esse artigo. Como eu ponderei como tal cenário seria implementado, eu vim acima w / duas ideias:

1. A RP é efectivamente configurado para exigir reivindicações de RP-STS; RP-STS requer um token de segurança do IP-STS. Como resultado, quando o assunto solicita um recurso da RP, ele salta-lhe para as RP-STS que lhe saltar para o IP-STS. Após a autenticação de lá, ele é devolvida aos RP-STS, as declarações de identidade-centric são transformados em que sejam necessárias para tomar uma decisão de autorização e voltou para o RP.

2. A RP é configurado para ter um interceptor (por exemplo, um AuthorizationPolicy se é um serviço WCF) que agarra a chamada, vê as reivindicações de identidade centrada, cria um RST (usando o WSTrustClient), passa para o STS RP-, que o serviço expande as reivindicações em novo que são devolvidos à RP, ea RP faz uma decisão de autorização.

Eu nunca implementou isso, mas, se eu fosse, eu iria explorar essas duas idéias ainda mais.

HTH!

---

Saudações,

Travis Spencer

Então eu vou tentar a opção 2 em primeiro lugar e ver se isso funciona, então, formular uma resposta aqui.

Answer 2

Eu tenho situação um belo trabalho. No meu caso AD FS é o Serviço de Identidade e um costume STS STS recursos.

Todos os do webapp usar o mesmo recurso STS, mas depois de um usuário visita uma outra aplicação da Identidade releated reivindicações não são addad novamente pelos FS AD desde que o usuário já está autenticado. Como posso forçar ou solicitar as reivindicações básicas do AD FS novamente?

Eu criei uma chamada para o AD FS com Actas, agora ele retorna minhas reivindicações de identificação. Lembre-se de habilitar uma regra Delegação permitida para as credenciais usadas para chamar os FS AD.

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