Versionshinweise

Aktualisiert: 19. Juni 2015

Gilt für: Azure

In diesem Thema werden die neuen Features in jeder Version von Microsoft Azure Active Directory Access Control (auch als Access Control Service oder ACS bezeichnet) beschrieben, wie sich jede Version des Produkts von den Vorgängern unterscheidet, und hebt alle unterbrechungsweisen Änderungen hervor, die sich auf Code auswirken können, der für eine frühere Version geschrieben wurde.

• März 2015 – Migrieren von ACS-Namespaces zu Google OpenID Connect

• Juni 2014 – Unterstützung für den Google-Identitätsanbieter

• Versionsanmerkungen für das Juli 2013-Update

• Versionsanmerkungen für das Dezember 2012-Update

• Versionsanmerkungen für das September 2012-Update

• Versionsanmerkungen für das Juni 2012-Update

• Versionsanmerkungen für das Mai 2012-Update

• Versionsanmerkungen für das Januar 2012-Update

• Updatenotizen für Juli 2011

März 2015 – Migrieren von ACS-Namespaces zu Google OpenID Connect

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 Anleitungen finden Sie unter Migrieren von ACS-Namespaces zu Google OpenID Verbinden.

Juni 2014 – Unterstützung für den Google-Identitätsanbieter

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. Vorhandene ACS-Namespaces, die Google verwendet haben, funktionieren bis zum 20. April 2015 weiter. Wenn Ihre Anwendung Unterstützung für Google-Konten erfordert, empfehlen wir Ihnen, Ihre Anwendung direkt bei ihnen zu registrieren.

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

Versionsanmerkungen für das Juli 2013-Update

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-Dienstbeschränkungen und ACS-Fehlercodes.

Versionsanmerkungen für das Dezember 2012-Update

Neue Funktionen

Das Update vom Dezember 2012 von ACS umfasst die folgenden neuen Features:

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

Webanwendungen, die ACS verwenden, um einmaliges Anmelden (Single Sign-On, SSO) mit Identitätsanbietern mit dem WS-Federation-Protokoll zu aktivieren, können jetzt die Funktionen für einmaliges Abmelden nutzen. Wenn sich ein Benutzer bei einer Webanwendung abmeldet, kann ACS den Benutzer automatisch vom Identitätsanbieter abmelden und von anderen Anwendungen der vertrauenden Partei, die denselben Identitätsanbieter verwenden.

Dieses Feature ist für WS-Federation Identitätsanbieter aktiviert, einschließlich Active Directory-Verbunddienste (AD FS) 2.0 und Windows Live ID (Microsoft-Konto). Um einmaliges Abmelden zu aktivieren, führt ACS die folgenden Aufgaben für WS-Federation Protokollendpunkte aus:

• ACS erkennt wsignoutcleanup1.0-Nachrichten von Identitätsanbietern und antwortet durch Senden von wsignoutcleanup1.0-Nachrichten an vertrauende Partyanwendungen.

• ACS erkennt wsignout1.0 - und wreply-Nachrichten von Anwendungen von vertrauenden Parteien und antwortet durch Senden von wsignout1.0-Nachrichten an Identitätsanbieter und wsignoutcleanup1.0-Nachrichten an Anwendungen von vertrauenden Parteien.

Weitere Informationen finden Sie im Codebeispiel: ASP.NET MVC 4 mit Partneranmeldung und passiver 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 Access Control Namespaces im neuen Azure-Verwaltungsportal

Das neue Azure Management Portal (https://manage.WindowsAzure.com) enthält eine Route zum vertrauten ACS-Verwaltungsportal, in dem Sie Access Control Namespaces erstellen und verwalten.

So navigieren Sie zum ACS-Verwaltungsportal:

1. Wechseln Sie zum Microsoft Azure Verwaltungsportal (https://manage.WindowsAzure.com), melden Sie sich an, und klicken Sie dann auf Active Directory. (Tipp zur Problembehandlung: Das Element "Active Directory" fehlt oder ist nicht verfügbar)

2. Klicken Sie auf einen Access Control Namespace, und klicken Sie dann 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 Access Control Namespace für einen Dienstbus

Wenn Sie im Portal einen Service Bus Namespace erstellen, erstellt das Portal automatisch einen Access Control Namespace für den Dienstbus.

So konfigurieren und verwalten Sie den Access Control Namespace für einen Dienstbus:

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.

Um zu überprüfen, ob der Access Control Namespace dem Dienstbus zugeordnet ist, lesen Sie das Feld "Dienstnamespace" oben auf der Seite "Access Control Dienst". Der Name des Namespace besteht aus dem Namen des Servicebus mit der Endung "-sb".

Weitere Informationen finden Sie unter How to: Manage the Access Control Namespace for a 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 zum Partnerspeichern von Verzeichnismandanten mit Access Control Namespaces

Azure Active Directory Mandanten können jetzt als Identitätsanbieter in Access Control Namespaces verwendet werden. Dies ermöglicht viele Szenarien, z. B. die Aktivierung Ihrer Webanwendung, sowohl Organisationsidentitäten von Verzeichnismandanten als auch Verbraucheridentitäten von sozialen Anbietern wie Facebook, Google, Yahoo!, Microsoft-Konten oder einem anderen OpenID-Anbieter. Ausführliche Anweisungen zum Implementieren des Szenarios finden Sie in diesem Beitrag, das 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. Weitere Details finden Sie unterDeveloper Preview: SAMLProtocol.

Bekannte Probleme

Im Dezember 2012 wurden Microsoft Azure Active Directory Access Control (auch als Access Control Service oder ACS bezeichnet) aktualisiert, die folgenden bekannten Probleme wurden identifiziert:

Azure Co-Administrators kann jetzt Access Control Namespaces verwalten. Eine Aktion ist jedoch erforderlich, um vorhandene Co-Administratoren an eine bereits vorhandene Access Control Namespaces weiterzuverbreiten.

Vor dem Update vom November 2012 wurde ein Problem behoben, bei dem standardmäßig nur der primäre Azure-Dienstadministrator Access Control Namespaces verwalten konnte, die im Abonnement erstellt wurden. Wenn ein Azure-Co-Administrator versucht hat, auf das ACS-Verwaltungsportal für einen Access Control Namespace zuzugreifen, erhält er einen der folgenden ACS-Fehlercodes:

• ACS50000: Fehler beim Ausgeben eines Tokens.

• ACS60000: Fehler beim Verarbeiten von Regeln für vertrauende Parteien mithilfe des Ausstellers "uri:WindowsLiveID"

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

Dieses Problem wurde jetzt für neue Access Control Namespaces behoben, die von jedem Azure-Dienstadministrator oder Co-Administrator erstellt wurden. 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. Melden Sie sich bei der Azure-Portal (https://windows.azure.com/) mithilfe von Anmeldeinformationen des Dienstadministrators oder Kontoadministrators an.

2. Entfernen und erneutes Hinzufügen des co-Administrators mithilfe der Anleitungen zum Hinzufügen und Entfernen von Co-Administrators für Ihre Azure-Abonnements (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

3. Abmelden und Anmelden am Azure-Portal mithilfe der Anmeldeinformationen des Co-Administrators. Anschließend können Sie die Access Control Namespaces verwalten.

Versionsanmerkungen für das September 2012-Update

Im September 2012 erhielt Microsoft Azure Active Directory Access Control (auch bekannt als Access Control Service oder ACS) ein Update, das die folgenden Änderungen enthielt:

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

Das Attribut "entityID" in den von Access Control Namespaces veröffentlichten WS-Federation Metadaten ist jetzt immer Kleinbuchstaben. In früheren Versionen wurde die Groß-/Kleinschreibung verwendet, die bei der Erstellung des Namespace im Azure-Portal eingegeben wurde. Das Attribut "entityID" identifiziert den Access Control-Namespace für vertrauende Partyanwendungen und unten ist ein Beispiel für das 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 wurde erforderlich, um potenzielle Tokenüberprüfungsprobleme zu beheben, bei denen der Buchstabenfall des Access Control Namespace im ACS-ausgestellten Token (das immer Kleinschreibung ist) nicht mit dem Buchstabenfall des von der vertrauenden Partei importierten Access Control Namespace ü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

Alle X.509-Zertifikate, die über das ACS-Verwaltungsportal oder den Verwaltungsdienst in einen Access Control Namespace hochgeladen wurden, müssen jetzt über eine öffentliche Schlüsselgröße verfügen, die nicht größer als 4096 Bit ist. 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. Wenn bei dieser Version keine konfigurierten Tokensignaturzertifikate das Feld "Primär erstellen" aktiviert haben, verwendet der Access Control Namespace das vorhandene nicht primäre Tokensignaturzertifikat mit dem frühesten gültigen Startdatum, um das Token zu signieren. 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: Ändern des Signaturverhaltens bei Verwendung eines globalen Namespacezertifikats oder schlüssels zum Signieren eines JWT-Tokens

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 Signaturschlüssel, der dem Access Control Namespace zugewiesen ist

• Dem Access Control Namespace zugewiesenes X.509-Signaturzertifikat

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

• Dem Access Control Namespace zugewiesenes X.509-Signaturzertifikat

Versionsanmerkungen für das Juni 2012-Update

Im Juni 2012 erhielt ACS ein Update, das das folgende neue Feature enthält:

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

Dieses Update führt die Unterstützung für das JSON-Webtoken (JWT)-BETA-Format in ACS ein. JWT ist ein einfaches, JSON-codiertes Tokenformat, das mithilfe eines X.509-Zertifikats oder symmetrischen Schlüssels signiert werden kann und von ACS für Vertrauensparteianwendungen über eine der folgenden Protokolle ausgestellt werden kann:

• OAuth 2.0

• WS-Federation

• WS-Trust

Das JWT-Tokenformat ist jetzt eine auswahlfähige Option im Abschnitt "Anwendungen der vertrauenden Partei" des ACS-Verwaltungsportals und kann auch über den ACS-Verwaltungsdienst konfiguriert werden.

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

Versionsanmerkungen für das Mai 2012-Update

Anfang Mai 2012 erhielt ACS ein Update, das die folgende Änderung enthielt:

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

Der ACS-Verwaltungsdienst macht derzeit eine ID-Eigenschaft für jede der unterstützten Entitätstypen verfügbar, wie in der ACS-Verwaltungsdienst-API-Referenz beschrieben. Diese ID-Eigenschaften werden automatisch von ACS festgelegt und verwaltet.

In diesem Dienstupdate wird ACS zu einem anderen Datenbankschema migriert, und daher werden diese IDs, die über den Verwaltungsdienst verfügbar gemacht werden, für alle Entitätstypen geändert.

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

Um die Unterstützung für internationale Sprachen zu erweitern und die Sicherheit zu verbessern, aktualisiert diese Version von ACS die zugrunde liegende SQL Datenbanksortierung, die zum Vergleichen von Eingabeansprüchen von SQL_Latin1_General_CP1_CI_AS zu Latin1_General_100_BIN2 verwendet wird. Mit dieser Änderung kann ACS zusätzliche Zeichensätze und Kombinationen von 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.

Versionsanmerkungen für das Januar 2012-Update

Am 25. Januar 2012 erhielt ACS 2.0 ein Update, das die folgenden Änderungen enthielt:

• Änderungen an den ACS-Fehlerantworten für fehlgeschlagene Authentifizierungsanfragen

• Änderungen an den OAuth 2.0-Fehlercodes für fehlgeschlagene Authentifizierungsanfragen

Änderungen an den ACS-Fehlerantworten für fehlgeschlagene Authentifizierungsanfragen

In der vorherigen Version reagierte ACS mit unterschiedlichen Fehlercodes, wenn sich ein Client mit einem nicht vorhandenen Aussteller authentifiziert hat (Fehlercode: ACS50026) oder falsche Anmeldeinformationen (Fehlercode: ACS50006). 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 Fehlercodes ACS50008, ACS50009 oder ACS50012 für eine fehlgeschlagene Authentifizierung in den Fällen SWT, SAML und Benutzername/Kennwort zurück. Genauere Informationen entnehmen Sie der folgenden Tabelle:

Authentifizierungsantwort	Vor	Danach
Nicht existierender Aussteller	ACS50026 IssuerNotFound	ACS50008 InvalidSwt, ACS50009 InvalidSaml, OR ACS50012 AuthenticationFailed
Falsche Anmeldeinformationen	ACS50006 InvalidSignature

Änderungen an den OAuth 2.0-Fehlercodes für fehlgeschlagene Authentifizierungsanfragen

Auch in der vorherigen Version reagierte ACS mit verschiedenen OAuth 2.0-Fehlercodes, wenn ein Client mit einem nicht vorhandenen Aussteller (invalid_client) oder falschen Anmeldeinformationen (invalid_grant) authentifiziert wurde. Dieses Verhalten wurde ebenfalls aktualisiert, und ACS gibt invalid_request zurück, wenn die OAuth 2.0-Anforderung falsch formatiert ist, invalid_client, wenn die Clientauthentifizierung fehlschlägt oder die für die Authentifizierung bereitgestellte Assertion falsch formatiert oder ungültig ist, und invalid_grant, wenn der Autorisierungscode falsch formatiert oder ungültig ist. Genauere Informationen entnehmen Sie der folgenden Tabelle:

Authentifizierungsantwort	Beispiele	Vor	Danach
Nicht existierender Aussteller		invalid_client	invalid_client
Falsche Anmeldeinformationen	SWT ist mit einem falschen Schlüssel signiert. Client-ID und Anmeldeinformationen entsprechen denen, die in ACS konfiguriert sind.	invalid_grant
Fehler bei der Authentifizierung	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

Updatenotizen für Juli 2011

Die Versionshinweise für das Update vom Juli 2011 von ACS 2.0 enthält die folgenden Elemente:

• Voraussetzungen

• Neue Funktionen

• Änderungen

• Bekannte Probleme

• Bekannte Probleme

Voraussetzungen

Alle Access Control Namespaces erhalten automatisch das Update vom Juli 2011. Dieses Update enthält keine Änderungen an den ACS-Voraussetzungen für neue oder vorhandene Kunden. Weitere Informationen zu den aktuellen ACS-Voraussetzungen finden Sie unter ACS-Voraussetzungen.

Neue Funktionen

Das Update vom Juli 2011 auf ACS enthält die folgenden neuen Features:

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

Das ACS-Regelmodul unterstützt jetzt einen neuen Regeltyp, der bis zu zwei Eingabeansprüche konfiguriert werden kann, statt nur einen Eingabeanspruch. 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 kann ein zweiter Eingabeanspruch in einer neuen Regel angegeben werden, indem sie im Regel-Editor auf einen 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 vom ACS gehostete Anmeldeseite für Vertrauensparteianwendungen unterstützen jetzt die Lokalisierung in elf geschriebenen Sprachen, einschließlich 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 kann die angezeigte Sprache sofort mithilfe eines neuen Sprachauswahlmenüs geändert werden, das in der oberen rechten Ecke des Portals angezeigt wird.

• URL – Die im ACS-Verwaltungsportal angezeigte Sprache kann geändert werden, indem sie am Ende der Anforderungs-URL einen "lang"-Parameter hinzufügen. 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. Nachfolgend sehen Sie eine Beispiel-ACS-Verwaltungsportal-URL mit einem Parameter, der die angezeigte Sprache auf Französisch festlegt:

  https://your-namespace.accesscontrol.windows.net/?lang=fr

• Webbrowsereinstellungen – Wenn der URL-Parameter "lang" oder die Sprachauswahl nie verwendet wurde, um eine Spracheinstellung festzulegen, bestimmt das ACS-Verwaltungsportal und acS-gehostete Anmeldeseiten die Standardsprache, die basierend auf den in den Webbrowsereinstellungen festgelegten Spracheinstellungen angezeigt werden soll.

Änderungen

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 ersten Version von ACS war der Zeichencodierungssatz für alle HTTP-Antworten vom OAuth 2.0-Endpunkt US-ASCII. Ab dem Juli 2011-Update wird als Zeichencodierung für alle HTTP-Antworten nun UTF-8 verwendet, um erweiterte Zeichensätze zu unterstützen.

Bekannte Probleme

Das folgende Problem ist in dieser Version bekannt:

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

Derzeit kann der Regel-Editor im ACS-Verwaltungsportal nur Anspruchsaussteller anzeigen, die einem Identitätsanbieter oder ACS zugeordnet 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 so konfiguriert, dass ein Anspruchsausgebertyp verwendet wird, der vom Verwaltungsportal nicht unterstützt wird. Verwenden Sie den Verwaltungsdienst, um diese Regel anzuzeigen und zu bearbeiten.

Es gibt zwei unterstützte Szenarien, in denen ein Aussteller ohne einen zugeordneten Identitätsanbieter in ACS vorhanden sein kann:

• In einem OAuth 2.0-Delegierungsszenario wird ein Ausstellerdatensatz im Access Control Namespace mithilfe des ACS-Verwaltungsdiensts erstellt, und dieser Aussteller verfügt nicht über einen zugeordneten Identitätsanbieter.

• Wenn ein Aussteller zum Zweck der Durchsetzung von Ansprüchen in einer Tokenanforderung über das OAuth WRAP-Protokoll erstellt wird, während eine identisch benannte Dienstidentität zum Authentifizieren mit ACS verwendet wird.

Kontingente

Ab dieser Version erzwingt ACS keine Grenzwerte für die Anzahl der Identitätsanbieter, vertrauende Parteienanwendungen, Regelgruppen, Regeln, Dienstidentitäten, Anspruchstypen, Delegierungseinträge, Aussteller, Schlüssel und Adressen, die für einen bestimmten Access Control Namespace erstellt werden können.

Diensteinschränkungen

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