Häufig gestellte Fragen

Häufig gestellte Fragen

ActAs und OnBehalfOf

F: Was ist der Unterschied zwischen ActAs und OnBehalfOf?

Vom WS-Trust-Protokoll aus gesehen,

• gibt ein ActAs RST-Element an, dass vom Requestor ein Token angefordert wird, das Ansprüche über zwei unterschiedliche Entitäten enthält: den Requestor und eine externe Entität, die im ActAs-Element vom Token dargestellt wird.

• Ein OnBehalfOf RST-Element gibt an, dass vom Requestor ein Token angefordert wird, das nur Ansprüchen über eine Entität enthält: die externe Entität, die vom Token im OnBehalfOf-Element dargestellt wird.

Die ActAs-Funktion wird normalerweise in Szenarien verwendet, die eine zusammengesetzte Delegation erfordern und in denen der letzte Empfänger des ausgestellten Tokens die ganze Delegationskette und nicht nur den Client, sondern sämtliche Vermittler überprüfen kann. Die Zugriffssteuerung, Überwachung und andere verwandte Aktivitäten können daher auf der Grundlage der gesamten Identitätsdelegationskette ausgeführt werden. Die ActAs-Funktion wird häufig in Systemen mit mehreren Ebenen verwendet, um Informationen über Identitäten zwischen den Ebenen zu authentifizieren, ohne diese Informationen auf der Anwendungs-/Geschäftslogikebene übergeben zu müssen.

Die OnBehalfOf-Funktion wird in Szenarien verwendet, in denen nur die Identität des ursprünglichen Clients wichtig und effektiv die gleiche wie die Identität der in Windows verfügbaren Identitätswechselfunktion ist. Wenn "OnBehalfOf" verwendet wird, kann der letzte Empfänger des ausgestellten Tokens nur Ansprüche über den ursprünglichen Client anzeigen, und die Informationen über die Vermittler werden nicht beibehalten. Ein Muster, in dem die OnBehalfOf-Funktion häufig verwendet wird, ist ein Proxymuster, in dem der Client nicht direkt sondern über einen Proxygateway auf den STS zugreift. Das Proxygateway authentifiziert den Aufrufer und legt die Informationen über den Aufrufer im OnBehalfOf-Element der RST-Meldung ab, die diese dann zur Verarbeitung an den eigentlichen STS sendet. Das resultierende Token enthält nur Ansprüche im Zusammenhang mit dem Client des Proxys und macht den Proxy für den Empfänger des ausgestellten Tokens vollständig transparent.

Beachten Sie, dass <wsse:SecurityTokenReference> oder <wsa:EndpointReferences> als untergeordnete Elemente von <wst:OnBehalfOf> von WIF nicht unterstützt werden. Mit der WS-Trust-Spezifikation kann die Identität des ursprünglichen Requestors (der durch den Proxy vertreten wird) auf die folgenden drei Arten festgestellt werden:

1. Verweis auf ein Sicherheitstoken: Ein Verweis auf ein Token, das entweder in der Meldung oder über einen zweiten Kanal abgerufen werden kann.

2. Verweis auf einen Endpunkt: Dieser wird als Schlüssel zum Suchen nach Daten verwendet, die ebenfalls über einen zweiten Kanal abgerufen werden.

3. Sicherheitstoken: Identifiziert den ursprünglichen Requestor direkt.

WIF unterstützt nur verschlüsselte bzw. unverschlüsselte Sicherheitstoken, die direkt untergeordnete Elemente von <wst:OnBehalfOf> sind.

Größenbeschränkung von IIS-Anforderungen

F: Warum erhalte ich beim Verwenden von Cardspace oder dem WS-Verbund die Fehlermeldung "400 Ungültige Anforderung – Anforderung zu groß"?

A: Lesen Sie die Informationen unter Http.sys-Registrierungseinstellungen für IIS. In diesem Artikel werden IIS-Einstellungen beschrieben. Die beiden relevanten Einstellungen sind:

• MaxFieldLength: Legt eine Obergrenze für jeden Header fest. Für eine URL liegt diese Grenze bei etwa 32k Zeichen.

• MaxRequestBytes: Bestimmt die Obergrenze für die Gesamtgröße der Anforderungszeile und der Header. Die Standardeinstellung ist 16 KB. Wenn dieser Wert niedriger als MaxFieldLength ist, wird der MaxFieldLength-Wert angepasst.

Anspruchsauthentifizierungs-Manager

F: Wann wird der Anspruchsauthentifizierungs-Manager aufgerufen?

A: Der Anspruchsauthentifizierungs-Manager wird in der Regel einmal pro Sitzung aufgerufen, mit den folgenden Ausnahmen:

• Um die Transportsicherheit zu gewährleisten, rufen die auf der Transportschicht vorhandenen Token die Anspruchsauthentifizierung einmal pro Aufruf ab, auch wenn Sitzungen vorhanden sind.

• Wenn mehrere Token auf der Nachrichtensicherheitsschicht vorhanden sind, ruft jedes Token den Anspruchsauthentifizierungs-Manager getrennt auf. Zwei Token im Sicherheitsheader rufen den Anspruchsauthentifizierungs-Manager beispielsweise zweimal pro Sitzung auf.

• Der Anspruchsauthentifizierungs-Manager wird nicht aufgerufen, wenn keine Token vorhanden sind, d. h. für alle AnonymousForxxx-Authentifizierungsmodi. In diesem Fall wird empfohlen, den Anspruchsautorisierungs-Manager als Gatekeeper zu verwenden.

class CustomClaimsAuthenticationManager : ClaimsAuthenticationManager { public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal) { return base.Authenticate(resourceName, incomingPrincipal); } }

Doppelte RSTs und doppelte RST-Elemente

F: Wie werden doppelte RSTs und doppelte Elemente innerhalb der RSTs von WIF behandelt?

A: Wird ein RST dupliziert, wird nur das erste RST analysiert und alle anderen werden ignoriert. Wenn ein RST doppelte Elemente enthält, wird nur der Wert des letzten Elements verwendet, und alle anderen Elementwerte werden ignoriert.

SID "Nur Verweigern"

F: Was bedeutet der SID (Security Identifier) "Nur verweigern"?

A: Weitere Informationen finden Sie unter SID Attributes in an Access Token.

IssuerNameRegistry

F: Wie überprüft eine Anwendung der vertrauenden Seite die Vertrauensbeziehung mit einem Aussteller?

A: Bei IssuerNameRegistry in WIF handelt es sich um einen Erweiterungspunkt zum Überprüfen der Vertrauensstellung zu einem Aussteller. Es gibt zwei Methoden, wie dieser Erweiterungspunkt verwendet werden kann:

1. Mit ConfigurationBasedIssuerNameRegistry können Sie das Signaturzertifikat des Ausstellers in der Konfigurationsdatei der Anwendung der vertrauenden Seite konfigurieren.

2. Eine benutzerdefinierte IssuerNameRegistry, die von der in WIF verfügbar gemachten IssuerNameRegistry-Klasse abgeleitet werden kann. In der Datei "Samples\End-to-end\Authentication Assurance\AuthAssuranceRP\App_Code\TrustedIssuerNameRegistry.cs" finden Sie eine Beispielimplementierung einer benutzerdefinierten IssuerNameRegistry.

Installation

F: Unter welchem Registrierungsschlüssel ist WIF installiert?

A: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsIdentityFoundation\setup\v3.5\.

Rufen Sie SecurityTokenService.Issue nicht über mehrere Tokenanforderungen auf

F: Kann eine STS-Instanz verwendet werden, um Issue über mehreren Tokenanforderungen aufzurufen?

A: Das WIF STS-Instanzmodell ist ein "pro Aufruf"-Modell, d. h., dass eine STS-Instanz nur für eine einzige Verwendung vorgesehen ist: Sie erstellen eine neue Instanz eines STS, führen die notwendigen Methodenaufrufe aus (wie z. B. Issue) und löschen anschließend diese STS-Instanz. Wenn Sie versuchen, Issue mit der gleichen STS-Instanz über mehrere Tokenanforderungen aufzurufen, anstatt für jede Tokenanforderung eine neue STS-Instanz zu erstellen, ist das Verhalten undefiniert.