Erstellen eines lokalen Token cache mithilfe der Genf-Framework

Question

Noch nicht viele gesehen, Geneva Fragen noch, ich habe diese Frage in der Genf-Forum wie gut...

Ich arbeite an einem Szenario, in dem wir eine win forms-app mit einem breiten installbase, die Ausstellung häufige Anrufe zu verschiedenen Diensten gehostet werden von uns zentral aus der gesamten it-Betrieb.

Die Dienste sind alle mit dem Genf-Framework und alle Kunden sind erwartet zu rufen Sie unsere STS erste zu sein, erhält einen token für den Zugriff auf die services.

Out of the box, mit der ws2007FederationHttpBinding, kann die app so konfiguriert werden, rufen Sie einen token vom STS vor jedem service-Aufruf, aber offensichtlich ist dies nicht der effizienteste Weg, als wir fast das duplizieren der Aufwand für den Aufruf des services.

Alternativ, die ich umgesetzt haben, ist der code zum abrufen des token "manuell" aus der app, und dann übergeben Sie den gleichen pre-abgerufen token beim aufrufen von Vorgängen auf die Dienste (basierend auf den WSTrustClient Probe und helpon forum);das funktioniert gut, und so haben wir eine Lösung,aber ich believeit ist nicht sehr elegant, da es verlangt, Gebäude der WCF-Kanal in code, bewegen Sie sich von der wunderbaren WCF-Konfiguration.

Ich bevorzuge die ws2007FederationHttpBinding Ansatz, bei dem der client ruft einfach den Dienst wie jeder andere WCF-Dienst, ohne etwas über Genf, und die Bindungen kümmert sich um die token-exchange.

Dann jemand (Jon Simpson) gab mir (was ich denke ist] eine tolle Idee - fügen Sie einen service, gehostet in der app selbst zu cache lokal abgerufen Token.Das lokale cache-Dienst implementieren würden die gleichen Vertrag wie die STS;wenn receiveing einen Wunsch es wäre zu überprüfen, um zu sehen, wenn eine cahced token vorhanden ist, und wenn ja, würde es zurückgeben, sonst würde es nennen, die "echte" STS, ermittelt werden einen neuen token cache und zurückzugeben.Die client-app könnte dann noch mit ws2007FederationHttpBinding, aber anstatt die STS als Emittentin würde es den lokalen cache;

Auf diese Weise denke ich, dass wir erreichen können, das beste aus beiden Welten - das Zwischenspeichern von Token ohne die service-sepcific custom code;unser cache sollte in der Lage sein zu handhaben Token für alle RPs.

Habe ich einen sehr einfachen Prototyp, um zu sehen, ob es funktioniert, und - irgendwie nicht überraschend, leider bin ich etwas stecken, -

Mein lokaler Dienst (derzeit eine Konsolen-app), erhält die Anfrage, und - das erste mal - fordert der STS zum abrufen des token-caches und erfolgreich gibt es an den client, anschließend nutzt Sie zum aufrufen der RP.alles funktioniert gut.

Zweites mal um, aber meine lokalen cahce-Dienst versucht, dasselbe token wieder, aber der client-Seite fehlschlägt, mit dem MessageSecurityException -

"Sicherheit Prozessor war nicht in der Lage zu finden, ein security-header in die Nachricht.Dies könnte sein, weil die Nachricht ist eine ungesicherte Schuld ist, oder weil es eine verbindliche Diskrepanz zwischen den kommunizierenden Parteien.Dies kann auftreten, wenn der Dienst konfiguriert ist, für die Sicherheit und die Kunden ist nicht mit Sicherheit."

Gibt es etwas, das verhindern der gleichen token mehr als einmal verwendet werden?Ich bezweifle es, denn wenn ich wiederverwendet, die token wie pro die WSTrustClient Beispiel funktioniert es gut;was vermisse ich?ist das meine Idee möglich?ein gutes?

Hier ist die (sehr einfachen, in dieser Phase) Haupt-code-bits des lokalen cache -

    static LocalTokenCache.STS.Trust13IssueResponse  cachedResponse = null; 
    public LocalTokenCache.STS.Trust13IssueResponse Trust13Issue(LocalTokenCache.STS.Trust13IssueRequest request) 
    { 
        if (TokenCache.cachedResponse == null) 
        { 
            Console.WriteLine("cached token not found, calling STS"); 
            //create proxy for real STS 
            STS.WSTrust13SyncClient sts = new LocalTokenCache.STS.WSTrust13SyncClient(); 
            //set credentials for sts 
            sts.ClientCredentials.UserName.UserName = "Yossi"; 
            sts.ClientCredentials.UserName.Password = "p@ssw0rd"; 
            //call issue on real sts 
            STS.RequestSecurityTokenResponseCollectionType stsResponse = sts.Trust13Issue(request.RequestSecurityToken); 
            //create result object - this is a container type for the response returned and is what we need to return; 
            TokenCache.cachedResponse = new LocalTokenCache.STS.Trust13IssueResponse(); 
            //assign sts response to return value... 
            TokenCache.cachedResponse.RequestSecurityTokenResponseCollection = stsResponse; 
        } 
        else 
        { 
        } 
        //...and reutn 
        return TokenCache.cachedResponse;

Answer 1

Das ist schon fast peinlich, aber Dank Dominick Baier auf dem forum, die ich nicht erkenne jetzt, die ich verpasst habe eine riesige Punkt (ich wusste, es hat keinen Sinn!ehrlich!:-) ) -

Ein token wird abgerufen, einmal pro service-proxy, vorausgesetzt, es war nicht abgelaufen, und so alles, was ich tun musste, ist zu verwenden Sie den gleichen proxy, was ich plante sowieso, aber ziemlich blöd, nicht auf meinem Prototyp.

Darüber hinaus fand ich ein sehr Interessantes Beispiel in der MSDN WCF-samples - Dauerhaft Ausgestellten Token Provider, die, wenn ich es richtig verstehe, verwendet einen benutzerdefinierten Endpunkt Verhalten auf der Clientseite zu implementieren token Zwischenspeichern, die sehr elegant.

Ich werde noch schauen, diesen Ansatz, da haben wir mehrere services und so konnten wir erreichen, auch mehr Effizienz durch Wiederverwendung des gleichen token zwischen Ihren proxies.

So zwei Lösungen, so ziemlich infornt von meinen Augen;hoffe, dass meine Dummheit hilft jemandem irgendwann!

Answer 2

Ich habe ein vollständiges Beispiel für das Zwischenspeichern der token hier: http://blogs.technet.com/b/meamcs/archive/2011/11/20/caching-sts-security-token-with-an-active-web-client.aspx