Kibocsátási megjegyzések

Frissítve: 2015. június 19.

Érintett kiadások: Azure

Ez a témakör a Microsoft Azure Active Directory Access Control egyes kiadásainak új funkcióit (más néven Access Control Service-t vagy ACS-t) ismerteti, ismerteti, hogy a termék egyes kiadásai miben különböznek elődeitől, és kiemeli azokat a kompatibilitástörő változásokat, amelyek hatással lehetnek egy korábbi kiadásra írt kódra.

• 2015. március – ACS-névterek migrálása a Google OpenID-Csatlakozás

• 2014. június – Google Identity Provider-támogatás

• 2013. júliusi frissítés kibocsátási megjegyzései

• 2012. decemberi frissítés kibocsátási megjegyzései

• 2012. szeptemberi frissítés kibocsátási megjegyzései

• 2012. júniusi frissítés kibocsátási megjegyzései

• 2012. májusi frissítés kibocsátási megjegyzései

• 2012. januári frissítés kibocsátási megjegyzései

• 2011. júliusi frissítés kibocsátási megjegyzései

2015. március – ACS-névterek migrálása a Google OpenID-Csatlakozás

Az ACS olyan funkciót implementált, amellyel az ACS-névterek tulajdonosai áttelepíthetik Google-identitásszolgáltatói konfigurációikat az OpenID 2.0-ról az OpenID Csatlakozás. Az ügyfeleknek 2015. június 1-ig át kell telepíteniük az ACS-névtereiket az OpenID Csatlakozás, majd 2017. január 1-jéig át kell telepíteniük a háttérkódot az OpenID Csatlakozás azonosítók használatára. Ha nem hajtja végre a megfelelő műveletet az egyes határidők előtt, az megzavarja az alkalmazásokat. Részletes útmutatásért lásd: ACS-névterek migrálása a Google OpenID-Csatlakozás.

2014. június – Google Identity Provider-támogatás

2014. május 19-én az új ACS-névterek nem használhatják a Google-t identitásszolgáltatóként. A Google-t használó, 2014. május 19. előtt regisztrált ACS-névterekre nincs hatással. Ez az új korlátozás azért létezik, mert a Google megszüntette az OpenID 2.0 támogatását, amelytől az ACS függ, és lezárta az új alkalmazások regisztrációját. A Google-t használó meglévő ACS-névterek 2015. április 20-ig fognak működni. Ha az alkalmazás támogatást igényel a Google-fiókokhoz, javasoljuk, hogy közvetlenül regisztrálja az alkalmazást velük.

Ha egy felhasználó a Google-fiókjával próbál bejelentkezni egy új ACS-névtérbe, a rendszer átirányítja egy HTTP 400 hibaoldalra.

2013. júliusi frissítés kibocsátási megjegyzései

Az ACS rendelkezésre állásának és teljesítményének növelése érdekében az ACS másodpercenként legfeljebb 30 jogkivonat-kérést implementált az egyes névterekhez. Ha egy névtér hosszabb ideig meghaladja ezt a korlátot, az ACS elutasítja a névtérből érkező jogkivonat-kérelmeket az időköz időtartamára, és HTTP 429/ACS90055 "Túl sok kérelem" hibát ad vissza. További információ: Az ACS szolgáltatás korlátozásai és az ACS-hibakódok.

2012. decemberi frissítés kibocsátási megjegyzései

Új funkciók

Az ACS 2012. decemberi frissítése a következő új funkciókat tartalmazza:

Összevont egyszeri kijelentkezés támogatása az WS-Federation protokoll használatával

Azok a webalkalmazások, amelyek ACS használatával engedélyezik az egyszeri bejelentkezést (SSO) az WS-Federation protokollt használó identitásszolgáltatókkal, most már kihasználhatják az egyszeri kijelentkezési képességek előnyeit. Amikor egy felhasználó kijelentkezik egy webalkalmazásból, az ACS automatikusan kijelentkeztetheti a felhasználót az identitásszolgáltatóból és az azonos identitásszolgáltatót használó más függő entitásalkalmazások közül.

Ez a funkció WS-Federation identitásszolgáltatók számára érhető el, beleértve a Active Directory összevonási szolgáltatások (AD FS) 2.0-t és a Windows Live ID-t (Microsoft-fiók). Az egyszeri kijelentkezés engedélyezéséhez az ACS a következő feladatokat hajtja végre WS-Federation protokollvégpontokon:

• Az ACS felismeri az identitásszolgáltatóktól érkező wsignoutcleanup1.0 üzeneteket, és úgy válaszol, hogy wsignoutcleanup1.0-üzeneteket küld a függő entitásalkalmazásoknak.

• Az ACS felismeri a függő entitásalkalmazásokból érkező wsignout1.0 és wreply üzeneteket, és úgy válaszol, hogy wsignout1.0-üzeneteket küld az identitásszolgáltatóknak, a wsignoutcleanup1.0-üzeneteket pedig a függő entitásalkalmazásoknak.

További információ: Kódminta: ASP.NET MVC 4 összevont kijelentkezéssel és passzív hitelesítéssel ASP.NET WIF-ben.

Az ACS 1.0 támogatásának megszüntetése

A Access Control Service 1.0 támogatása ebben a kiadásban megszűnik, beleértve a Access Control Service 1.0-ról Access Control Service 2.0-ra való migrálás támogatását is.

Navigálás Access Control névterekhez az új Azure felügyeleti portálon

Az új Azure Felügyeleti portál (https://manage.WindowsAzure.com) tartalmaz egy útvonalat a jól ismert ACS felügyeleti portálhoz, ahol Access Control névtereket hozhat létre és kezelhet.

Az ACS felügyeleti portálra való navigáláshoz:

1. Lépjen a Microsoft Azure felügyeleti portálra (https://manage.WindowsAzure.com), jelentkezzen be, majd kattintson az Active Directoryra. (Hibaelhárítási tipp: Az "Active Directory" elem hiányzik vagy nem érhető el)

2. Kattintson egy Access Control névtérre, majd a Kezelés gombra.

Access Control névtér létrehozásához kattintson az Új, az App Services, a Access Control, majd a Gyors létrehozás elemre. (Vagy kattintson Access Control Névterek elemre, mielőtt az Új gombra kattint.)

Ha segítségre van szüksége az ACS felügyeleti feladataival kapcsolatban a Microsoft Azure felügyeleti portálon, kattintson az Active Directory, majd a Súgó (?) elemre. (Vagy kattintson az Active Directory, Access Control Névterek, majd a Súgó elemre.)

Navigálás a service bus Access Control névteréhez

Amikor létrehoz egy Service Bus névteret a portálon, a portál automatikusan létrehoz egy Access Control névteret a service bus számára.

A service bus Access Control-névterének konfigurálása és kezelése:

1. Jelentkezzen be az Azure felügyeleti portálra.

2. Kattintson a Service Bus elemre, majd válasszon ki egy service busot.

3. Kattintson a Hozzáférési kulcs , majd az ACS felügyeleti portál megnyitása elemre.

Annak ellenőrzéséhez, hogy a Access Control névtér társítva van-e a service bushoz, tekintse meg a Szolgáltatásnévtér mezőt a Access Control Szolgáltatás lap tetején. A névtér neve a Service Bus-névből áll egy "-sb" utótaggal.

További információ: How to: Manage the Access Control Namespace for a Service Bus.

Az ACS felügyeleti portál fejlesztései WS-Federation identitásszolgáltatói kulcsok megtekintéséhez és jelszavak elrejtéséhez

Ez a kiadás az ACS 2.0 felügyeleti portál tanúsítványainak, kulcsainak és jelszavának megtekintéséhez és használatához kapcsolódó fejlesztéseket tartalmaz:

• Az aláíró tanúsítványok most már láthatók az WS-Federation Identitásszolgáltató szerkesztése szakaszban – Korábban az identitásszolgáltatótól kibocsátott jogkivonatok aláírásának ellenőrzésére használt WS-Federation metaadatokból importált tanúsítványok nem voltak láthatók az ACS felügyeleti portálján. Az WS-Federation Identitásszolgáltató szerkesztése szakasz mostantól információkat jelenít meg az importált tanúsítványokról, beleértve azok lejárati dátumát és állapotát. Ezek a tanúsítványok mostantól frissíthetők egy új "Adatok újraimportálása WS-Federation metaadat URL-címéről mentéskor" jelölőnégyzet használatával.

• A jelszavak és a szimmetrikus aláírókulcsok alapértelmezés szerint rejtve vannak – A jelszavak és a szimmetrikus kulcsok véletlen felfedésének megakadályozása érdekében ezek az értékek alapértelmezés szerint rejtve vannak a portál szerkesztési képernyőin. Ha szándékosan meg szeretné jeleníteni egy jelszó vagy szimmetrikus kulcs értékét (például egy alkalmazásba való másoláshoz), a "Jelszó megjelenítése" vagy a "Kulcs megjelenítése" gombot most le kell nyomni.

Címtárbérlők összevonásának képessége Access Control névtérrel

Azure Active Directory bérlők mostantól identitásszolgáltatókként is használhatók Access Control névterekben. Ez számos forgatókönyvet tesz lehetővé, például lehetővé teszi a webalkalmazás számára, hogy a címtár-bérlőktől származó szervezeti identitásokat és a közösségi szolgáltatóktól (például Facebook, Google, Yahoo!, Microsoft-fiókok vagy bármely más OpenID-szolgáltató) származó szervezeti identitásokat is elfogadjon. Ebben a bejegyzésben részletes útmutatást talál a forgatókönyv implementálásához: Azure Active Directory-bérlő kiépítése identitásszolgáltatóként egy ACS-névtérben.

SAML 2.0 protokolltámogatás függő entitások alkalmazásához (fejlesztői előzetes verzió)

Az ACS mostantól támogatja az SAML 2.0 protokollt a jogkivonatok függő entitások számára történő kiadásához. Az SAML 2.0 protokoll támogatása fejlesztői előzetes verzióként jelent meg, ami azt jelenti, hogy az SAML 2.0 protokoll implementációjának részletei továbbra is változhatnak. További részletekért lásd:Fejlesztői előzetes verzió: SAMLProtocol.

Ismert problémák

A 2012. decemberi Microsoft Azure Active Directory Access Control (más néven Access Control Service vagy ACS) frissítésben a következő ismert problémákat észleltük:

Az Azure Co-Administrators mostantól képes kezelni Access Control névtereket. A meglévő társadminisztrátorok meglévő Access Control névterekre való propagálásához azonban műveletre van szükség.

A 2012. novemberi frissítés előtt megoldottuk azt a problémát, amely miatt alapértelmezés szerint csak az elsődleges Azure-szolgáltatásadminisztrátor kezelheti az előfizetésben létrehozott Access Control névtereket. Ha egy Azure-társadminisztrátor egy Access Control névtérhez próbál hozzáférni az ACS felügyeleti portáljához, az alábbi ACS-hibakódok valamelyikét kapja:

• ACS50000: Hiba történt egy jogkivonat kiállítása közben.

• ACS60000: Hiba történt az "uri:WindowsLiveID" kiállítót használó függő entitás szabályainak feldolgozása közben

• ACS60001: A szabályok feldolgozása során nem jöttek létre kimeneti jogcímek.

Ez a probléma megoldódott az Azure-szolgáltatás rendszergazdája vagy társadminisztrátora által létrehozott új Access Control-névterek esetében. A javítás előtt létező névtérrel rendelkező ügyfeleknek azonban végre kell hajtaniuk a következő kerülő megoldást ahhoz, hogy a társadminisztrátori adatok propagálva lesznek ezekre a névterekre:

1. Jelentkezzen be a Azure Portal (https://windows.azure.com/) szolgáltatásadminisztrátori vagy fiókadminisztrátori hitelesítő adatokkal.

2. Távolítsa el és adja hozzá újra a társadminisztrátort az Azure-előfizetések Co-Administrators hozzáadása és eltávolítása című témakör útmutatása alapján (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

3. Jelentkezzen ki, és jelentkezzen be a Azure Portal a társadminisztrátori hitelesítő adatokkal. Ezután kezelheti a Access Control névtereket.

2012. szeptemberi frissítés kibocsátási megjegyzései

2012 szeptemberében Microsoft Azure Active Directory Access Control (más néven Access Control Service vagy ACS) kapott egy frissítést, amely a következő módosításokat tartalmazta:

Az ACS által kibocsátott WS-Federation metaadatokban közzétett entityID mostantól következetesen kisbetűs.

Az Access Control névterek által közzétett WS-Federation metaadatok "entityID" attribútuma mostantól mindig kisbetűs. A korábbi kiadásokban a névtér Azure Portal való létrehozásakor beírt betűes kisbetűs esetet használta. Az "entityID" attribútum azonosítja a Access Control névteret a függő entitásalkalmazások számára, az alábbiakban pedig egy példa látható az attribútumra:

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

Ez a módosítás olyan lehetséges jogkivonat-érvényesítési problémák megoldásához szükséges, amelyekben az ACS által kibocsátott (mindig kisbetűs) jogkivonatban lévő Access Control névtér betűes esete nem egyezik meg a függő entitás által importált Access Control névtér betűs esetével. Az Windows Identity Foundationt használó függő entitásokat nem érintik a kis- és nagybetűk bizalmassági problémái.

Az ACS-be feltöltött X.509-tanúsítványok mostantól 4096 bites nyilvánoskulcs-méretkorlátozással rendelkeznek

Az ACS felügyeleti portálon vagy felügyeleti szolgáltatáson keresztül egy Access Control névtérbe feltöltött összes X.509-tanúsítványnak 4096 bites nyilvános kulcsméretűnek kell lennie. Ide tartoznak a jogkivonat-aláíráshoz, a jogkivonat-titkosításhoz és a jogkivonat visszafejtéséhez használt tanúsítványok.

A Windows a tanúsítvány nyilvános kulcsának mérete a tanúsítvány megnyitásával ellenőrizhető (. CER) fájl, válassza a "Részletek" lapot, és ellenőrizze a "Nyilvános kulcs" mező értékét. A biztonságos sha256RSA aláírási algoritmust használó tanúsítványok 2048 bites nyilvános kulccsal rendelkeznek.

A 4096 bitnél nagyobb kulcsméretű meglévő tanúsítványok továbbra is működni fognak az ACS-vel, de ezek a tanúsítványok csak akkor menthetők újra az ACS-ben, ha megfelelő tanúsítványra cserélik őket.

Kisebb módosítás az "elsődleges kulcs" kiválasztási algoritmusra, amelyet akkor használnak, ha az ACS X.509-tanúsítvánnyal ír alá jogkivonatot

Az ACS felügyeleti portálon és a felügyeleti szolgáltatásban található egy "Elsődlegesvé tétele" mező a jogkivonat-aláíró tanúsítványokhoz, amelyek kiválasztása esetén az ACS-nek jogkivonatokat kell aláírnia ezzel a tanúsítvánnyal. Ebben a kiadásban, ha egyetlen konfigurált jogkivonat-aláíró tanúsítványban sincs bejelölve az "Elsődlegesvé tétele" mező, a Access Control névtér a jogkivonat aláírásához a legkorábbi érvényes kezdő dátummal rendelkező meglévő nem elsődleges jogkivonat-aláíró tanúsítványt fogja használni. Az ACS továbbra sem ír alá jogkivonatokat nem elsődleges jogkivonat-aláíró tanúsítvánnyal, ha létezik elsődleges tanúsítvány, de érvénytelen vagy lejárt.

JWT bétaverzió: Változás az aláírási viselkedésben, ha globális névtértanúsítványt vagy -kulcsot használ JWT-token aláírásához

Amikor 2012 júniusában megjelent a JSON Web Token (JWT) formátum bétaverziójának támogatása, az ACS a következő sorrendet használta annak meghatározásához, hogy melyik kulcsot kell használni az egyes függő entitások alkalmazásaihoz kiadott JWT-tokenek aláírásához:

• A függő entitáshoz rendelt szimmetrikus aláírókulcs, ha elérhető

• A függő entitáshoz rendelt X.509 aláíró tanúsítvány, ha elérhető

• A Access Control névtérhez rendelt szimmetrikus aláírókulcs

• A Access Control névtérhez rendelt X.509 aláíró tanúsítvány

A jelen kiadástól a névtér egészére kiterjedő szimmetrikus kulcsok már nem támogatottak a JWT-tokenek aláírásához. Az alábbiakban a JWT-jogkivonatok aláírásának új sorrendje látható:

• A függő entitáshoz rendelt szimmetrikus aláírókulcs, ha elérhető

• A függő entitáshoz rendelt X.509 aláíró tanúsítvány, ha elérhető

• A Access Control névtérhez rendelt X.509 aláíró tanúsítvány

2012. júniusi frissítés kibocsátási megjegyzései

2012 júniusában az ACS a következő új funkciót tartalmazó frissítést kapott:

A JWT formátum már elérhető függő entitásos alkalmazásokhoz (bétaverzió)

Ez a frissítés támogatja a JSON Web Token (JWT) BÉTA-formátumát az ACS-ben. A JWT egy egyszerűsített, JSON-kódolású jogkivonat-formátum, amely X.509-tanúsítvánnyal vagy szimmetrikus kulccsal írható alá, és az ACS a függő entitásalkalmazások számára az alábbi protokollok bármelyikén kibocsáthatja:

• OAuth 2.0

• WS-Federation

• WS-Trust

A JWT-jogkivonat formátuma mostantól választható lehetőség az ACS felügyeleti portál Függő entitásalkalmazások szakaszában, és az ACS felügyeleti szolgáltatáson keresztül is konfigurálható.

A JWT-jogkivonat formátumával kapcsolatos további információkért tekintse meg a JSON webes jogkivonat specifikációját. A JWT-jogkivonatokat tartalmazó ACS-kódminták egy későbbi időpontban jelennek meg.

Fontos

A JWT-támogatás "bétaverzióként" van megjelölve az ACS-ben, ami azt jelenti, hogy a JWT implementációjának minden részlete változhat. A fejlesztőknek javasoljuk, hogy kísérletezzen ezzel a tokenformátummal. A JWT-t azonban nem szabad éles szolgáltatásokban használni, mivel a viselkedés értesítés nélkül változhat.

2012. májusi frissítés kibocsátási megjegyzései

2012 májusának elején az ACS a következő módosítást tartalmazó frissítést kapott:

A felügyeleti szolgáltatáson keresztül közzétett entitásazonosító-tulajdonságok módosítása

Az ACS felügyeleti szolgáltatás jelenleg minden általa támogatott entitástípushoz elérhetővé tesz egy ID tulajdonságot, az ACS Management Service API-referenciájában leírtak szerint. Ezeket az azonosítótulajdonságokat az ACS automatikusan beállítja és kezeli.

Ebben a szolgáltatásfrissítésben az ACS egy másik adatbázissémába lesz migrálva, és ennek eredményeként a felügyeleti szolgáltatáson keresztül közzétett azonosítók minden entitástípus esetében megváltoznak.

Nem gyakori, és általában nem ajánlott, hogy az alkalmazások tároljanak vagy vegyenek fel egy rögzített függőséget ezekből az azonosítókból, hogy bizonyos entitásokat lekérdezhessenek a felügyeleti szolgáltatáson keresztül. Ehelyett javasoljuk, hogy a RelyingParty, a ServiceIdentity, a RuleGroup és a Issuer entitástípusokat a Name tulajdonság használatával kérdezze le, más entitástípusokat pedig egy szülőentitás-azonosítóval (például szabály esetén ruleGroupId, identitásszolgáltatók esetében pedig Kiállítóazonosító) kell lekérdezni.

Az adatbázis-rendezés módosítása a szabályok feldolgozásához

A nemzetközi nyelvek támogatásának bővítése és a biztonság javítása érdekében az ACS ezen kiadása frissíti a mögöttes SQL Database-rendezést, amely a SQL_Latin1_General_CP1_CI_AS és a Latin1_General_100_BIN2 bemeneti jogcímeinek összehasonlítására szolgál. Ez a módosítás lehetővé teszi, hogy az ACS további karakterkészleteket és karakterkészlet-kombinációkat is támogatjon. A több karakterkészlettel rendelkező, SQL_Latin1_General_CP1_CI_AS által nem támogatott karakterláncokat tartalmazó bemeneti jogcímekre támaszkodó alkalmazások eltérő vagy további jogcímeket láthatnak az új rendezés eredményeként. Azoknak az ügyfeleknek, akik ki szeretnék használni ezt az új képességet, javasoljuk, hogy ellenőrizze az alkalmazásaikat, hogy kompatibilisek-e az új SQL-rendezéssel.

2012. januári frissítés kibocsátási megjegyzései

2012. január 25-én az ACS 2.0 a következő módosításokat tartalmazó frissítést kapott:

• Sikertelen hitelesítési kérelmek ACS-hibaválaszainak módosítása

• Az OAuth 2.0 hibakódjainak módosítása sikertelen hitelesítési kérelmek esetén

Sikertelen hitelesítési kérelmek ACS-hibaválaszainak módosítása

Az előző kiadásban az ACS különböző hibakódokkal válaszolt, amikor egy ügyfél nem létező kiállítóval (hibakód: ACS50026) vagy helytelen hitelesítő adatokkal (hibakód: ACS50006) hitelesített. Ezeket a hibakódokat korábban akkor adták ki, amikor egy ügyfél érvénytelen szolgáltatásidentitás-névvel vagy érvénytelen identitásszolgáltatótól származó SWT- vagy SAML-jogkivonattal próbált hitelesíteni.

Az ACS az ACS50008, az ACS50009 vagy az ACS50012 hibakódot adja vissza a sikertelen hitelesítéshez SWT, SAML és felhasználónév/jelszó esetén. Részletekért tekintse meg az alábbi táblázatot:

Hitelesítési válasz	Előtte	Utána
Nem létező kiállító	ACS50026 IssuerNotFound	ACS50008 InvalidSwt, ACS50009 InvalidSaml, VAGY ACS50012 AuthenticationFailed
Helytelen hitelesítő adatok	ACS50006 InvalidSignature

Az OAuth 2.0 hibakódjainak módosítása sikertelen hitelesítési kérelmek esetén

Az előző kiadásban az ACS különböző OAuth 2.0 hibakódokkal válaszolt, amikor egy ügyfél nem létező kiállítóval (invalid_client) vagy helytelen hitelesítő adatokkal (invalid_grant) hitelesített. Ez a viselkedés is frissült, és az ACS invalid_request ad vissza, ha az OAuth 2.0-kérés helytelen formátumú, invalid_client, ha az ügyfél nem hitelesít, vagy a hitelesítéshez megadott helyességi feltétel helytelen vagy érvénytelen, és invalid_grant, hogy az engedélyezési kód helytelen vagy érvénytelen- e. Részletekért tekintse meg az alábbi táblázatot:

Hitelesítési válasz	Példák	Előtte	Utána
Nem létező kiállító		invalid_client	invalid_client
Helytelen hitelesítő adatok	Az SWT helytelen kulccsal van aláírva. Az ügyfél-azonosító és a hitelesítő adatok megegyeznek az ACS-ben konfiguráltakkal.	invalid_grant
A hitelesítés sikertelen	A célközönség URI-ellenőrzése nem sikerült. A tanúsítvány érvényesítése nem sikerült. A szolgáltatásidentitásból származó helyességi feltétel önkibocsátott jogcímeket tartalmaz.	invalid_grant
Helytelen formátumú helyességi feltétel	Hiányzik az aláírás az SWT-ből. Az SAML helyességi állapota érvénytelen XML.	invalid_request
Hibásan formázott engedélyezési kód		invalid_grant	invalid_grant
Érvénytelen engedélyezési kód		invalid_grant
Hibás formátumú OAuth2-kérelem		invalid_request	invalid_request

2011. júliusi frissítés kibocsátási megjegyzései

Az ACS 2.0 2011. júliusi frissítésének kibocsátási megjegyzései a következő elemeket tartalmazzák:

• Előfeltételek

• Új funkciók

• Módosítások

• Ismert problémák

• Ismert problémák

Előfeltételek

Minden Access Control névtér automatikusan megkapja a 2011. júliusi frissítést. Ez a frissítés nem tartalmaz módosításokat az új vagy meglévő ügyfelek ACS-előfeltételeiben. Az ACS aktuális előfeltételeivel kapcsolatos további információkért lásd az ACS előfeltételeit.

Új funkciók

Az ACS 2011. júliusi frissítése a következő új funkciókat tartalmazza:

1. A szabályok mostantól legfeljebb két bemeneti jogcímet támogatnak

Az ACS szabálymotor mostantól egy új szabálytípust támogat, amely legfeljebb két bemeneti jogcím konfigurálását teszi lehetővé egyetlen bemeneti jogcím helyett. A két bemeneti jogcímmel rendelkező szabályokkal csökkenthető az összetett felhasználói engedélyezési funkciók végrehajtásához szükséges szabályok teljes száma.

Az ACS felügyeleti portálon egy második bemeneti jogcím is megadható egy új szabályban a második bemeneti jogcím hozzáadása gombra kattintva a szabályszerkesztőben. A felügyeleti szolgáltatásban a két bemeneti jogcímmel rendelkező szabályok a ConditionalRule entitástípussal konfigurálhatók. Az egy bemeneti jogcímmel rendelkező szabályok továbbra is a Szabály entitástípussal vannak konfigurálva a visszamenőleges kompatibilitás érdekében.

A két bemeneti jogcímet tartalmazó szabályokkal kapcsolatos további információkért lásd: Szabálycsoportok és szabályok.

2. Honosítás tizenegy nyelven

Az ACS felügyeleti portálja és a függő entitások alkalmazásainak ACS által üzemeltetett bejelentkezési oldala mostantól tizenegy írott nyelven támogatja a honosítást, beleértve az angol, a francia, a német, az olasz, a japán, a koreai, az orosz, a spanyol, a portugál (Brazília), az egyszerűsített kínai és a hagyományos kínai nyelvet. Elérhető egy "angol (nemzetközi)" lehetőség is, amely alternatív dátumformátumot használ a kulcsok érvényes/lejárati dátumainak beállításához és megjelenítéséhez. Az ezekhez a felhasználói felületekhez megjelenített írott nyelv az alábbi három módszer egyikével módosítható:

• Nyelvválasztó – Az ACS felügyeleti portálon a megjelenített nyelv azonnal módosítható a portál jobb felső sarkában megjelenő új nyelvválasztó menü használatával.

• URL – Az ACS felügyeleti portálon megjelenő nyelv módosítható úgy, hogy hozzáad egy "lang" paramétert a kérelem URL-címének végéhez. A paraméter jogi értékei a támogatott nyelvnek megfelelő ISO 639-1/3166 nyelvi kódok. Ilyen értékek például az en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn és zh-tw. Az alábbiakban látható egy példa az ACS felügyeleti portál URL-címére, amely a megjelenített nyelvet francia nyelvre állítja be:

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

• Webböngésző-beállítások – Ha a "lang" URL-paramétert vagy nyelvválasztót soha nem használták nyelvi beállítások megadására, akkor az ACS felügyeleti portál és az ACS által üzemeltetett bejelentkezési lapok határozzák meg az alapértelmezett megjelenítendő nyelvet a webböngésző beállításaiban megadott nyelvi beállítások alapján.

Módosítások

A következő jelentős szolgáltatásviselkedési változások jelennek meg ebben a kiadásban:

1. A kódolás mostantól UTF-8 az összes OAuth 2.0-válaszhoz

Az ACS kezdeti kiadásában az OAuth 2.0 végpontról érkező összes HTTP-válasz karakterkódolása US-ASCII volt. A 2011. júliusi frissítésben az összes HTTP-válasz karakterkódolása mostantól UTF-8-ra van állítva a kiterjesztett karakterkészletek támogatásához.

Ismert problémák

A kiadás ismert problémája a következő:

A Szabályszerkesztő nem tudja megjeleníteni az identitásszolgáltatókhoz nem társított egyéni kiállítókat

Az ACS felügyeleti portál szabályszerkesztője jelenleg csak az identitásszolgáltatóhoz vagy az ACS-hez társított jogcímkiállítókat tudja megjeleníteni. Ha olyan szabály van betöltve, amely egy olyan kiállítóra hivatkozik, amely egyiknek sem felel meg, akkor a következő hiba jelenik meg:

• ACS80001: Ez a szabály olyan jogcímkibocsátó-típus használatára van konfigurálva, amelyet a felügyeleti portál nem támogat. A szabály megtekintéséhez és szerkesztéséhez használja a felügyeleti szolgáltatást.

Két támogatott forgatókönyv létezik, amelyekben a kiállítók a társított identitásszolgáltató nélkül létezhetnek az ACS-ben:

• OAuth 2.0-delegálási forgatókönyv esetén a rendszer létrehoz egy kiállítói rekordot a Access Control névtérben az ACS felügyeleti szolgáltatás használatával, és ez a kibocsátó nem rendelkezik társított identitásszolgáltatóval.

• Ha egy kiállító azért jön létre, hogy jogcímeket érvényesítsen egy jogkivonat-kérelemben az OAuth WRAP protokollon keresztül, miközben azonos nevű szolgáltatásidentitást használ az ACS-hitelesítéshez.

Kvóták

A jelen kiadástól az ACS nem korlátozza az identitásszolgáltatók, függő entitások alkalmazásai, szabálycsoportok, szabályok, szolgáltatásidentitások, jogcímtípusok, delegálási rekordok, kiállítók, kulcsok és címek számát, amelyek létrehozhatók egy adott Access Control névtérhez.

Szolgáltatáskorlátozások

A szolgáltatáskorlátozásokról további információt az ACS szolgáltatáskorlátozásait ismertető cikkben talál.