Zpráva k vydání verze

Aktualizováno: 19. června 2015

Platí pro: Azure

Toto téma popisuje nové funkce v každé verzi Microsoft Azure Active Directory Access Control (označované také jako služba Access Control service nebo ACS), vysvětluje, jak se jednotlivé verze produktu liší od předchůdců, a zvýrazní všechny zásadní změny, které by mohly ovlivnit kód napsaný pro dřívější verzi.

• Březen 2015 – Migrace oborů názvů ACS na Google OpenID Připojení

• Červen 2014 – Podpora zprostředkovatele identity Google

• Zpráva k vydání aktualizace z července 2013

• Zpráva k vydání aktualizace z prosince 2012

• Zpráva k vydání aktualizace ze září 2012

• Zpráva k vydání aktualizace z června 2012

• Zpráva k vydání verze z května 2012

• Zpráva k vydání verze aktualizace z ledna 2012

• Zpráva k vydání aktualizace z července 2011

Březen 2015 – Migrace oborů názvů ACS na Google OpenID Připojení

Služba ACS implementovala funkci, která vlastníkům oboru názvů ACS pomáhá migrovat konfigurace zprostředkovatele identity Google z OpenID 2.0 na OpenID Připojení. Zákazníci budou muset do 1. června 2015 migrovat své obory názvů ACS na OpenID Připojení a až do 1. ledna 2017 migrovat svůj back-endový kód, aby mohli používat identifikátory OpenID Připojení. Selhání provedení příslušné akce před každým termínem způsobí přerušení vašich aplikací. Podrobné pokyny najdete v tématu Migrace oborů názvů služby ACS na Google OpenID Připojení.

Červen 2014 – Podpora zprostředkovatele identity Google

Od 19. května 2014 nemůžou nové obory názvů služby ACS používat Google jako zprostředkovatele identity. Obory názvů služby ACS, které používaly Google a byly zaregistrovány před 19. květnem 2014, nejsou ovlivněné. Toto nové omezení existuje, protože Google postupně ukončuje podporu OpenID 2.0, na které služba ACS závisí, a má uzavřenou registraci pro nové aplikace. Stávající obory názvů služby ACS, které používaly Google, budou dál fungovat až do 20. dubna 2015. Pokud vaše aplikace vyžaduje podporu pro účty Google, doporučujeme aplikaci zaregistrovat přímo s nimi.

Pokud se uživatel pokusí přihlásit k novému oboru názvů služby ACS pomocí svého účtu Google, přesměruje se na chybovou stránku HTTP 400.

Zpráva k vydání aktualizace z července 2013

Kvůli zvýšení dostupnosti a výkonu služby ACS pro všechny uživatele služba ACS implementovala limit 30 požadavků na tokeny za sekundu pro každý obor názvů. Pokud obor názvů překročí tento limit po delší dobu, služba ACS odmítne žádosti o tokeny z oboru názvů po dobu trvání intervalu a vrátí chybu HTTP 429 / ACS90055 "Příliš mnoho požadavků". Další informace najdete v tématu Omezení služby ACS a kódy chyb služby ACS.

Zpráva k vydání aktualizace z prosince 2012

Nové funkce

Aktualizace služby ACS z prosince 2012 obsahuje následující nové funkce:

Podpora federovaného jednotného přihlašování pomocí protokolu WS-Federation

Webové aplikace, které používají službu ACS k povolení jednotného přihlašování s zprostředkovateli identit pomocí protokolu WS-Federation, teď můžou využívat funkce jednotného přihlašování. Když se uživatel odhlásí z webové aplikace, služba ACS se může automaticky odhlásit od zprostředkovatele identity a z jiných aplikací předávající strany, které používají stejného zprostředkovatele identity.

Tato funkce je zapnutá pro zprostředkovatele identity WS-Federation, včetně Active Directory Federation Services (AD FS) 2.0 a Windows Live ID (účet Microsoft). Pokud chcete povolit jednotné odhlašování, služba ACS provádí pro koncové body protokolu WS-Federation následující úlohy:

• Služba ACS rozpozná zprávy wsignoutcleanup1.0 od zprostředkovatelů identity a odpoví odesláním zpráv wsignoutcleanup1.0 aplikacím předávající strany.

• Služba ACS rozpozná zprávy wsignout1.0 a wreply z aplikací předávající strany a odpoví odesláním zpráv wsignout1.0 zprostředkovatelům identity a zprávám wsignoutcleanup1.0 aplikacím předávající strany.

Další informace najdete v tématu Ukázka kódu: ASP.NET MVC 4 s federovaným odhlašováním a pasivním ověřovánímpro ASP.NET ve WIF.

Ukončení podpory pro ACS 1.0

Podpora služby Access Control Service 1.0 je v této verzi ukončena, včetně podpory migrace ze služby Access Control Service 1.0 na službu Access Control Service 2.0.

Přechod na Access Control oborů názvů na novém portálu pro správu Azure

Nový portál pro správu Azure (https://manage.WindowsAzure.com) zahrnuje trasu na známý portál pro správu služby ACS, kde vytváříte a spravujete Access Control obory názvů.

Přechod na portál pro správu služby ACS:

1. Přejděte na portál pro správu Microsoft Azure (https://manage.WindowsAzure.com), přihlaste se a klikněte na Active Directory. (Tip pro řešení potíží: Položka Active Directory chybí nebo není k dispozici)

2. Klikněte na Access Control obor názvů a potom klikněte na Spravovat.

Chcete-li vytvořit obor názvů Access Control, klikněte na tlačítko Nový, klikněte na App Services, klikněte na Access Control a potom klikněte na Rychlé vytvoření. (Nebo klikněte na Access Control Obory názvů před kliknutím na Tlačítko Nový.)

Pokud potřebujete pomoc s úlohami správy služby ACS na portálu pro správu Microsoft Azure, klikněte na položku Active Directory a potom na tlačítko Nápověda (?). (Nebo klikněte na Active Directory, klikněte na Access Control Obory názvů a potom na Nápověda.)

Přechod na obor názvů Access Control pro service bus

Když vytvoříte obor názvů Service Bus na portálu, portál automaticky vytvoří obor názvů Access Control pro službu Service Bus.

Konfigurace a správa oboru názvů Access Control pro service bus:

1. Přihlaste se k portálu pro správu Azure.

2. Klikněte na Service Bus a pak vyberte service bus.

3. Klepněte na tlačítko Přístupový klíč a poté klepněte na tlačítko Otevřít portál pro správu služby ACS.

Pokud chcete ověřit, že je obor názvů Access Control přidružený ke službě Service Bus, podívejte se na pole Obor názvů služby v horní části stránky služby Access Control. Název oboru názvů se skládá z názvu služby Service Bus s příponou -sb.

Další informace najdete v tématu Postupy: Správa oboru názvů Access Control pro Service Bus.

Vylepšení portálu pro správu služby ACS pro zobrazení klíčů zprostředkovatele identity WS-Federation a skrytí hesel

Tato verze obsahuje pár vylepšení souvisejících se zobrazením a prací s certifikáty, klíči a hesly na portálu pro správu služby ACS 2.0:

• Podpisové certifikáty jsou teď viditelné v části Upravit WS-Federation Zprostředkovatel identity – dříve certifikáty importované z WS-Federation metadat použitých k ověření podpisu tokenů vydaných z tohoto zprostředkovatele identity nebyly na portálu pro správu služby ACS viditelné. V části Upravit WS-Federation zprostředkovatele identity se teď zobrazují informace o importovaných certifikátech, včetně jejich dat vypršení platnosti a stavu. Tyto certifikáty se teď dají aktualizovat pomocí nového zaškrtávacího políčka Znovu importovat data z adresy URL metadat WS-Federation při uložení.

• Hesla a symetrické podpisové klíče jsou teď ve výchozím nastavení skryté – Aby se zabránilo neúmyslnému zpřístupnění hesel a symetrických klíčů, jsou tyto hodnoty ve výchozím nastavení skryté na obrazovkách Pro úpravy na celém portálu. Chcete-li záměrně zobrazit hodnotu hesla nebo symetrického klíče (například ho můžete zkopírovat do aplikace), musí se teď stisknout tlačítko Zobrazit heslo nebo Zobrazit klíč.

Možnost federovat tenanty adresářů s Access Control obory názvů

Azure Active Directory tenanty se teď dají použít jako zprostředkovatelé identit v Access Control oborech názvů. To umožňuje mnoha scénářům, jako je povolení, aby vaše webová aplikace přijímala jak identity organizace z adresářových tenantů, tak identit příjemců od poskytovatelů sociálních sítí, jako je Facebook, Google, Yahoo!, účty Microsoft nebo jakýkoli jiný zprostředkovatel OpenID. Podrobné pokyny k implementaci scénáře najdete v tomto příspěvku– Zřízení tenanta Azure Active Directory jako zprostředkovatele identity v oboru názvů služby ACS.

Podpora protokolu SAML 2.0 pro aplikace předávající strany (Developer Preview)

Služba ACS teď podporuje protokol SAML 2.0 pro vydávání tokenů aplikacím předávající strany. Podpora protokolu SAML 2.0 byla vydána jako verze Preview pro vývojáře, což znamená, že podrobnosti implementace protokolu SAML 2.0 se stále můžou změnit. Další podrobnosti najdete v tématuDeveloper Preview: SAMLProtocol.

Známé problémy

V aktualizaci Microsoft Azure Active Directory Access Control (označované také jako služba Access Control nebo ACS) z prosince 2012 byly identifikovány následující známé problémy:

Azure Co-Administrators teď může spravovat obory názvů Access Control. Akce je však nutná k rozšíření před stávajících spolusprávců do již existujících Access Control oborů názvů.

Před aktualizací z listopadu 2012 jsme vyřešili problém, kdy ve výchozím nastavení mohl spravovat Access Control oborů názvů vytvořených v předplatném jenom primární správce služeb Azure. Pokud se spolusprávce Azure pokusil o přístup k portálu pro správu služby ACS pro Access Control obor názvů, obdrží jeden z následujících kódů chyb služby ACS:

• ACS50000: Při vydávání tokenu došlo k chybě.

• ACS60000: Při zpracování pravidel předávající strany pomocí vystavitele uri:WindowsLiveID došlo k chybě.

• ACS60001: Během zpracování pravidel nebyly generovány žádné výstupní deklarace identity.

Tento problém je teď vyřešen pro nové obory názvů Access Control vytvořené libovolným správcem služeb Azure nebo spolusprávcem. Zákazníci s obory názvů, které existovaly před opravou, ale musí provést následující alternativní řešení pro rozšíření dat spolusprávce do těchto oborů názvů:

1. Přihlaste se k Azure Portal (https://windows.azure.com/) pomocí přihlašovacích údajů správce služeb nebo správce účtu.

2. Odebrání a opětovné přidání spolusprávce pomocí pokynů v tématu Přidání a odebrání Co-Administrators pro předplatná Azure (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

3. Odhlaste se a přihlaste se k Azure Portal pomocí přihlašovacích údajů spolusprávce. Pak budete moct spravovat Access Control obory názvů.

Zpráva k vydání aktualizace ze září 2012

V září 2012 Microsoft Azure Active Directory Access Control (označované také jako služba Access Control nebo služba ACS) obdržela aktualizaci, která obsahovala následující změny:

ID entity publikované v metadatech WS-Federation generovaných službou ACS je teď konzistentně malými písmeny.

Atribut entityID v metadatech WS-Federation publikovaných Access Control obory názvů je teď vždy malými písmeny. V předchozích verzích použil písmena, která byla zadána při vytvoření oboru názvů v Azure Portal. Atribut entityID identifikuje obor názvů Access Control pro aplikace předávající strany a níže je příkladem atributu:

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

Tato změna se vyžadovala pro řešení potenciálních problémů s ověřováním tokenů, kdy písmena oboru názvů Access Control v tokenu vydaném službou ACS (což je vždy malé) neodpovídá písmenu písmena Access Control oboru názvů importovaného předávající stranou. Přijímající strany, které používají Windows Identity Foundation, nemají vliv na problémy s citlivostí velkých a malých písmen.

Certifikáty X.509 nahrané do služby ACS teď mají omezení velikosti veřejného klíče 4096 bitů.

Všechny certifikáty X.509 nahrané do oboru názvů Access Control prostřednictvím portálu pro správu služby ACS nebo služby pro správu jsou teď nutné, aby měly velikost veřejného klíče, která není větší než 4096 bitů. To zahrnuje certifikáty používané k podepisování tokenů, šifrování tokenů a dešifrování tokenů.

V Windows lze velikost veřejného klíče certifikátu zkontrolovat otevřením certifikátu (. Soubor CER) vyberte kartu Podrobnosti a zkontrolujte hodnotu pole Veřejný klíč. Certifikáty, které používají zabezpečený algoritmus podpisu sha256RSA, budou mít 2048bitový veřejný klíč.

Všechny existující certifikáty, které mají velikost klíče větší než 4096 bitů, budou dál fungovat se službou ACS, ale tyto certifikáty nelze v ACS znovu uložit, dokud nebudou nahrazeny kompatibilním certifikátem.

Menší změna algoritmu výběru primárního klíče, který se používá, když služba ACS podepíše token pomocí certifikátu X.509

Na portálu pro správu služby ACS a službě pro správu existuje pole Nastavit jako primární pro podpisové certifikáty tokenů, které při výběru způsobí, že služba ACS podpisuje tokeny pomocí daného certifikátu. Pokud v této verzi nejsou zaškrtnuté žádné nakonfigurované podpisové certifikáty tokenu, bude obor názvů Access Control používat existující podpisový certifikát bez primárního tokenu, který má nejstarší platné počáteční datum pro podepsání tokenu. Služba ACS stále nepodepisuje tokeny s podpisovým certifikátem jiného než primárního tokenu, pokud existuje primární certifikát, ale je neplatný nebo vypršela jeho platnost.

JWT Beta: Změna chování při přihlašování při použití globálního certifikátu oboru názvů nebo klíče k podepsání tokenu JWT

Když byla v červnu 2012 vydána podpora beta formátu webového tokenu JSON (JWT), služba ACS použila následující pořadí priorit k určení klíče, který se má použít k podepsání každého tokenu JWT vydaného pro každou aplikaci předávající strany:

• Symetrický podpisový klíč přiřazený předávající straně( pokud je k dispozici)

• Podpisový certifikát X.509 přiřazený předávající straně( pokud je k dispozici)

• Symetrický podpisový klíč přiřazený k oboru názvů Access Control

• Podpisový certifikát X.509 přiřazený k oboru názvů Access Control

Od této verze se symetrické klíče na úrovni oboru názvů už nepodporují pro podepisování tokenů JWT. Níže je nové pořadí priorit podepisování tokenů JWT:

• Symetrický podpisový klíč přiřazený předávající straně( pokud je k dispozici)

• Podpisový certifikát X.509 přiřazený předávající straně( pokud je k dispozici)

• Podpisový certifikát X.509 přiřazený k oboru názvů Access Control

Zpráva k vydání aktualizace z června 2012

V červnu 2012 obdržela služba ACS aktualizaci, která obsahovala následující novou funkci:

Formát JWT je teď k dispozici pro aplikace předávající strany (beta verze)

Tato aktualizace zavádí podporu formátu BETA webového tokenu JSON (JWT) v ACS. JWT je jednoduchý formát tokenu s kódováním JSON, který lze podepsat pomocí certifikátu X.509 nebo symetrického klíče a může ho služba ACS vystavit aplikacím předávající strany prostřednictvím některého z následujících protokolů:

• OAuth 2.0

• WS-Federation

• WS-Trust

Formát tokenu JWT je teď možnost výběru v části Aplikace předávající strany na portálu pro správu služby ACS a je také konfigurovatelná prostřednictvím služby pro správu služby ACS.

Další informace o formátu tokenu JWT najdete ve specifikaci webového tokenu JSON. Ukázky kódu ACS, které obsahují tokeny JWT, budou k dispozici k budoucímu datu.

Důležité

Podpora JWT je v ACS označená jako beta verze, což znamená, že všechny podrobnosti implementace JWT se můžou změnit. Vývojářům se doporučuje experimentovat s tímto formátem tokenu. JWT by se ale neměl používat v produkčních službách, protože chování se může změnit bez předchozího upozornění.

Zpráva k vydání verze z května 2012

Na začátku května 2012 obdržela služba ACS aktualizaci, která obsahovala následující změnu:

Změny vlastností ID entity vystavených prostřednictvím služby pro správu

Služba ACS Management Service aktuálně zveřejňuje vlastnost ID pro každý z typů entit, které podporuje, jak je popsáno v referenčních informacích k rozhraní API služby ACS Management. Tyto vlastnosti ID se automaticky nastaví a spravují službou ACS.

V této aktualizaci služby se služba ACS migruje do jiného schématu databáze a v důsledku toho se tato ID vystavená prostřednictvím služby pro správu změní pro všechny typy entit.

Obecně se nedoporučuje, aby aplikace ukládaly pevně zakódované závislosti na těchto ID, aby mohly dotazovat konkrétní entity prostřednictvím služby pro správu. Místo toho se doporučuje dotazovat typy entit RelyingParty, ServiceIdentity, RuleGroup a Issuer pomocí vlastnosti Name a jiné typy entit pomocí ID nadřazené entity (např. RuleGroupId v případě pravidel nebo IssuerId v případě zprostředkovatelů identity).

Změny kolace databáze pro zpracování pravidel

Aby bylo možné rozšířit podporu pro mezinárodní jazyky a zlepšit zabezpečení, aktualizuje tato verze služby ACS základní kolaci databáze SQL, která se používá k porovnání vstupních deklarací identity z SQL_Latin1_General_CP1_CI_AS na Latin1_General_100_BIN2. Tato změna umožňuje službě ACS podporovat další znakové sady a kombinace znakových sad. Aplikace, které se spoléhají na vstupní deklarace identity obsahující řetězce s více znakovými sadami, které SQL_Latin1_General_CP1_CI_AS nepodporují, se můžou v důsledku této nové kolace zobrazit jiné nebo další deklarace identity. Zákazníkům, kteří chtějí využít tuto novou funkci, se doporučuje ověřit kompatibilitu aplikací s novou kolací SQL.

Zpráva k vydání verze aktualizace z ledna 2012

25. ledna 2012 přijal ACS 2.0 aktualizaci, která obsahovala následující změny:

• Změna chybových odpovědí služby ACS pro neúspěšné žádosti o ověření

• Změna kódů chyb OAuth 2.0 pro neúspěšné žádosti o ověřování

Změna chybových odpovědí služby ACS pro neúspěšné žádosti o ověření

V předchozí verzi služba ACS odpověděla s různými kódy chyb, když se klient ověřil s neexistující vystavitelem (kód chyby: ACS50026) nebo nesprávnými přihlašovacími údaji (kód chyby: ACS50006). Tyto kódy chyb se dříve vygenerovaly, když se klient pokusil ověřit pomocí neplatného názvu identity služby nebo pomocí tokenu SWT nebo SAML vydaného z neplatného zprostředkovatele identity.

Služba ACS vrátí kódy chyb ACS50008, ACS50009 nebo ACS50012 pro neúspěšné ověřování v případech SWT, SAML a uživatelského jména a hesla. Podrobnosti najdete v následující tabulce:

Odpověď na ověřování	Před	Po
Neexistující vystavitel	ACS50026 IssuerNotFound	ACS50008 InvalidSwt, ACS50009 InvalidSaml, OR ACS50012 AuthenticationFailed
Nesprávné přihlašovací údaje	ACS50006 InvalidSignature

Změna kódů chyb OAuth 2.0 pro neúspěšné žádosti o ověřování

V předchozí verzi služba ACS také odpověděla s různými kódy chyb OAuth 2.0, když se klient ověřil s neexistující vystavitelem (invalid_client) nebo nesprávnými přihlašovacími údaji (invalid_grant). Toto chování se také aktualizovalo a služba ACS vrátí invalid_request, když je požadavek OAuth 2.0 poškozený, invalid_client pokud klient selže ověření nebo kontrolní výraz zadaný pro ověření je poškozený nebo neplatný, a invalid_grant, pokud je autorizační kód poškozený nebo neplatný. Podrobnosti najdete v následující tabulce:

Odpověď na ověřování	Příklady	Před	Po
Neexistující vystavitel		invalid_client	invalid_client
Nesprávné přihlašovací údaje	SWT je podepsán nesprávným klíčem. ID klienta a přihlašovací údaje odpovídají těm, které jsou nakonfigurované v ACS.	invalid_grant
Ověření se nezdařilo.	Ověření identifikátoru URI cílové skupiny se nezdařilo. Ověření certifikátu se nezdařilo. Kontrolní výraz z identity služby obsahuje deklarace identity vydané vlastním držitelem.	invalid_grant
Poškozený kontrolní výraz	V SWT chybí podpis. Kontrolní výraz SAML není platný xml.	invalid_request
Chybný autorizační kód		invalid_grant	invalid_grant
Autorizační kód je neplatný.		invalid_grant
Poškozený požadavek OAuth2		invalid_request	invalid_request

Zpráva k vydání aktualizace z července 2011

Zpráva k vydání verze pro aktualizaci ACS 2.0 z července 2011 obsahuje následující položky:

• Požadavky

• Nové funkce

• Změny

• Známé problémy

• Známé problémy

Požadavky

Všechny obory názvů Access Control automaticky obdrží aktualizaci z července 2011. Tato aktualizace neobsahuje žádné změny požadavků služby ACS pro nové nebo stávající zákazníky. Další informace o aktuálních požadavcích služby ACS najdete v tématu Požadavky služby ACS.

Nové funkce

Aktualizace služby ACS z července 2011 obsahuje následující nové funkce:

1. Pravidla teď podporují až dvě vstupní deklarace identity.

Modul pravidel služby ACS teď podporuje nový typ pravidla, který umožňuje konfiguraci až dvou vstupních deklarací identity místo jedné vstupní deklarace identity. Pravidla se dvěma vstupními deklaracemi identity lze použít ke snížení celkového počtu pravidel potřebných k provádění složitých funkcí autorizace uživatelů.

Na portálu pro správu služby ACS je možné zadat druhou vstupní deklaraci identity v novém pravidle kliknutím na Přidat druhou vstupní deklaraci identity v editoru pravidel. Ve službě pro správu je možné nakonfigurovat pravidla se dvěma vstupními deklaracemi identity pomocí typu entity ConditionalRule . Pravidla s jednou vstupní deklarací identity jsou stále nakonfigurovaná pomocí typu entity pravidla pro zpětnou kompatibilitu.

Další informace opravidlech

2. Lokalizace v jedenácti jazycích

Portál pro správu služby ACS a přihlašovací stránka hostovaná službou ACS pro aplikace předávající strany teď podporují lokalizaci v jedenácti psaných jazycích, včetně angličtiny, francouzštiny, němčiny, italštiny, japonštiny, korejštiny, ruštiny, španělštiny, portugalštiny (Brazílie), zjednodušené čínštiny a tradiční čínštiny. K dispozici je také možnost "Angličtina (Mezinárodní)", která používá alternativní formát data pro nastavení a zobrazení dat platnosti a vypršení platnosti klíčů. Psaný jazyk zobrazený pro tato uživatelská rozhraní lze změnit jedním z následujících tří způsobů:

• Výběr jazyka – Na portálu pro správu služby ACS je možné zobrazovaný jazyk okamžitě změnit pomocí nové nabídky selektoru jazyka, která se zobrazí v pravém horním rohu portálu.

• ADRESA URL – Jazyk zobrazený na portálu pro správu služby ACS lze změnit přidáním parametru "lang" na konec adresy URL požadavku. Právní hodnoty tohoto parametru jsou kódy jazyka ISO 639-1/3166, které odpovídají podporovanému jazyku. Mezi příklady patří en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn a zh-tw. Níže je příklad adresy URL portálu pro správu ACS s nastavením parametru zobrazeného jazyka na francouzštinu:

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

• Předvolby webového prohlížeče – Pokud se k nastavení jazykových předvoleb nikdy nepoužíval parametr adresy URL nebo selektor jazyka lang, určí portál pro správu služby ACS a přihlašovací stránky hostované službou ACS výchozí jazyk, který se má zobrazit podle jazykových předvoleb nastavených v nastavení webového prohlížeče.

Změny

Toto jsou důležité změny chování služeb v této verzi:

1. Kódování je nyní UTF-8 pro všechny odpovědi OAuth 2.0

V počáteční verzi služby ACS byla znaková sada pro všechny odpovědi HTTP z koncového bodu OAuth 2.0 us-ASCII. V aktualizaci z července 2011 je kódování znaků všech odpovědí HTTP nyní nastaveno na UTF-8 pro podporu rozšířených znakových sad.

Známé problémy

V této verzi je následující známý problém:

Editor pravidel nemůže zobrazit vlastní vystavitele, které nejsou přidružené k zprostředkovatelům identit.

Editor pravidel na portálu pro správu služby ACS v současné době může zobrazovat pouze vystavitele deklarací identity, které jsou přidružené k zprostředkovateli identity nebo službě ACS. Pokud je pravidlo načteno, které odkazuje na vystavitele, který neodpovídá některé z těchto věcí, zobrazí se následující chyba:

• ACS80001: Toto pravidlo je nakonfigurované tak, aby používalo typ vystavitele deklarace identity, který portál pro správu nepodporuje. Pomocí služby pro správu můžete toto pravidlo zobrazit a upravit.

Existují dva podporované scénáře, kdy vystavitel může existovat bez přidruženého zprostředkovatele identity v ACS:

• Ve scénáři delegování OAuth 2.0 se záznam vystavitele vytvoří v oboru názvů Access Control pomocí služby pro správu služby ACS a tento vystavitel nemá přidruženého zprostředkovatele identity.

• Když je vystavitel vytvořen pro účely uplatnění deklarací identity v požadavku na token přes protokol OAuth WRAP, zatímco při ověřování v ACS používá stejnou pojmenovanou identitu služby.

Kvóty

Od této verze služba ACS neukládá omezení počtu zprostředkovatelů identit, aplikací předávající strany, skupin pravidel, pravidel, identit služeb, typů deklarací identity, záznamů delegování, vystavitelů, klíčů a adres, které lze vytvořit pro daný Access Control obor názvů.

Omezení služeb

Další informace o omezeních služeb najdete v tématu Omezení služby ACS.