Diese Dokumentation wurde archiviert und wird nicht länger gepflegt.

Versionsanmerkungen

Veröffentlicht: April 2011

Letzte Aktualisierung: Juni 2015

Betrifft: Azure

Dieses Thema beschreibt die neuen Features in den einzelnen Versionen von Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS), die Unterschiede des Produkts zu den Vorgängern sowie alle aktuellen Änderungen, die sich auf Code auswirken können, der für frühere Versionen geschrieben wurde.

ACS hat eine Funktion implementiert, um Inhaber eines ACS-Namespace bei der Migration ihrer Google-Identitätsanbieterkonfigurationen von OpenID 2.0 zu OpenID Connect zu unterstützen. Kunden müssen ihre ACS-Namespaces bis zum 1. Juni 2015 zu OpenID Connect migrieren und bis zum 1. Januar 2017 ihren Back-End-Code migrieren, um OpenID Connect Bezeichner zu verwenden. Werden die erforderlichen Maßnahmen nicht vor Ablauf des Termins durchgeführt, führt dies zu einer Unterbrechung Ihrer Anwendungen. Ausführliche Anweisungen finden Sie unter Migrieren von ACS-Namespaces zu Google OpenID Connect.

Ab dem 19. Mai 2014 können neue ACS-Namespaces Google nicht als Identitätsanbieter verwenden. ACS-Namespaces, die Google verwenden und vor dem 19. Mai 2014 registriert wurden, sind nicht betroffen. Diese neue Einschränkung existiert, weil Google den Support für OpenID 2.0 einstellt und keine neuen Registrierungen mehr akzeptiert. ACS verwendet diese Technologie. Existierende ACS-Namespaces, die Google verwenden, werden bis zum 20. April 2015 funktionieren. Wenn Ihre Anwendung Unterstützung für Google-Konten benötigt, sollten Sie diese direkt bei Google registrieren.

Benutzer, die versuchen, sich mit einem Google-Konto bei einem neuen ACS-Namespace anzumelden, werden auf eine HTTP 400-Fehlerseite weitergeleitet.

Neuer ACS-Namespace und Google-Fehler

ACS hat ein Limit von 30 Tokenanforderungen pro Sekunde pro Namespace eingeführt, um Verfügbarkeit und Leistung von ACS für alle Benutzer zu verbessern. Wenn ein Namespace dieses Limit für längere Zeit überschreitet, lehnt ACS Tokenanforderungen aus dem Namespace für die Dauer des Intervalls ab und gibt den Fehler HTTP 429 / ACS90055 "Too many requests" zurück. Weitere Informationen finden Sie unter ACS-Diensteinschränkungen und ACS-Fehlercodes.

Neue Funktionen

Das Dezember 2012-Update von ACS enthält die folgenden neuen Features:

Unterstützung für einmaliges Verbundabmelden mit dem WS-Verbundprotokoll

Webanwendungen, die ACS für die einmalige Anmeldung (Single Sign-On SSO) bei Identitätsanbietern mit dem WS-Verbundprotokoll verwenden, können nun die Funktionen für einmaliges Abmelden nutzen. Wenn sich ein Benutzer aus einer Webanwendung abmeldet, kann ACS den Benutzer automatisch beim Identitätsanbieter und anderen Anwendungen der vertrauenden Seite abmelden, die denselben Anbieter verwenden.

Dieses Feature unterstützt WS-Verbund-Identitätsanbieter inklusive Active Directory-Verbunddienste 2.0 und Windows Live ID (Microsoft-Konto). Zur Abmeldung führt ACS die folgenden Schritte für Endpunkte des WS-Verbundprotokolls durch:

  • ACS erkennt wsignoutcleanup1.0-Nachrichten von Identitätsanbietern und sendet seinerseits wsignoutcleanup1.0-Nachrichten an Anwendungen der vertrauenden Seite.

  • ACS erkennt wsignout1.0- und wreply-Nachrichten von Anwendungen der vertrauenden Seite und sendet seinerseits wsignout1.0-Nachrichten an Identitätsanbieter und wsignoutcleanup1.0-Nachrichten an Anwendungen der vertrauenden Seite.

Weitere Informationen finden Sie unter Codebeispiel: ASP.NET MVC 4 mit Verbundabmeldung und Passive Authentifizierung für ASP.NET in WIF.

Einstellung der Unterstützung für ACS 1.0

Access Control Service 1.0 wird in dieser Version nicht mehr unterstützt, inklusive der Migrationsunterstützung von Access Control Service 1.0 zu Access Control Service 2.0.

Navigieren zu Namespace für die Zugriffssteuerungs im neuen Azure-Verwaltungsportal

Das neue Azure-Verwaltungsportal (http://manage.WindowsAzure.com) enthält einen neuen Weg zum vertrauten ACS-Verwaltungsportal, in dem Sie Namespace für die Zugriffssteuerungs erstellen und verwalten.

So navigieren Sie zum ACS-Verwaltungsportal:

  1. Navigieren Sie zum Microsoft Azure-Verwaltungsportal (https://manage.WindowsAzure.com), melden Sie sich an, und klicken Sie dann auf Active Directory. (Hinweis für die Fehlerbehebung: Das Element "Active Directory" fehlt oder ist nicht verfügbar)

  2. Klicken Sie auf einen Namespace für die Zugriffssteuerung und klicken Sie auf Verwalten.

Um einen Namespace für die Zugriffssteuerung zu erstellen, klicken Sie auf Neu, auf Anwendungsdienste, auf Zugriffssteuerung und dann auf Schnellerfassung. (Oder klicken Sie auf Namespaces für die Zugriffssteuerung und dann auf Neu.)

Um Hilfe zu ACS-Verwaltungsaufgaben im Microsoft Azure-Verwaltungsportal zu erhalten, klicken Sie auf Active Directory und dann auf Hilfe (?). (Oder klicken Sie auf Active Directory, auf Namespaces für die Zugriffssteuerung und dann auf Hilfe.)

Navigieren zum Namespace für die Zugriffssteuerung für einen Service Bus

Wenn Sie einen Servicebus-Namespace im erstellen, erstellt das Portal automatisch einen Namespace für die Zugriffssteuerung für den Servicebus.

So konfigurieren und verwalten Sie den Namespace für die Zugriffssteuerung für einen Servicebus:

  1. Melden Sie sich beim Azure-Verwaltungsportal an.

  2. Klicken Sie auf Servicebus und wählen Sie einen Servicebus aus.

  3. Klicken Sie auf Zugriffsschlüssel und dann auf ACS-Verwaltungsportal öffnen.

Prüfen Sie anhand des Felds "Dienstnamespace" im oberen Bereich der Seite für den Zugriffssteuerungsdienst, ob der Namespace für die Zugriffssteuerung mit dem Servicebus verbunden ist. Der Name des Namespace besteht aus dem Namen des Servicebus mit der Endung "-sb".

Weitere Informationen finden Sie unter Vorgehensweise: Verwalten des Access Control-Namespaces für einen Service Bus.

Verbesserungen im ACS-Verwaltungsportal für die Anzeige von Schlüsseln von WS-Verbundidentitätsanbietern, Ausblenden von Kennwörtern

Diese Version enthält zwei Verbesserungen für die Anzeige von und die Arbeit mit Zertifikaten, Schlüsseln und Kennwörtern im ACS 2.0-Verwaltungsportal:

  • Signaturzertifikate sind nun im Bereich "WS-Verbundidentitätsanbieter bearbeiten" sichtbar – Bisher waren die aus WS-Verbundmetadaten importierten Zertifikate, die zur Validierung der Signatur von Tokens des entsprechenden Identitätsanbieters verwendet werden, im ACS-Verwaltungsportal nicht sichtbar. Der Bereich "WS-Verbundidentitätsanbieter bearbeiten" enthält nun Informationen über importierte Zertifikate inklusive deren Ablaufdatum und Status. Diese Zertifikate können nun über das Kontrollkästchen "Daten aus WS-Verbundmetadaten beim Speichern erneut importieren" aktualisiert werden.

  • Kennwörter und symmetrische Signierungsschlüssel sind nun standardmäßig ausgeblendet – Diese Werte sind nun in allen Bearbeitungsbildschirmen im Portal standardmäßig ausgeblendet, um die ungewollte Weitergabe von Kennwörtern und symmetrischen Schlüsseln zu verhindern. Benutzer müssen nun auf eine "Kennwort anzeigen"- bzw. "Schlüssel anzeigen"-Schaltfläche klicken, um ein Kennwort bzw. einen symmetrischen Schlüssel anzuzeigen (z. B. um diese in eine Anwendung zu kopieren).

Möglichkeit des Verbunds von Verzeichnismandanten mit Namespace für die Zugriffssteuerungs

Azure Active Directory-Mandanten können nun als Identitätsanbieter in Namespace für die Zugriffssteuerungs verwendet werden. Auf diese Weise kann Ihre Webanwendung z. B. sowohl organisationsinterne Identitäten aus Verzeichnismandanten sowie Verbraucher-Identität aus sozialen Anbietern wie Facebook, Google, Yahoo!, Microsoft-Konten oder anderen OpenID-Anbietern unterstützen. Sie finden detaillierte Anweisungen zur Implementierung dieses Szenarios in diesem Blogeintrag Bereitstellen eines Azure Active Directory-Mandanten als Identitätsanbieter in einem ACS-Namespace.

Unterstützung des SAML 2.0-Protokolls für Anwendungen der vertrauenden Seite (Entwicklervorschau)

ACS unterstützt jetzt das SAML 2.0-Protokoll zum Ausstellen von Tokens für Anwendungen der vertrauenden Seite. Die Unterstützung für das SAML 2.0-Protokoll ist bisher als Entwicklervorschau veröffentlicht, d. h. die genauen Implementierungsdetails für das SAML 2.0-Protokoll werden sich vermutlich noch ändern. Ausführliche Informationen finden Sie unter Entwicklervorschau: SAMLProtocol.

Bekannte Probleme

Das Dezember 2012-Update von Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) enthält die folgenden bekannten Probleme:

Azure-Co-Administratoren können nun Namespace für die Zugriffssteuerungs verwalten. Es ist jedoch eine Aktion erforderlich, bereits vorhandene Co-Administratoren in einem bereits vorhandenen Namespace für die Zugriffssteuerung zu verteilen.

Vor dem November 2012-Update haben wir ein Problem behoben, bei dem standardmäßig nur der erste Azure-Dienstadministrator die in einem Abonnement erstellten Namespace für die Zugriffssteuerungs verwalten konnte. Wenn Azure-Co-Administratoren versucht haben, das ACS-Verwaltungsportal für einen Namespace für die Zugriffssteuerung zu öffnen, erhielten sie einen der folgenden ACS-Fehlercodes:

  • ACS50000: Fehler beim Ausstellen eines Tokens.

  • ACS60000: Fehler beim Verarbeiten der Regeln für die vertrauende Seite mit dem Aussteller ‘uri:WindowsLiveID’

  • ACS60001: Während der Regelverarbeitung wurden keine Ausgabeansprüche generiert.

Dieses Problem ist nun behoben für neue Namespace für die Zugriffssteuerungs, die von einem Azure-Dienstadministrator oder Co-Administrator erstellt werden. Kunden mit Namespaces, die vor der Fehlerkorrektur erstellt wurden, müssen jedoch die folgende Aktion ausführen, um die Co-Administratordaten an diese Namespaces zu übertragen:

  1. Anmelden am Azure-Portal (https://windows.azure.com/) mithilfe der Anmeldeinformationen des Dienstadministrators oder Kontoadministrators.

  2. Entfernen Sie den Co-Administrator und fügen Sie ihn erneut hinzu. Folgen Sie dazu den Anweisungen unter Hinzufügen und Entfernen von Co-Administratoren für Ihre Azure-Abonnements (http://msdn.microsoft.com/en-us/library/windowsazure/gg456328.aspx)

  3. Abmelden und Anmelden am Azure-Portal mithilfe der Anmeldeinformationen des Co-Administrators. Sie können nun die Namespace für die Zugriffssteuerungs verwalten.

Im September 2012 wurde ein Update für Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) mit den folgenden Änderungen veröffentlicht:

Die in den von ACS ausgestellten WS-Verbundmetadaten veröffentlichte Entitäts-ID enthält nun durchgehend Kleinbuchstaben

Das in den von Namespace für die Zugriffssteuerungs ausgestellten WS-Verbundmetadaten veröffentlichte Attribut "entityID" enthält nun durchgehend Kleinbuchstaben. In früheren Versionen wurde die Groß-/Kleinschreibung verwendet, die bei der Erstellung des Namespace im Azure-Portal eingegeben wurde. Das "entityID"-Attribut identifiziert den Namespace für die Zugriffssteuerung gegenüber Anwendungen der vertrauenden Seite. Hier sehen Sie ein Beispiel für dieses Attribut:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Diese Änderung behebt potenzielle Probleme mit der Tokenvalidierung, wenn die Schreibweise des Namespace für die Zugriffssteuerung in dem von ACS ausgestellten Token (immer in Kleinbuchstaben) nicht mit dem von der vertrauenden Seite importierten Namespace für die Zugriffssteuerung übereinstimmt. Vertrauende Seiten, die Windows Identity Foundation verwenden, sind von diesen Groß-/Kleinschreibungsproblemen nicht betroffen.

Der öffentliche Schlüssel der in ACS hochgeladenen X.509-Zertifikate ist nun auf 4096 Bit beschränkt

Der öffentliche Schlüssel aller über das ACS-Verwaltungsportal oder den Verwaltungsdienst in einen Namespace für die Zugriffssteuerung hochgeladenen X.509-Zertifikate ist nun auf maximal 4096 Bit beschränkt. Dies umfasst Zertifikate für die Tokensignierung, Tokenverschlüsselung und Tokenentschlüsselung.

In Windows können Sie die Länge des öffentlichen Schlüssels eines Zertifikats prüfen, indem Sie die Zertifikatsdatei (.CER) öffnen, die Registerkarte "Details" auswählen und den Wert im Feld "Öffentlicher Schlüssel" ablesen. Zertifikate mit dem sha256RSA-Signaturalgorithmus haben einen öffentlichen Schlüssel mit 2048 Bit.

Alle vorhandenen Zertifikate mit einer Schlüssellänge größer als 4096 Bit funktionieren weiterhin mit ACS, können jedoch erst wieder in ACS gespeichert werden, nachdem sie durch ein gültiges Zertifikat ersetzt wurden.

Kleinere Änderungen am Algorithmus für die "Primärschlüssel"-Auswahl, wenn ACS ein Token mit einem X.509-Zertifikat signiert

Im ACS-Verwaltungsportal und im Verwaltungsdienst existiert ein Feld "Als Primärschlüssel verwenden" für Tokensignaturzertifikate, das dazu führt, dass ACS Tokens mit diesem Zertifikat signiert. Ab dieser Version verwendet Namespace für die Zugriffssteuerung das existierende nicht-primäre Tokensignaturzertifikat mit dem frühesten Startdatum für die Tokensignierung, wenn das Feld "Als Primärschlüssel verwenden" für keines der konfigurierten Tokensignaturzertifikate markiert ist. ACS signiert weiterhin keine Tokens mit nicht-primären Tokensignaturzertifikaten, wenn ein primäres Zertifikat existiert, dieses jedoch ungültig oder abgelaufen ist.

JWT Beta: Änderung im Signaturverhalten, wenn ein globales Namespacezertifikat oder ein Schlüssel zum Signieren eines JWT-Tokens vorhanden ist.

Als die Beta-Unterstützung für das JSON Web Token (JWT)-Format im Juni 2012 veröffentlicht wurde, verwendete ACS die folgende Reihenfolge, um zu bestimmen, mit welchem Schlüssel die einzelnen JWT-Token für die jeweiligen Anwendungen der vertrauenden Seite signiert wurden:

  • Symmetrischer Signierungsschlüssel der vertrauenden Seite, falls verfügbar

  • X.509-Signierungszertifikat für die vertrauende Seite, falls verfügbar

  • Symmetrischer Signierungsschlüssel für den Namespace für die Zugriffssteuerung, falls verfügbar

  • X.509-Signierungszertifikat für den Namespace für die Zugriffssteuerung, falls verfügbar

Ab dieser Version werden symmetrische Schlüssel für ganze Namespaces zur Signierung von JWT-Tokens nicht mehr unterstützt. Dies ist die neue Reihenfolge für die Signierung von JWT-Tokens:

  • Symmetrischer Signierungsschlüssel der vertrauenden Seite, falls verfügbar

  • X.509-Signierungszertifikat für die vertrauende Seite, falls verfügbar

  • X.509-Signierungszertifikat für den Namespace für die Zugriffssteuerung, falls verfügbar

Im Juni 2012 wurde ein Update für ACS mit dem folgenden neuen Feature veröffentlicht:

JWT-Format nun für Anwendungen der vertrauenden Seite verfügbar (Beta)

Mit diesem Update wurde die Unterstützung für das JSON Web Token (JWT)-Betaformat in ACS eingeführt. JWT ist ein vereinfachtes, JSON-codiertes Tokenformat, das mit einem X.509-Zertifikat oder einem symmetrischen Schlüssel signiert werden und von ACS für Anwendungen der vertrauenden Seite über die folgenden Protokolle ausgestellt werden kann:

  • OAuth 2.0

  • WS-Verbund

  • WS-Trust

Das JWT-Tokenformat ist nun eine auswählbare Option im Bereich für Anwendungen der vertrauenden Seite im ACS-Verwaltungsportal und kann ebenfalls über den ACS-Verwaltungsdienst ausgewählt werden.

Weitere Informationen zum JWT-Tokenformat finden Sie in der JSON Web Token-Spezifikation. ACS-Codebeispiele für JWT-Tokens werden zu einem zukünftigen Zeitpunkt bereitgestellt.

ImportantWichtig
Die JWT-Unterstützung in ACS ist als "Beta" markiert, d. h. sämtliche Details der JWT-Implementierung können sich jederzeit ändern. Entwickler sind herzlich dazu eingeladen, dieses Tokenformat auszuprobieren. JWT sollte jedoch nicht in Produktionsdiensten verwendet werden, da sich das Verhalten ohne vorherige Ankündigung ändern kann.

Anfang Mai 2012 wurde ein Update für ACS mit der folgenden Änderung veröffentlicht:

Änderungen an der vom Verwaltungsdienst bereitgestellten Entitäts-ID

Der ACS-Verwaltungsdienst stellt momentan eine ID-Eigenschaft für alle unterstützten Entitätstypen bereit, wie in der Referenz zur ACS-Verwaltungsdienst-API beschrieben. Diese ID-Eigenschaften werden automatisch von ACS gesetzt und verwaltet.

In diesem Dienstupdate wird ACS in ein neues Datenbankschema migriert. Aus diesem Grund ändern sich diese vom Verwaltungsdienst bereitgestellten IDs für alle Entitätstypen.

Es ist eher ungewöhnlich und nicht empfehlenswert, dass Anwendung diese IDs speichern oder hartcodierte Abhängigkeiten von diesen IDs verwenden, um bestimmte Entitäten über den Verwaltungsdienst abzurufen. Stattdessen sollten die Entitätstypen "RelyingParty", "ServiceIdentity", "RuleGroup" und "Issuer" über die "Name"-Eigenschaft und andere Entitätstypen über die ID einer übergeordneten Entität abgefragt werden (z. B. "RuleGroupId" für Regeln oder "IssuerId" für Identitätsanbieter).

Änderung der Datenbanksortierung für die Regelverarbeitung

Diese Version von ACS ändert die zugrunde liegende SQL-Datenbanksortierung von SQL_Latin1_General_CP1_CI_AS zu Latin1_General_100_BIN2, um die internationale Sprachunterstützung und die Sicherheit zu verbessern. Dank dieser Änderung kann ACS internationale Zeichensätze und Kombinationen aus internationalen Zeichensätzen unterstützen. In Anwendungen mit Eingabeansprüchen mit mehreren Zeichensätzen, die von SQL_Latin1_General_CP1_CI_AS nicht unterstützt werden, tauchen möglicherweise durch diese neue Sortierung unterschiedliche oder zusätzliche Ansprüche auf. Kunden, die diese neue Funktionalität nutzen möchten, sollten die Kompatibilität ihrer Anwendungen mit der neuen SQL-Sortierung prüfen.

Am 25. Januar 2012 wurde ein Update für ACS 2.0 mit den folgenden Änderungen veröffentlicht:

In der vorherigen Version antwortete ACS mit unterschiedlichen Fehlercodes, wenn sich ein Client mit einem nicht existierenden Aussteller (Fehlercode: ACS50026) oder mit falschen Anmeldeinformationen (Fehlercode: ACS50006) authentifiziert hat. Diese Fehlercodes wurden zuvor ausgegeben, wenn ein Client versucht hat, sich mit einem ungültigen Dienstidentitätsnamen oder einem SWT- bzw. SAML-Token eines ungültigen Identitätsanbieters zu authentifizieren.

ACS gibt die Fehlercodes ACS50008, ACS50009 oder ACS50012 für fehlgeschlagene Authentifizierungsversuche mit SWT, SAML bzw. Benutzername/Kennwort zurück. Genauere Informationen entnehmen Sie der folgenden Tabelle:

 

Authentifizierungsantwort Vorher Danach

Nicht existierender Aussteller

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml, ODER

ACS50012 AuthenticationFailed

Falsche Anmeldeinformationen

ACS50006 InvalidSignature

In der vorherigen Version antwortete ACS ebenfalls mit unterschiedlichen OAuth 2.0-Fehlercodes, wenn sich ein Client mit einem nicht existierenden Aussteller (invalid_client) oder mit falschen Anmeldeinformationen (invalid_grant) authentifiziert hat. Dieses Verhalten wurde ebenfalls aktualisiert. ACS gibt "invalid_request" für fehlerhafte OAuth 2.0-Anfragen zurück, "invalid_client" für fehlgeschlagene Authentifizierungsversuche oder für fehlerhafte bzw. ungültige Assertionen, und "invalid_grant" für fehlerhafte bzw. ungültige Autorisierungscodes. Genauere Informationen entnehmen Sie der folgenden Tabelle:

 

Authentifizierungsantwort Beispiele Vorher Danach

Nicht existierender Aussteller

invalid_client

invalid_client

Falsche Anmeldeinformationen

SWT ist mit einem ungültigen Schlüssel signiert. Client-ID und Anmeldeinformationen stimmen nicht mit den Daten in ACS überein.

invalid_grant

Authentifizierung fehlgeschlagen

Fehler bei der Überprüfung des Zielgruppen-URI. Zertifikatprüfung fehlgeschlagen. Assertion von einer Dienstidentität enthält selbst ausgestellte Ansprüche.

invalid_grant

Fehlerhafte Assertion

Signatur fehlt in SWT. SAML-Assertion ist kein gültiges XML.

invalid_request

Fehlerhafter Autorisierungscode

invalid_grant

invalid_grant

Ungültiger Autorisierungscode

invalid_grant

Fehlerhafte OAuth2-Anforderung

invalid_request

invalid_request

Die Versionshinweise für das Juli 2011-Update von ACS 2.0 enthalten die folgenden Punkte:

Alle Namespace für die Zugriffssteuerungs erhalten das Juli 2011-Update automatisch. Dieses Update enthält keine Änderungen an den ACS-Voraussetzungen für neue oder existierende Kunden. Weitere Informationen zu den aktuellen ACS-Voraussetzungen finden Sie unter ACS-Voraussetzungen.

Das Juli 2011-Update von ACS enthält die folgenden neuen Features:

1. Regeln unterstützen nun bis zu zwei Eingabeansprüche

Das ACS-Regelmodul unterstützt nun einen neuen Regeltyp, mit dem bis zu zwei Eingabeansprüche konfiguriert werden können, anstatt wie bisher nur ein Anspruch. Regeln mit zwei Eingabeansprüchen können verwendet werden, um die Gesamtzahl der benötigten Regeln für komplexe Funktionen zur Benutzerautorisierung zu senken.

Im ACS-Verwaltungsportal können Sie einen zweiten Eingabeanspruch für neue Regeln konfigurieren, indem Sie im Regel-Editor auf Zweiten Eingabeanspruch hinzufügen klicken. Im Verwaltungsdienst können Sie Regeln mit zwei Eingabeansprüchen über den ConditionalRule-Entitätstyp konfigurieren. Regeln mit einem Eingabeanspruch werden aus Gründen der Abwärtskompatibilität weiterhin über den Rule-Entitätstyp konfiguriert.

Weitere Informationen zu Regeln mit zwei Eingabeansprüchen finden Sie unter Regelgruppen und Regeln.

2. Lokalisierung in elf Sprachen

Das ACS-Verwaltungsportal und die in ACS gehostete Anmeldungsseite für Anwendungen der vertrauenden Seite wurde in elf Sprachen lokalisiert, darunter Englisch, Französisch, Deutsch, Italienisch, Japanisch, Koreanisch, Russisch, Spanisch, Portugiesisch (Brasilien), vereinfachtes Chinesisch und traditionelles Chinesisch. Außerdem ist eine Option "Englisch (International)" verfügbar. Diese Option verwendet ein alternatives Datumsformat für die Einstellung und Anzeige von Gültigkeits- und Ablaufdatum für Schlüssel. Sie können die Anzeigesprache für diese Benutzeroberflächen auf die folgenden drei Arten ändern:

  • Sprachauswahl – Im ACS-Verwaltungsportal können Sie die Anzeigesprache sofort ändern, indem Sie die Sprachauswahl in der oberen rechten Ecke des Portals verwenden.

  • URL – Sie können die im ACS-Verwaltungsportal verwendete Anzeigesprache ändern, indem Sie einen "lang"-Parameter an das Ende der Anforderungs-URL anhängen. Dieser Parameter akzeptiert die ISO 639-1/3166-Sprachcodes für die entsprechenden unterstützten Sprachen. Beispielwerte sind: en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn und zh-tw. Hier sehen Sie ein Beispiel für eine URL im ACS-Verwaltungsportal mit einem Parameter, der die Anzeigesprache auf Französisch setzt:

    https://Ihr-Namespace.accesscontrol.windows.net/?lang=fr

  • Webbrowser-Einstellungen – Wenn weder "lang"-URL-Parameter noch Sprachauswahl für die Einstellung einer bevorzugten Sprache verwendet wurden, verwenden das ACS-Verwaltungsportal und die in ACS gehosteten Anmeldeseiten die Webbrowser-Einstellungen für die Auswahl der Standardsprache.

Diese Version enthält die folgenden wichtigen Verhaltensänderungen:

1. Als Codierung wird nun UTF-8 für alle OAuth 2.0-Antworten verwendet

In der ursprünglichen Version von ACS wurde US-ASCII als Zeichencodierung für alle HTTP-Antworten des OAuth 2.0-Endpunkts verwendet. Ab dem Juli 2011-Update wird als Zeichencodierung für alle HTTP-Antworten nun UTF-8 verwendet, um erweiterte Zeichensätze zu unterstützen.

Das folgende Problem ist in dieser Version bekannt:

Der Regel-Editor kann keine benutzerdefinierten Aussteller anzeigen, die keinem Identitätsanbieter zugewiesen sind

Momentan kann der Regel-Editor im ACS-Verwaltungsportal nur Aussteller von Ansprüchen anzeigen, die einem Identitätsanbieter oder ACS zugewiesen sind. Wenn eine Regel geladen wird, die auf einen Aussteller verweist, der keiner dieser Entitäten zugewiesen ist, wird der folgende Fehler angezeigt:

  • ACS80001: Diese Regel ist für die Verwendung eines Anspruchsausstellertyps konfiguriert, der vom Verwaltungsportal nicht unterstützt wird. Verwenden Sie den Verwaltungsdienst, um diese Regel anzuzeigen und zu bearbeiten.

Es existieren zwei unterstützte Szenarien in ACS, in denen Aussteller ohne zugewiesenen Identitätsanbieter existieren können:

  • In einem OAuth 2.0-Delegierungsszenario wird im Namespace für die Zugriffssteuerung mithilfe des ACS-Verwaltungsdiensts ein Ausstellerdatensatz erstellt, und diesem Aussteller ist kein Identitätsanbieter zugeordnet.

  • Wenn ein Aussteller für die Bestätigung von Ansprüchen in Tokenanfragen über das OAuth WRAP-Protokoll erstellt wird und gleichzeitig eine Dienstidentität mit identischem Namen für die Authentifizierung mit ACS verwendet wird.

Ab dieser Version erzwingt ACS keine Obergrenzen für die Anzahl von Identitätsanbietern, Anwendungen der vertrauenden Seite, Regelgruppen, Dienstidentitäten, Anspruchstypen, Delegierungseinträge, Aussteller, Schlüssel und Adressen, die für einen bestimmten Namespace für die Zugriffssteuerung erstellt werden können.

Weitere Informationen zu Diensteinschränkungen finden Sie unter ACS-Diensteinschränkungen.

Anzeigen: