Überlegungen zum Entwurf

In diesem Thema werden Überlegungen zum Entwurf erläutert.

• Best Practices für ClaimsPrincipal.IsInRole

• Anmeldefehler aufgrund von Groß-/Kleinschreibung

• Bestimmte Konfigurationseinstellungen werden ignoriert

• Kompatibilität mit IssuedTokenAuthentication.KnownCertificates

• Konfigurieren der virtuellen Verzeichnisse des WCF-Diensts, um anonymen Zugriff zuzulassen

• ConfigureServiceHost

• Cookiemodus-SSPI-Authentifizierung wird nicht unterstützt

• FederatedPassiveSignIn.AutoSignIn-Umleitung

• Handhabung von wtrealm und wreply

• Verwenden von SAML 2-Token

• IPrincipal und IClaimsPrincipal

• Ausnahme "Kontingent überschritten" beim Verwenden von SAML2-Token, die ActAs-Ansprüche enthalten

• Sichere Konversationen

• Ausstellername des Sicherheitstokendiensts

• Ablaufzeitpunkt des SessionSecurityToken

• Einige Ansprüche und ClaimsIdentity-Eigenschaften werden nicht serialisiert

• SPNego-Authentifizierungsmodus

• Fehler bei der SSL-Zertifikatüberprüfung

• Threadsicherheit bei der Reserialisierung von Bootstraptoken

• Kompatibilität mit WCF-Authentifizierungsflags

• WS-Trust-Verben

Konfigurieren der virtuellen Verzeichnisse des WCF-Diensts, um anonymen Zugriff zuzulassen

Wenn Sie WIF auf einem WCF-Dienst aktivieren, wird von WSTrustServiceHost die automatische MEX-Endpunktveröffentlichung für den Dienst aktiviert. Daher müssen Sie das virtuelle Verzeichnis des Diensts konfigurieren, um anonymen Zugriff zuzulassen. WSTrustServiceHost ist in der Regel einem STS zugeordnet, dem Dienst können möglicherweise jedoch auch Nicht-STS-Endpunkte hinzugefügt werden. WIF aktiviert MEX nicht für Nicht-STS-Dienste. Sie können anonymen MEX deaktivieren, indem Sie DisableWsdl auf true festlegen. Dies empfiehlt sich in Produktionsumgebungen, um bestimmten MEX-Angriffen entgegenzuwirken. Beachten Sie auch, dass WIF MEX auf den gleichen Basisadressen aktiviert, die beim WSTrustServiceHost registriert sind. Daher wird anonymer MEX nur aktiviert, wenn ein Endpunkt beim HTTP-Protokoll registriert wird, und MEX über HTTPS ist nur verfügbar, wenn ein Endpunkt beim HTTPS-Protokoll registriert wird.

Einige Ansprüche und ClaimsIdentity-Eigenschaften werden nicht serialisiert

Die folgenden Eigenschaften sind für die Verwendung durch die vertrauende Seite gedacht, deshalb werden sie nicht im Netzwerk ausserialisiert. Zudem hat ihre Festlegung während der Tokenausstellung keine Auswirkungen:

• Claim.Issuer. Die Issuer-Eigenschaft wird nach dem Empfang des Rückgabewerts von IssuerNameRegistry für X509-und SAML-Token aufgefüllt.

• Claim.Properties. Die Properties-Eigenschaft wird standardmäßig ignoriert und nicht im Netzwerk ausserialisiert.

• ClaimsIdentity.Label. Die Label-Eigenschaft soll nach dem Empfang von der Richtlinie der vertrauenden Seite aufgefüllt werden.

• ClaimsIdentity.NameClaimType. Die NameClaimType-Eigenschaft wird auf der empfangenden Seite verwendet, um auszuwählen, welcher Anspruchswert für IIdentity.Name verwendet wird.

• ClaimsIdentity.RoleClaimType. Die RoleClaimType-Eigenschaft wird auf der empfangenden Seite verwendet, um auszuwählen, welcher Anspruchswert bei der Ausstellung eines Tokens für IsInRole() verwendet wird.

• ClaimsIdentity.AuthenticationType. Die AuthenticationType-Eigenschaft wird auf der empfangenden Seite festgelegt, wenn ein Tokenhandler ein Token überprüft, und sie gibt an, wie das Token überprüft wurde.

Threadsicherheit bei der Reserialisierung von Bootstraptoken

Beim Reserialisieren von SAML-Bootstraptoken (z. B. in einem ActAs-Szenario) mit mehreren Threads müssen Sie die Aufrufe synchronisieren. Andernfalls werden die Token möglicherweise beschädigt. Weitere Informationen zu ActAs finden Sie unter Identitätsdelegationsszenario und Häufig gestellte Fragen.

ConfigureServiceHost

ConfigureServiceHost konfiguriert eine vertrauende Seite von Windows Communication Foundation (WCF) mit Windows® Identity Foundation (WIF). Verwenden Sie die Überladungen dieser Methode, um Konfigurationsdetails anzugeben.

Sichere Konversationen

Wenn Sie keine sicheren Konversationssitzungen zwischen dem Tokenanforderer und dem STS festlegen möchten, müssen Sie die Funktion für sichere Konversation deaktivieren. Im Gegensatz zu WsHttpBinding können Sie bei der WSFederationHttpBinding-Klasse die sicheren Konversationen nicht deaktivieren. Stattdessen müssen Sie eine benutzerdefinierte Bindung erstellen, die die sicheren Sitzungseinstellungen durch einen Bootstrap ersetzt. Ein Beispiel hierfür finden Sie in der Datei "app.config" des Clients im Beispiel "Webdienst/ClaimsAwareWebService" aus dem Beispielverzeichnis. Im folgenden Beispiel wird die relevante Konfiguration veranschaulicht.

      <customBinding> <binding name="MyCustomBinding"> <security authenticationMode="IssuedTokenForCertificate"> </security> <!-- Andere Bindungselemente wie httpTransport werden hier platziert --> </binding> </customBinding>

Der Kernpunkt besteht darin, den SecureConversation-Authentifizierungsmodus nicht zu verwenden. Weitere Informationen zur Ausführung dieser Konfiguration in Code finden Sie unter Vorgehensweise: Deaktivieren von sicheren Konversationen bei einer WsFederationHttpBinding.

Best Practices für ClaimsPrincipal.IsInRole

Diese Überlegung bezieht sich auf ein Szenario, in dem Sie mehrere Anspruchstypen konfiguriert haben und IsInRole zum Festlegen der Zugriffsteuerung verwenden möchten. Es wird empfohlen, nicht mehrere Rollenanspruchstypen mit den gleichen Anspruchswerten zu verwenden. Stattdessen sollten Sie nur einen Rollenanspruchstyp verwenden.

Nehmen Sie beispielsweise an, Sie haben mehrere Rollenanspruchstypen konfiguriert: http://.../Role und http://.../Group. Das eingehende Token enthält Group:Editor. Wenn die Anwendung IsInRole(“Editor”) aufruft, wird true zurückgegeben, da das Token Group:Editor enthält. Wenn Sie jedoch möchten, dass Ihre Anwendung nur Zugriff gewährt, wenn das Token Role:Editor enthält (wenn also Group:Editor nicht ausreichend sein soll), wird dies von WIF nicht unterstützt.

Wahlweise können Sie das Anspruchsmodell direkt verwenden und nicht IsInRole verwenden.

SPNego-Authentifizierungsmodus

SPNego ist der Standardauthentifizierungsmodus für WsHttpBinding. SPNego wird unterstützt, wenn RequireCancellationtrue oder false ist. Es wird nicht jedoch unterstützt, wenn RequireCancellation auf false festgelegt ist, da dies auf einen Cookiemodus auf der Aushandlungsebene hinweist. Das Festlegen von RequireCancellation auf true weist auf einen Sitzungsmodus auf der Aushandlungsebene hin, der unterstützt wird. Beachten Sie außerdem, dass ClaimsAuthenticationManager im SSPI-Fall nicht aufgerufen wird.

https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod- und https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant-Ansprüche werden für SPNego nicht generiert.

Außerdem werden Bootstraptoken für SPNego nicht unterstützt. In diesem Fall ist die Bootstraptoken-Sammlung leer.

Cookiemodus-SSPI-Authentifizierung wird nicht unterstützt

Cookiemodus SSPI-Authentifizierung wird nicht unterstützt Es gibt zwei Möglichkeiten, nicht unterstützte Bindungen abzurufen, die SSPI-Authentifizierung ausführen können:

1. Wandeln Sie eine WSHttpBinding in eine benutzerdefinierte Bindung um, und legen Sie RequireCancellation auf false fest.

2. Rufen Sie SymmetricSecurityBindingElement.CreateSspiNegotiationBindingElement auf.

Ausnahme "Kontingent überschritten" beim Verwenden von SAML2-Token, die ActAs-Ansprüche enthalten

Wenn Sie versuchen, SAML 2-Token zu verwenden, die ActAs-Ansprüche enthalten, erhalten Sie möglicherweise die Ausnahme "Kontingent überschritten". Das liegt daran, dass der ActAs-Anspruch möglicherweise bewirkt, dass das SAML 2-Token die von Windows Communication Foundation (WCF) auferlegte Standardtokengröße von 8K überschreitet. Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?LinkId=150815

Verwenden von SAML 2-Token

Für eine RP-Anwendung, die ASP.NET verwendet, müssen Sie den Standardtokentyp des STS auf SAML2 festlegen oder die STS-Richtlinie ändern, um den RST TokenType ordnungsgemäß auf SAML2 pro Anforderung festzulegen. Im folgenden Codebeispiel ist dies dargestellt:

// // Bei der Verwendung von WS2007FederationHttpBinding // WS2007FederationHttpBinding binding = new WS2007FederationHttpBinding(); binding.Security.Message.IssuedTokenType = Saml2SecurityTokenHandler.TokenProfile11TokenType;

Für eine RP-Anwendung, die ASP.NET verwendet, müssen Sie den Standardtokentyp des STS auf SAML2 festlegen. In der RP-Anwendung müssen keine Festlegungen vorgenommen werden. Die Anwendung akzeptiert alle Token, die sie verarbeiten kann. Im folgenden Codebeispiel ist dies dargestellt:

// Im SecurityTokenServiceConfiguration-Konstruktor kann Folgendes hinzugefügt werden: this.DefaultTokenType = Saml2SecurityTokenHandler.TokenProfile11TokenType;

Ausstellername des Sicherheitstokendiensts

Beachten Sie, dass der STS-Ausstellername immer auf einen gültigen und absoluten, nicht auf einen relativen URI festgelegt werden sollte:

SecurityTokenServiceConfiguration stsConfig = new SecurityTokenServiceConfiguration(“https://localhost:8081/STS”); SecurityTokenService sts = new SecurityTokenService(stsConfig);

Das hat folgenden Grund: Wenn ein STS eine verwaltete Karte ausstellt und der STS nicht für die Verwendung einer gültigen URL als Ausstellername konfiguriert wurde, kann die Karte von CardSpace nicht importiert werden.

Anmeldefehler aufgrund von Groß-/Kleinschreibung

So reproduzieren Sie den Anmeldefehler, wenn der Cookiepfad aufgrund der Groß-/Kleinschreibung nicht mit der URL der letzten Umleitung übereinstimmt:

1. Richten Sie eine passive ASP.NET-Verbundanwendung der vertrauenden Seite (relying party, RP) ein, deren virtuelles Verzeichnis Großbuchstaben einschließt, z. B. "MyRP".

2. Versuchen Sie, mit einer URL, in der das virtuelle Verzeichnis in Kleinbuchstaben geschrieben wird (z. B. "myrp"), auf die RP zuzugreifen. Beispielsweise können Sie einen STS-Anbieter (Sicherheitstokendienst, Security Token Service) so programmieren oder konfigurieren, dass ein Token für die RP mit einer derartigen URL bereitgestellt wird.

3. Die Clientanmeldung schlägt fehl.

Dies tritt auf, da das auf dem Client geschriebene Cookie vom Browser des Clients nicht an die Webanwendung zurückgesendet wird, da das PATH-Attribut des Cookies in der Groß-/Kleinschreibung nicht mit der angeforderten URL übereinstimmt. Das bedeutet, das PATH-Attribut verweist auf das virtuelle Verzeichnis als "MyRP", wohingegen die angeforderte URL "myrp" ist. Das PATH-Attribut wird mithilfe von AppDomainAppVirtualPath direkt aus dem Namen des virtuellen Verzeichnisses entnommen. Da der Clientbrowser beim Abgleichen der Cookiepfade die Groß-/Kleinschreibung beachtet, wird das Verbundcookie nach der nachfolgenden Umleitung nie zurückgesendet.

Um dieses Problem zu vermeiden, stellen Sie sicher, dass die URL auf den Webanwendungsinhalt mit der richtigen Groß-/Kleinschreibung verweist, wenn Sie auf die RP zugreifen möchten.

Fehler bei der SSL-Zertifikatüberprüfung

So reproduzieren Sie das Fehlschlagen der SSL-Zertifikatüberprüfung, wenn WinHTTP nicht mit Proxykonfigurationsproblem bereitgestellt wird:

1. Richten Sie eine Anwendung ein, die eine Verbindung mit einem Webdienst herstellt, der SSL verwendet. Die Anwendung soll als Netzwerkdienst oder lokales System ausgeführt werden. Konfigurieren Sie die Anwendung so, dass sie einen Proxyserver in der Datei "app.config" verwendet, um eine Verbindung herzustellen.

2. Die Anwendung löst folgende Ausnahme aus:

   WebException: System.Net.WebException: Webdienstverbindung konnte nicht hergestellt werden: Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden. ---> System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden. ---> System.Security.Authentication.AuthenticationException: Das Remotezertifikat ist laut Validierungsverfahren ungültig.
   

Dies tritt auf, da die Anwendung .NET mit der Proxykonfiguration in der Datei "app.config" bereitstellt, WinHTTP jedoch nicht über die Proxykonfiguration informiert wird. Aus diesem Grund schlagen die Anforderungen für AIA/Zwischenzertifizierungsstellen während der Zertifikatkettenüberprüfung fehl.

Um dieses Problem zu vermeiden, verwenden Sie entweder "proxycfg.exe" oder die WinHttpSetDefaultProxyConfiguration-Funktion, um den WinHTTP-Proxy für die Übereinstimmung mit der Datei "app.config" der Anwendung zu konfigurieren.

WS-Trust-Verben

Standardmäßig unterstützt ein STS, der mit WIF erstellt wurde, nur das "issue"-Verb. Er stellt nicht die Verben "renew", "cancel" oder "validate" bereit, wie es bei WSDL-Vorgängen der Fall ist. Sie können dieses Verhalten anpassen, indem Sie IsOperationSupported überschreiben.

FederatedPassiveSignIn.AutoSignIn-Umleitung

Wenn Sie AutoSignIn für das FederatedPassiveSignIn-Steuerelement auf "true" festlegen, stellen Sie sicher, dass Sie DestinationPageUrl auf eine andere URL als die Anmeldeseite festgelegt haben. Andernfalls gerät der Browser in eine unendliche Umleitungsschleife, wenn ein Benutzer erfolgreich für einen STS authentifiziert wird. Das hat folgenden Grund: Wenn der Benutzer auf die gleiche Seite umgeleitet wird, die ihn ursprünglich an den STS gesendet hat, erkennt das Steuerelement, dass die aktuelle Anforderung kein Postback ist und kein Token enthält. Daher sendet es den Benutzer erneut an den STS.

IPrincipal und IClaimsPrincipal

Wenn eine Anwendung eine Dienstanforderung empfängt, stehen dieser zwei Methoden zur Verfügung, um den Aufrufer zu ermitteln. Die erste Methode ist die Verwendung der IPrincipal-Klasse und der IIdentity-Klasse. Dieser Ansatz wird sowohl von ASP.NET als auch von WCF unterstützt und WIF ist auf beiden Plattformen vollständig in dieses Modell integriert. So kann der vorhandene Code mit dem neuen, anspruchsbasierten Identitätsmodell und Authentifizierungsmodi verwendet werden. WIF kann Werte für einen bestimmten Anspruchstyp als .NET Framework-Identitätsrollen verfügbar machen, damit IsInRole für die Autorisierung in diesem Anwendungscode verwendet werden kann. Der Anwendungscode oder der Administrator kann einen Anspruchstyp-URI auswählen, und das .NET-Identitätsmodell macht alle Werte als Rollen verfügbar, die diesem im Prinzipal des Aufrufers angezeigten Anspruchstyp zugeordnet sind.

Der zweite Ansatz besteht darin, die IClaimsPrincipal-Klasse zu verwenden, die von WIF bereitgestellt wird. Im Gegensatz zum .NET-Identitätsmodell macht diese Klasse die von WIF bereitgestellten Ansprüche direkt verfügbar. Dadurch werden alle verfügbaren Informationen über den Aufrufer bereitgestellt. Wenn Sie WIF aktiviert haben, sollten Sie IClaimsPrincipal verwenden. Hinweis: Wenn WIF in WCF aktiviert wird, kann der WCF ServiceSecurityContext nicht zum Abrufen der Identität und der Ansprüche des Aufrufers verwendet werden. Der Anwendungscode muss den IClaimsPrincipal verwenden, um auf die Aufruferinformationen zugreifen zu können. Sie können die IClaimsPrincipal-Instanz mithilfe von Thread.CurrentPrincipal abrufen. Dieser ist für jeden Authentifizierungstyp verfügbar, sobald WIF für die Anwendung WCF aktiviert wird.

Ablaufzeitpunkt des SessionSecurityToken

Wenn der Benutzer sich entscheidet, für seine RP-Anwendung Cookies auszugeben, wird die Lebensdauer des entsprechenden SessionSecurityToken auf die gleiche Länge festgelegt wie die Eigenschaft SessionSecurityTokenHandler im DefaultTokenLifetime. Um die Gültigkeitsdauer des Tokens zu ändern, sollten Sie ein benutzerdefiniertes SessionSecurityTokenHandler einbinden. WIF unterstützt das Festlegen der Lebensdauer eines SessionSecurityToken über "web.config" oder "app.config" nicht.

Kompatibilität mit WCF-Authentifizierungsflags

Kunden, die von den im Folgenden aufgeführten WCF-Authentifizierungsflags abhängig sind, werden feststellen, dass diese Flags keine Auswirkungen mehr haben. Dies zeigt sich in Form von Unterbrechungsszenarien, da WIF strengere Überprüfungen auf Tokenhandlerebene erzwingt, oder in Form von Verhaltensänderungen, wenn die Einstellung für den Überprüfungsmodus nicht berücksichtigt wird. Im Folgenden sind einige der Flags aufgeführt, die in WIF nicht unterstützt werden oder ersetzt wurden:

1. ServiceHost.Credentials.IssuedTokenAuthentication

2. ServiceHost.Credentials.ClientCertificate.Authentication

3. ServiceHost.Credentials.UserNameAuthentication

Kompatibilität mit IssuedTokenAuthentication.KnownCertificates

Wenn in WIF-aktivierten WCF-Webdiensten IssuedTokenAuthentication.KnownCertificates nicht festgelegt ist, wird das Framework standardmäßig auf den SimpleIssuerTokenResolver festgelegt, der alle Rohdaten-SKIs auflöst, die über das Netzwerk gesendet werden und bei anderen SKI-Typen fehlschlagen, z. B. IssuerSerial. Wenn IssuedTokenAuthentication.KnownCertificates festgelegt ist, erstellt das Framework standardmäßig eine Tokenauflösung aus dem KnownCertificates-Satz. Diese Auflösung funktioniert jedoch nicht bei Rohdaten-SKIs, die nicht im KnownCertificates-Satz sind. Dies ist das aktuelle Verhalten seit dieser Betaversion.

Handhabung von wtrealm und wreply

Eine an einen STS gesendete Anmeldeanforderungsmeldung muss entweder einen wtrealm-Parameter oder einen wreply-Parameter enthalten. Der wtrealm-Parameter sollte für Richtlinienentscheidungen verwendet werden. Vor der Verwendung des wreply-Parameters als Umleitungs-URL sollte unbedingt anhand der Richtlinie überprüft werden, ob dessen Wert vertrauenswürdig ist.

Bestimmte Konfigurationseinstellungen werden ignoriert

Im <tokenhandlerconfiguration>-Element werden Konfigurationseinstellungen auf <certificateValidation>-Ebene ignoriert, wohingegen jene auf <certificateValidator>-Ebene berücksichtigt werden. Dies wird im folgenden Konfigurationsbeispiel dargestellt:

<tokenHandlerConfiguration> <! – Folgende Einstellungen werden ignoriert --> <certificateValidation mode="ignored" revocationMode="ignored" trustedStoreLocation="ignored"> <! – Die folgenden Einstellungen werden berücksichtigt --> <certificateValidator type="honored" /> </certificateValidation> </tokenHandlerConfiguration>

Wenn sowohl auf den <serviceConfiguration>-Ebenen als auch auf den <securityTokenHandlers>-Ebenen Konfigurationseinstellungen angegeben werden, werden jene auf <securityTokenHandlers>-Ebene berücksichtigt, während die auf <serviceConfiguration>-Ebene ignoriert werden. Dies wird im folgenden Konfigurationsbeispiel dargestellt:

<serviceConfiguration> <issuerNameRegistry type="ignored" /> <serviceTokenResolver type="ignored" /> <audienceUris> ignored </audienceUris> <certificateValidation> ignored </certificateValidation> <issuerTokenResolver type="ignored" /> <securityTokenHandlers> <securityTokenHandlerConfiguration> <issuerNameRegistry type="honored" /> <serviceTokenResolver type="honored" /> <audienceUris> honored </audienceUris> <certificateValidation> honored </certificateValidation> <issuerTokenResolver type="honored" /> <securityTokenHandlerConfiguration> </securityTokenHandlers> </serviceConfiguration>

Festlegen von Eigenschaften in HTTP-Modulen in der Konfiguration, nicht mit Application_Start

In den HTTP-Modulen (ClaimsAuthorizationModule, ClaimsPrincipalHttpModule und SessionAuthenticationModule sowie WSFederationAuthenticationModule) im Application_Start-Ereignishandler sollten keine Einstellungen festgelegt werden. Der Grund hierfür ist, dass der Handler nur einmal aufgerufen wird, jedoch möglicherweise mehrere Instanzen der HTTP-Module erstellt werden, deren Eigenschaften in diesem Fall nicht festgelegt sind. Stattdessen sollten Sie ihre Eigenschaften in der Konfiguration festlegen.