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 aus RequestSecurityTokenTemplate empfangenen WS-Trust-Elemente, damit Sie der STS-Trust-Version entsprechen. 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 das EncryptionAlgorithm-Element, das CanonicalizationAlgorithm-Element und das KeyWrapAlgorithm-Element aus dem Element oberster Ebene unter dem RST, sofern 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 das KeyType-Element, das KeySize-Element und das TokenType-Element folgendermaßen:

  • 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 secondaryParamters-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.