Opmerkingen bij de release

Bijgewerkt: 19 juni 2015

Van toepassing op: Azure

In dit onderwerp worden de nieuwe functies beschreven in elke release van Microsoft Azure Active Directory Access Control (ook wel bekend als Access Control Service of ACS), wordt uitgelegd hoe elke release van het product verschilt van zijn voorgangers en markeert belangrijke wijzigingen die van invloed kunnen zijn op code die voor een eerdere release zijn geschreven.

• Maart 2015 : ACS-naamruimten migreren naar Google OpenID-Verbinding maken

• Juni 2014 – Ondersteuning voor Google Identity Provider

• Releaseopmerkingen van de update van juli 2013

• Releaseopmerkingen van de update van december 2012

• Releaseopmerkingen van de update van september 2012

• Opmerkingen bij de release van de update van juni 2012

• Releaseopmerkingen bijwerken van mei 2012

• Opmerkingen bij de release van de update van januari 2012

• Opmerkingen bij de release van de update van juli 2011

Maart 2015 : ACS-naamruimten migreren naar Google OpenID-Verbinding maken

ACS heeft een functie geïmplementeerd om eigenaren van ACS-naamruimten te helpen bij het migreren van de configuraties van hun Google-id-provider van OpenID 2.0 naar OpenID Verbinding maken. Klanten hebben tot 1 juni 2015 de MOGELIJKHEID om hun ACS-naamruimten te migreren naar OpenID Verbinding maken en tot 1 januari 2017 om hun back-endcode te migreren om OpenID-Verbinding maken-id's te gebruiken. Als u de juiste actie niet kunt uitvoeren vóór elke deadline, leidt dit tot onderbrekingen van uw toepassingen. Zie ACS-naamruimten migreren naar Google OpenID Verbinding maken voor gedetailleerde richtlijnen.

Juni 2014 – Ondersteuning voor Google Identity Provider

Vanaf 19 mei 2014 kunnen nieuwe ACS-naamruimten Google niet gebruiken als id-provider. ACS-naamruimten die Google hebben gebruikt en die vóór 19 mei 2014 zijn geregistreerd, worden niet beïnvloed. Deze nieuwe beperking bestaat omdat Google de ondersteuning voor OpenID 2.0 affaseert, waarvan ACS afhankelijk is en de registratie voor nieuwe toepassingen heeft gesloten. Bestaande ACS-naamruimten die Google hebben gebruikt, blijven werken tot 20 april 2015. Als uw toepassing ondersteuning vereist voor Google-accounts, raden we u aan uw toepassing rechtstreeks bij hen te registreren.

Als een gebruiker zich probeert aan te melden bij een nieuwe ACS-naamruimte met behulp van zijn Google-account, wordt deze omgeleid naar een HTTP 400-foutpagina.

Releaseopmerkingen van de update van juli 2013

Om de beschikbaarheid en prestaties van ACS voor alle gebruikers te verhogen, heeft ACS een limiet van 30 tokenaanvragen per seconde geïmplementeerd voor elke naamruimte. Als een naamruimte deze limiet voor een langere periode overschrijdt, weigert ACS tokenaanvragen van de naamruimte voor de duur van het interval en retourneert een HTTP 429/ACS90055-fout 'Te veel aanvragen'. Zie ACS-servicebeperkingen en ACS-foutcodes voor meer informatie.

Releaseopmerkingen van de update van december 2012

Nieuwe functies

De update van DECEMBER 2012 van ACS bevat de volgende nieuwe functies:

Ondersteuning voor federatieve eenmalige aanmelding met behulp van het WS-Federation-protocol

Webtoepassingen die ACS gebruiken om eenmalige aanmelding (SSO) met id-providers in te schakelen met behulp van het WS-Federation-protocol, kunnen nu gebruikmaken van mogelijkheden voor eenmalige afmelding. Wanneer een gebruiker zich afmeldt bij een webtoepassing, kan ACS de gebruiker automatisch afmelden bij de id-provider en bij andere relying party-toepassingen die gebruikmaken van dezelfde id-provider.

Deze functie is ingeschakeld voor WS-Federation id-providers, waaronder Active Directory Federation Services 2.0 en Windows Live ID (Microsoft-account). Als u eenmalige afmelding wilt inschakelen, voert ACS de volgende taken uit voor WS-Federation protocoleindpunten:

• ACS herkent wsignoutcleanup1.0-berichten van id-providers en reageert door wsignoutcleanup1.0-berichten te verzenden naar relying party-toepassingen.

• ACS herkent wsignout1.0 en wreply-berichten van relying party-toepassingen en reageert door wsignout1.0-berichten te verzenden naar id-providers en wsignoutcleanup1.0-berichten naar relying party-toepassingen.

Zie Codevoorbeeld: ASP.NET MVC 4 met federatieve afmelding en passieve verificatie voor ASP.NET in WIF voor meer informatie.

Ondersteuning voor ACS 1.0 stoppen

Ondersteuning voor Access Control Service 1.0 wordt in deze release stopgezet, inclusief ondersteuning voor het migreren van Access Control Service 1.0 naar Access Control Service 2.0.

Navigeren naar Access Control naamruimten in de nieuwe Azure-beheerportal

De nieuwe Azure Management Portal (https://manage.WindowsAzure.com) bevat een route naar de vertrouwde ACS-beheerportal waar u Access Control naamruimten maakt en beheert.

Ga naar de ACS-beheerportal:

1. Ga naar de Microsoft Azure-beheerportal (https://manage.WindowsAzure.com), meld u aan en klik vervolgens op Active Directory. (Tip voor probleemoplossing: Item 'Active Directory' ontbreekt of is niet beschikbaar)

2. Klik op een Access Control naamruimte en klik vervolgens op Beheren.

Als u een Access Control naamruimte wilt maken, klikt u op Nieuw, klikt u op App Services, klikt u op Access Control en klikt u vervolgens op Snel maken. (Of klik op Access Control Naamruimten voordat u op Nieuw klikt.)

Klik op Active Directory en klik vervolgens op Help (?) voor hulp bij ACS-beheertaken in de Microsoft Azure-beheerportal. (Of klik op Active Directory, klik op Access Control naamruimten en klik vervolgens op Help.)

Navigeren naar de Access Control-naamruimte voor een servicebus

Wanneer u een Service Bus naamruimte in de portal maakt, wordt er automatisch een Access Control naamruimte voor de service bus gemaakt.

De Access Control-naamruimte voor een servicebus configureren en beheren:

1. Meld u aan bij de Azure-beheerportal.

2. Klik op Service Bus en selecteer vervolgens een servicebus.

3. Klik op Toegangssleutel en klik vervolgens op ACS-beheerportal openen.

Als u wilt controleren of de Access Control-naamruimte is gekoppeld aan de servicebus, raadpleegt u het veld Servicenaamruimte boven aan de pagina Access Control Service. De naamruimtenaam bestaat uit de service bus-naam met een achtervoegsel '-sb'.

Zie Procedure: De Access Control naamruimte voor een Service Bus beheren voor meer informatie.

Verbeteringen in acs-beheerportal voor het weergeven van WS-Federation sleutels van id-provider, het verbergen van wachtwoorden

Deze release bevat een paar verbeteringen met betrekking tot het weergeven en werken met certificaten, sleutels en wachtwoorden in de ACS 2.0-beheerportal:

• Ondertekeningscertificaten zijn nu zichtbaar in de sectie Bewerken WS-Federation Id-provider : eerder zijn certificaten geïmporteerd uit WS-Federation metagegevens die worden gebruikt om de handtekening van tokens die zijn uitgegeven door die id-provider, niet zichtbaar te zijn in de ACS-beheerportal. De sectie Edit WS-Federation Identity Provider geeft nu informatie weer over geïmporteerde certificaten, inclusief de vervaldatums en status. Deze certificaten kunnen nu worden vernieuwd met behulp van het selectievakje 'Gegevens opnieuw importeren uit WS-Federation metagegevens-URL bij opslaan'.

• Wachtwoorden en symmetrische ondertekeningssleutels zijn nu standaard verborgen : om onbedoelde openbaarmaking van wachtwoorden en symmetrische sleutels te voorkomen, worden deze waarden nu standaard verborgen op de schermen Bewerken in de portal. Als u de waarde van een wachtwoord of symmetrische sleutel opzettelijk wilt weergeven (bijvoorbeeld, zodat deze kan worden gekopieerd naar een toepassing), moet nu een knop Wachtwoord weergeven of Sleutel weergeven worden ingedrukt.

Mogelijkheid om Directory-tenants te federeren met Access Control naamruimten

Azure Active Directory tenants kunnen nu worden gebruikt als id-providers in Access Control naamruimten. Hierdoor kunnen veel scenario's, zoals het inschakelen van uw webtoepassing, zowel organisatie-id's van directorytenants als consumentenidentiteiten van sociale providers accepteren, zoals Facebook, Google, Yahoo!, Microsoft-accounts of een andere OpenID-provider. In dit bericht vindt u gedetailleerde instructies voor het implementeren van het scenario, het inrichten van een Azure Active Directory-tenant als een id-provider in een ACS-naamruimte.

SAML 2.0 Protocol Support for Relying Party Applications (Developer Preview)

ACS ondersteunt nu het SAML 2.0-protocol voor het uitgeven van tokens aan relying party-toepassingen. Ondersteuning voor SAML 2.0-protocol is uitgebracht als preview-versie van een ontwikkelaar, wat betekent dat details van de implementatie van het SAML 2.0-protocol nog steeds onderhevig zijn aan wijzigingen. ZieDeveloper Preview: SAMLProtocol voor meer informatie.

Bekende problemen

In de update van december 2012 zijn de volgende bekende problemen geïdentificeerd Microsoft Azure Active Directory Access Control (ook wel bekend als Access Control Service of ACS):

Azure Co-Administrators kan nu Access Control naamruimten beheren. Er is echter een actie vereist om bestaande co-beheerders door te geven aan een bestaande Access Control naamruimten.

Vóór de update van november 2012 hebben we een probleem opgelost waarbij standaard alleen de primaire Azure-servicebeheerder Access Control naamruimten kon beheren die in het abonnement zijn gemaakt. Als een Azure-medebeheerder heeft geprobeerd toegang te krijgen tot de ACS-beheerportal voor een Access Control naamruimte, ontvangen ze een van de volgende ACS-foutcodes:

• ACS50000: er is een fout opgetreden bij het uitgeven van een token.

• ACS60000: Er is een fout opgetreden tijdens het verwerken van regels voor relying party met behulp van verlener 'uri:WindowsLiveID'

• ACS60001: Er zijn geen uitvoerclaims gegenereerd tijdens de verwerking van regels.

Dit probleem is nu opgelost voor nieuwe Access Control naamruimten die zijn gemaakt door een Azure-servicebeheerder of co-beheerder. Klanten met naamruimten die bestonden vóór de oplossing, moeten echter de volgende tijdelijke oplossing uitvoeren voor co-beheerdersgegevens die moeten worden doorgegeven aan deze naamruimten:

1. Meld u aan bij de Azure Portal (https://windows.azure.com/) met de referenties van de servicebeheerder of accountbeheerder.

2. Verwijder en voeg de medebeheerder opnieuw toe met behulp van de richtlijnen in Het toevoegen en verwijderen van Co-Administrators voor uw Azure-abonnementen (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

3. Meld u af en meld u aan bij de Azure Portal met behulp van de referenties van de co-beheerder. Vervolgens kunt u de Access Control naamruimten beheren.

Releaseopmerkingen van de update van september 2012

In september 2012 ontving Microsoft Azure Active Directory Access Control (ook wel bekend als Access Control Service of ACS) een update met de volgende wijzigingen:

De entityID die is gepubliceerd in de WS-Federation metagegevens die door ACS worden verzonden, is nu consistent in kleine letters

Het kenmerk entityID in de WS-Federation metagegevens die zijn gepubliceerd door Access Control naamruimten, is nu altijd kleine letters. In eerdere versies werd de lettercase gebruikt die werd ingevoerd toen de naamruimte werd gemaakt in de Azure Portal. Het kenmerk entityID identificeert de Access Control naamruimte voor relying party-toepassingen. Hieronder ziet u een voorbeeld van het kenmerk:

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

Deze wijziging is vereist om mogelijke problemen met tokenvalidatie op te lossen waarin de letter-case van de Access Control naamruimte in het door ACS uitgegeven token (dat altijd kleine letters is) niet overeenkomt met de letter-case van de Access Control naamruimte die door de relying party is geïmporteerd. Relying party's die gebruikmaken van Windows Identity Foundation worden niet beïnvloed door de problemen met hoofdlettergevoeligheid.

X.509-certificaten die naar ACS zijn geüpload, hebben nu een beperking van de grootte van een openbare sleutel van 4096 bits

Alle X.509-certificaten die zijn geüpload naar een Access Control naamruimte via de ACS-beheerportal of -beheerservice, moeten nu een openbare-sleutelgrootte hebben die niet groter is dan 4096 bits. Dit omvat certificaten die worden gebruikt voor tokenondertekening, tokenversleuteling en tokenontsleuteling.

In Windows kan de grootte van de openbare sleutel van een certificaat worden gecontroleerd door het certificaat te openen (. CER)-bestand, het tabblad Details selecteren en de waarde van het veld Openbare sleutel controleren. Certificaten die gebruikmaken van het beveiligde sha256RSA-handtekeningalgoritme hebben een openbare sleutel van 2048 bits.

Bestaande certificaten met een sleutelgrootte van meer dan 4096 bits blijven werken met ACS, maar deze certificaten kunnen niet opnieuw worden opgeslagen in ACS totdat ze worden vervangen door een compatibel certificaat.

Kleine wijziging in selectie-algoritme 'primaire sleutel' dat wordt gebruikt wanneer ACS een token ondertekent met behulp van een X.509-certificaat

In de ACS-beheerportal en -beheerservice is er een veld Primair maken voor certificaten voor tokenondertekening die, wanneer deze optie is geselecteerd, ACS tokentekent met dat certificaat. Als met deze release geen geconfigureerde certificaten voor tokenondertekening het veld Primair maken hebben ingeschakeld, gebruikt de Access Control naamruimte het bestaande niet-primaire tokenondertekeningscertificaat met de vroegste geldige begindatum om het token te ondertekenen. ACS ondertekent nog steeds geen tokens met een niet-primair tokenondertekeningscertificaat als er een primair certificaat bestaat, maar is ongeldig of is verlopen.

JWT Beta: gedrag van ondertekening wijzigen wanneer u een algemeen naamruimtecertificaat of sleutel gebruikt om een JWT-token te ondertekenen

Toen bèta-ondersteuning voor de JSON Web Token-indeling (JWT) werd uitgebracht in juni 2012, gebruikte ACS de volgende volgorde van prioriteit om te bepalen welke sleutel moet worden gebruikt om elk JWT-token te ondertekenen dat is uitgegeven aan elke relying party-toepassing:

• Symmetrische ondertekeningssleutel die is toegewezen aan relying party, indien beschikbaar

• X.509-handtekeningcertificaat dat is toegewezen aan relying party, indien beschikbaar

• Symmetrische ondertekeningssleutel die is toegewezen aan de Access Control naamruimte

• X.509-handtekeningcertificaat dat is toegewezen aan de Access Control-naamruimte

Vanaf deze release worden symmetrische sleutels voor de gehele naamruimte niet meer ondersteund voor het ondertekenen van JWT-tokens. Hieronder ziet u de nieuwe volgorde van prioriteit voor het ondertekenen van JWT-tokens:

• Symmetrische ondertekeningssleutel die is toegewezen aan relying party, indien beschikbaar

• X.509-handtekeningcertificaat dat is toegewezen aan relying party, indien beschikbaar

• X.509-handtekeningcertificaat dat is toegewezen aan de Access Control-naamruimte

Releaseopmerkingen voor update van juni 2012

In juni 2012 heeft ACS een update ontvangen met de volgende nieuwe functie:

JWT-indeling is nu beschikbaar voor relying party-toepassingen (bèta)

Deze update introduceert ondersteuning voor de JSON Web Token (JWT) BETA-indeling in ACS. JWT is een lichtgewicht, JSON-gecodeerde tokenindeling die kan worden ondertekend met behulp van een X.509-certificaat of symmetrische sleutel en kan worden uitgegeven door ACS voor relying party-toepassingen via een van de volgende protocollen:

• OAuth 2.0

• Webservices-federatie

• WS-Trust

De indeling van het JWT-token is nu een selecteerbare optie in de sectie Relying Party Applications van de ACS-beheerportal en kan ook worden geconfigureerd via de ACS-beheerservice.

Zie de JSON-webtokenspecificatie voor meer informatie over de JWT-tokenindeling. ACS-codevoorbeelden die JWT-tokens bevatten, worden op een toekomstige datum weergegeven.

Belangrijk

JWT-ondersteuning is gemarkeerd als bèta in ACS, wat betekent dat alle details van de JWT-implementatie onderhevig zijn aan wijzigingen. Ontwikkelaars worden aangemoedigd om te experimenteren met deze tokenindeling. JWT mag echter niet worden gebruikt in productieservices, omdat het gedrag zonder kennisgeving kan veranderen.

Releaseopmerkingen bij de update van mei 2012

Begin mei 2012 heeft ACS een update ontvangen met de volgende wijziging:

Wijzigingen in eigenschappen van entiteits-id's die worden weergegeven via de beheerservice

De ACS Management-service stelt momenteel een id-eigenschap beschikbaar voor elk van de entiteitstypen die worden ondersteund, zoals beschreven in de API-verwijzing van de ACS Management Service. Deze id-eigenschappen worden automatisch ingesteld en beheerd door ACS.

In deze service-update wordt ACS gemigreerd naar een ander databaseschema, waardoor deze id's die via de beheerservice worden weergegeven, worden gewijzigd voor alle entiteitstypen.

Het is ongebruikelijk en wordt over het algemeen niet aanbevolen dat toepassingen een vastgelegde afhankelijkheid opslaan of gebruiken om query's uit te voeren op specifieke entiteiten via de beheerservice. In plaats daarvan wordt aanbevolen om de entiteitstypen RelyingParty, ServiceIdentity, RuleGroup en Issuer op te vragen met behulp van de eigenschap Naam en andere entiteitstypen worden opgevraagd met behulp van een bovenliggende entiteits-id (bijvoorbeeld RuleGroupId in het geval van regels of IssuerId in het geval van id-providers).

Wijzigingen in databasesortering voor de verwerking van regels

Om de ondersteuning voor internationale talen uit te breiden en de beveiliging te verbeteren, werkt deze versie van ACS de onderliggende SQL databasesortering bij die wordt gebruikt om invoerclaims van SQL_Latin1_General_CP1_CI_AS te vergelijken met Latin1_General_100_BIN2. Met deze wijziging kan ACS aanvullende tekensets en combinaties van tekensets ondersteunen. Toepassingen die afhankelijk zijn van invoerclaims die tekenreeksen met meerdere tekensets bevatten, die niet worden ondersteund door SQL_Latin1_General_CP1_CI_AS kunnen verschillende of aanvullende claims zien als gevolg van deze nieuwe sortering. Klanten die willen profiteren van deze nieuwe mogelijkheid, worden aangemoedigd om hun toepassingen te valideren voor compatibiliteit met de nieuwe SQL sortering.

Opmerkingen bij de release van de update van januari 2012

Op 25 januari 2012 heeft ACS 2.0 een update ontvangen met de volgende wijzigingen:

• Wijziging in ACS-foutreacties voor mislukte verificatieaanvragen

• Wijziging in OAuth 2.0-foutcodes voor mislukte verificatieaanvragen

Wijziging in ACS-foutreacties voor mislukte verificatieaanvragen

In de vorige release heeft ACS gereageerd met verschillende foutcodes wanneer een client is geverifieerd met een niet-bestaande verlener (foutcode: ACS50026) of onjuiste referenties (foutcode: ACS50006). Deze foutcodes werden eerder verzonden toen een client probeerde te verifiëren met behulp van een ongeldige service-id-naam of met behulp van een SWT- of SAML-token dat is uitgegeven door een ongeldige id-provider.

ACS retourneert foutcodes ACS50008, ACS50009 of ACS50012 voor een mislukte verificatie in het geval van RESPECTIEVELIJK SWT, SAML en gebruikersnaam/wachtwoord. Zie de onderstaande tabel voor meer informatie:

Verificatiereactie	Voor	Na
Niet-bestaande verlener	ACS50026 IssuerNotFound	ACS50008 InvalidSwt, ACS50009 InvalidSaml, OR ACS50012 AuthenticationFailed
Onjuiste referenties	ACS50006 InvalidSignature

Wijziging in OAuth 2.0-foutcodes voor mislukte verificatieaanvragen

Ook in de vorige release heeft ACS gereageerd met verschillende OAuth 2.0-foutcodes wanneer een client is geverifieerd met een niet-bestaande verlener (invalid_client) of onjuiste referenties (invalid_grant). Dit gedrag is ook bijgewerkt en ACS retourneert invalid_request wanneer de OAuth 2.0-aanvraag ongeldig is, invalid_client als de client mislukte verificatie of de verklaring die is opgegeven voor verificatie ongeldig of ongeldig is, en invalid_grant als de autorisatiecode ongeldig of ongeldig is. Zie de onderstaande tabel voor meer informatie:

Verificatiereactie	Voorbeelden	Voor	Na
Niet-bestaande verlener		invalid_client	invalid_client
Onjuiste referenties	SWT is ondertekend met een onjuiste sleutel. Client-id en -referenties komen overeen met de referenties die zijn geconfigureerd in ACS.	invalid_grant
De verificatie is mislukt	Validatie van doelgroep-URI is mislukt. Certificaatvalidatie is mislukt. Assertion from a Service Identity bevat zelf uitgegeven claims.	invalid_grant
Ongeldige assertie	Handtekening ontbreekt in SWT. SAML-assertie is geen geldige XML.	invalid_request
Ongeldige autorisatiecode		invalid_grant	invalid_grant
Autorisatiecode is ongeldig		invalid_grant
Onjuiste OAuth2-aanvraag		invalid_request	invalid_request

Opmerkingen bij de release van de update van juli 2011

De releaseopmerkingen voor de update van juli 2011 van ACS 2.0 bevatten de volgende items:

• Vereisten

• Nieuwe functies

• Wijzigingen

• Bekende problemen

• Bekende problemen

Vereisten

Alle Access Control naamruimten ontvangen automatisch de update van juli 2011. Deze update bevat geen wijzigingen in de ACS-vereisten voor nieuwe of bestaande klanten. Zie ACS-vereisten voor meer informatie over de huidige ACS-vereisten.

Nieuwe functies

De update van juli 2011 naar ACS bevat de volgende nieuwe functies:

1. Regels ondersteunen nu maximaal twee invoerclaims

De ACS-regelengine ondersteunt nu een nieuw type regel waarmee maximaal twee invoerclaims kunnen worden geconfigureerd, in plaats van slechts één invoerclaim. Regels met twee invoerclaims kunnen worden gebruikt om het totale aantal regels te verminderen dat nodig is om complexe gebruikersautorisatiefuncties uit te voeren.

In de ACS-beheerportal kan een tweede invoerclaim worden opgegeven in een nieuwe regel door te klikken op Een tweede invoerclaim toevoegen in de regeleditor. In de beheerservice kunnen regels met twee invoerclaims worden geconfigureerd met behulp van het entiteitstype ConditionalRule . Regels met één invoerclaim worden nog steeds geconfigureerd met behulp van het type Regelentiteit voor compatibiliteit met eerdere versies.

Zie Regelgroepen en regels voor meer informatie over regels met twee invoerclaims.

2. Lokalisatie in elf talen

De ACS-beheerportal en de door ACS gehoste aanmeldingspagina voor relying party-toepassingen ondersteunen nu lokalisatie in elf geschreven talen, waaronder Engels, Frans, Duits, Italiaans, Japans, Koreaans, Russisch, Spaans, Portugees (Brazilië), Vereenvoudigd Chinees en Traditioneel Chinees. Er is ook een optie Engels (internationaal) beschikbaar die een alternatieve datumnotatie gebruikt voor het instellen en weergeven van effectieve/vervaldatums voor sleutels. De geschreven taal die voor deze gebruikersinterfaces wordt weergegeven, kan op een van de volgende drie manieren worden gewijzigd:

• Taalkiezer : in de ACS-beheerportal kan de weergegeven taal direct worden gewijzigd met behulp van een nieuw taalkiezermenu dat in de rechterbovenhoek van de portal wordt weergegeven.

• URL : de taal die wordt weergegeven in de ACS-beheerportal, kan worden gewijzigd door een 'lang'-parameter toe te voegen aan het einde van de aanvraag-URL. De juridische waarden voor deze parameter zijn ISO 639-1/3166 taalcodes die overeenkomen met een ondersteunde taal. Voorbeelden van waarden zijn en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn en zh-tw. Hieronder ziet u een voorbeeld van de URL van de ACS-beheerportal met een parameterinstelling voor de weergegeven taal in het Frans:

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

• Webbrowservoorkeuren : als de URL-parameter 'lang' of taalkiezer nooit is gebruikt om een taalvoorkeur in te stellen, bepalen de ACS-beheerportal- en ACS-gehoste aanmeldingspagina's de standaardtaal die moet worden weergegeven op basis van de taalvoorkeuren die zijn ingesteld in de instellingen van de webbrowser.

Wijzigingen

Hier volgen belangrijke wijzigingen in het servicegedrag in deze release:

1. Encoding is nu UTF-8 voor alle OAuth 2.0-antwoorden

In de eerste release van ACS was de tekencodering die is ingesteld voor alle HTTP-antwoorden van het OAuth 2.0-eindpunt US-ASCII. In de update van juli 2011 wordt de tekencodering van alle HTTP-antwoorden nu ingesteld op UTF-8 ter ondersteuning van uitgebreide tekensets.

Bekende problemen

Hier volgt een bekend probleem in deze release:

Regeleditor kan geen aangepaste verleners weergeven die niet zijn gekoppeld aan id-providers

Momenteel kan de regeleditor in de ACS-beheerportal alleen claimverleners weergeven die zijn gekoppeld aan een id-provider of ACS. Als een regel wordt geladen die verwijst naar een verlener die niet overeenkomt met een van deze dingen, wordt de volgende fout weergegeven:

• ACS80001: Deze regel is geconfigureerd voor het gebruik van een claimverlenertype dat niet wordt ondersteund door de beheerportal. Gebruik de beheerservice om deze regel weer te geven en te bewerken.

Er zijn twee ondersteunde scenario's waarin een verlener kan bestaan zonder een gekoppelde id-provider in ACS:

• In een OAuth 2.0-delegeringsscenario wordt een verlenerrecord gemaakt in de Access Control naamruimte met behulp van de ACS Management-service en heeft deze verlener geen gekoppelde id-provider.

• Wanneer een verlener wordt gemaakt voor het claimen van claims in een tokenaanvraag via het OAuth WRAP-protocol, terwijl u een identieke service-id gebruikt om te verifiëren met ACS.

Quota

Vanaf deze release legt ACS geen limieten op voor het aantal id-providers, relying party-toepassingen, regelgroepen, regels, service-id's, claimtypen, overdrachtsrecords, verleners, sleutels en adressen die kunnen worden gemaakt voor een bepaalde Access Control naamruimte.

Servicebeperkingen

Zie ACS-servicebeperkingen voor meer informatie over servicebeperkingen.