Verwenden mehrerer verschiedener Vertrauensprotokolle in Verbundszenarien

Unter bestimmten Bedingungen sind Szenarios denkbar, in denen Verbundclients mit einem Dienst und mit einem Security Token Service (STS) kommunizieren, die nicht die gleiche Trust-Version besitzen. Die Dienst-WSDL kann eine RequestSecurityTokenTemplate-Assertion mit WS-Trust-Elementen enthalten, die aus anderen Versionen stammen als der STS. In solchen Fällen konvertiert ein Windows Communication Foundation (WCF)-Client die vom RequestSecurityTokenTemplate empfangenen WS-Trust-Elemente, damit sie mit der STS-Trust-Version übereinstimmen. WCF behandelt nicht übereinstimmende Trust-Versionen nur für Standardbindungen. Alle Standardalgorithmusparameter, die von WCF erkannt werden, sind Teil der Standardbindung. In diesem Thema wird das WCF-Verhalten mit verschiedenen Vertrauenseinstellungen zwischen dem Dienst und dem STS beschrieben.

RP (Feb. 2005) und STS (Feb. 2005)

Die WSDL für die abhängige Seite (Relying Party, RP) enthält im RequestSecurityTokenTemplate-Abschnitt die folgenden Elemente:

  • CanonicalizationAlgorithm

  • EncryptionAlgorithm

  • EncryptWith

  • SignWith

  • KeySize

  • KeyType

Die Clientkonfigurationsdatei enthält eine Liste mit Parametern.

WCF unterscheidet nicht zwischen Client- und Dienstparametern, also werden alle Parameter hinzugefügt und in der RequestSecurityTokenTemplate (RST) versendet.

RP Trust 1.3 und STS Trust 1.3

Die WSDL für RP enthält im RequestSecurityTokenTemplate-Abschnitt die folgenden Elemente:

  • CanonicalizationAlgorithm

  • EncryptionAlgorithm

  • EncryptWith

  • SignWith

  • KeySize

  • KeyType

  • KeyWrapAlgorithm

Die Clientkonfigurationsdatei enthält ein secondaryParameters-Element, das die von der RP angegebenen Parameter umschließt.

WCF entfernt die Elemente EncryptionAlgorithm, CanonicalizationAlgorithm und KeyWrapAlgorithm aus dem Top-Level-Element unter dem RST, wenn diese innerhalb des SecondaryParameters -Elements vorhanden sind. WCF hängt das SecondaryParameters-Element ohne Änderungen an das ausgehende RST an.

RP Trust (Feb. 2005) und STS Trust 1.3

Die WSDL für RP enthält im RequestSecurityTokenTemplate-Abschnitt die folgenden Elemente:

  • CanonicalizationAlgorithm

  • EncryptionAlgorithm

  • EncryptWith

  • SignWith

  • KeySize

  • KeyType

Die Clientkonfigurationsdatei enthält eine Liste mit Parametern.

Anhand der Clientkonfigurationsdatei kann WCF nicht zwischen Dienst- und Clientparametern unterscheiden. Deshalb konvertiert WCF alle Parameter in einen Trust 1.3-Namespace.

WCF behandelt die Elemente KeyType, KeySize und TokenType wie folgt:

  • Laden Sie die WSDL herunter, erstellen Sie die Bindung, und weisen Sie KeyType, KeySize und TokenType auf Basis der RP-Parameter zu. Anschließend wird die Clientkonfigurationsdatei generiert.

  • Der Client kann nun jeden Parameter in der Konfigurationsdatei ändern.

  • Zur Laufzeit kopiert WCF alle angegebenen Parameter in den AdditionalTokenParameters-Abschnitt der Konfigurationsdatei. Hiervon ausgenommen sind KeyType, KeySize und TokenType, da diese Parameter beim Generieren der Konfigurationsdatei berücksichtigt werden.

RP Trust 1.3 und STS Trust (Feb. 2005)

Die WSDL für RP enthält im RequestSecurityTokenTemplate-Abschnitt die folgenden Elemente:

  • CanonicalizationAlgorithm

  • EncryptionAlgorithm

  • EncryptWith

  • SignWith

  • KeySize

  • KeyType

  • KeyWrapAlgorithm

Die Clientkonfigurationsdatei enthält ein secondaryParameters-Element, das die von der RP angegebenen Parameter umschließt.

WCF kopiert alle Parameter, die im SecondaryParameters-Abschnitt angegeben sind, in das RST-Element oberster Ebene, die Parameter werden jedoch nicht in den WS-Trust-Namespace (2005) konvertiert.