Einfache Ansprüche Transformation für eine RP-STS in Geneva Framework

Question

Nach dem MSDN-Artikel zu lesen ( http://msdn.microsoft .com / en-us / Magazin / 2009.01.genevests.aspx ) auf einem benutzerdefinierten STS Durchführung des Microsoft Geneva Framework ich bin ein bisschen über eines der Szenarien dort bedeckt verwirrt. Dieses Szenario ist in Abbildung 13 des oben erwähnten Artikels dargestellt.

Meine Fragen sind um wie funktioniert der RP den Aufruf an den RP-STS, um auf den bereits erhaltenen Forderungen aus den IP-STS passieren initiieren? Wie wirkt sich die gewünschte Methode DeleteOrder () erhalten in einem Anspruch Antrag auf den Aktions Anspruch von den RP-STS gedreht, die mit einem Wert Löschen mit dem Aktions Anspruch reagiert, die den Anruf berechtigt? Ich denke, auch die Figur, dass etwas falsch ist die Wechselwirkung zwischen den RP-STS und der Policy Engine sollten die Ansprüche haben und in die andere Richtung Pfeile um.

kann ich die Struktur sehen, aber es ist nicht klar, was von Genf / WCF bereitgestellt wird und was in dem RP in Code getan werden muss, was ein wenig seltsam erscheinen würde, da wir nicht die DeleteOrder Methode mit einer Principal Nachfrage schützen könnten für die Delete „Erlaubnis“ würde aber eine Rolle zu fordern hat erhalten zuerst, dann den feinkörnigen Anspruch der Löschaktion nach diesem Punkt.

Wenn ich den Punkt verpasst (da ich diesen Fall nicht leicht auf dem Web abgedeckt finden), dann entschuldige mich!

Vielen Dank im Voraus.

Answer 1

, fragte ich die gleiche Frage auf dem Genfer Forum bei http://social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required und bekam diese Antwort:

Hallo Dokie,

Ich fragte mich, diese gleiche Sache, wenn ich diesen Artikel zu lesen. Als ich überlegte ich, wie ein solches Szenario umgesetzt werden würde, habe ich w / zwei Ideen kommen:

1. Der RP tatsächlich konfigurieren Ansprüche aus den RP-STS zu verlangen; die RP-STS erfordern einen Sicherheitstoken von den IP-STS. Als Ergebnis, wenn das Objekt eine Ressource des RP fordert, es springt ihn an die RP-STS, die ihn an den IP-STS springen. Nachdem es die Authentifizierung wird er an den RP-STS prallen zurück, werden die Identität zentriert Ansprüche in solche umgewandelt notwendig eine Zulassungsentscheidung zu machen und an den RP zurückgegeben.

2. Der RP ist konfiguriert, um eine Interceptor zu haben (zB ein AuthorizationPolicy wenn es ein WCF-Dienst ist), die den Aufruf greift, sieht die Identität zentriert Ansprüche, schafft einen RST (das WSTrustClient verwendet wird), geht es um den RP-STS, dass Service erweitert die Ansprüche in neue Version, die den RP zurückgegeben werden, und der RP macht eine Zulassungsentscheidung.

Ich habe das nie umgesetzt, aber, wenn ich will, würde ich diese beiden Ideen weiter erforschen.

HTH!

---

Grüße,

Travis Spencer

So werde ich versuchen, Option 2 zuerst und sehen, ob das klappt dann hier eine Antwort formulieren.

Answer 2

Ich habe Situation ein adaequat bekam. In meinem Fall AD FS ist der Identitäts-Service und eine benutzerdefinierte STS die Ressource STS.

Alle Verwendung des Webapp die gleiche Ressource STS, aber nachdem ein Benutzer besucht eine andere Anwendung die Identität releated Ansprüche nicht wieder werden Addad durch die FS AD, da der Benutzer bereits authentifiziert ist. Wie kann ich die grundlegenden Forderungen aus der AD FS wieder zwingen, oder fordern Sie?

ich einen Anruf an den AD FS mit ActAs erstellt haben, jetzt gibt es meine Identifizierung Ansprüche. Denken Sie daran, eine Delegation erlaubt Regel für die Anmeldeinformationen zu ermöglichen, verwendet, um den AD FS zu nennen.

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