Windows Azure újdonságok – Identitás-kezelés a felhőben III.

Ahogy korábban olvasóinknak ígértük, igyekszünk folyamatosan frissíteni a blogot a könyv megjelenése után bejelentett Azure frissítésekkel és új szolgáltatásokkal, amik bizonyos időközönként bekerülnek majd a könyv elektronikus kiadásaiba is.Sok újdonsággal bővültek az Azure autentikációs szolgáltatásai is, így egy több részes blogbejegyzés sorozatban mutatjuk be az újdonságokat:

Az előző bejegyzések:

Access Control (ACS)

Röviden összefoglalva az ACS-sel foglalkozó fejezetrész tartalmát, a federált autentikáció alapgondolata az, hogy a hatékony felhasználókezelés érdekében megszüntetjük a szolgáltatásaink és a konkrét autentikációs logika közti szoros csatolást.  A federált hitelesítést alkalmazva az alkalmazásaink felelősségköréből kiszervezzük a felhasználók autentikációjának feladatát. Adataikat, jelszavaikat nem az alkalmazásunk saját adatbázisában tároljuk – ezt a feladatot megbízható felhasználó-azonosítást végző szolgáltatókra, ún. Identity Provider-ekre (IDP)  bízzuk. Az IDP-k feladata, hogy a felhasználói autentikáció sikeressége esetén kiállítson egy security tokennek nevezett adatstruktúrát, amit visszakapva az alkalmazásunk értesül a sikeres autentikáció tényéről és belőlük különböző adatokhoz (claim-ekhez) jut. Ilyen adat lehet például a felhasználó neve, csoport-információja stb.

A federált hitelesítés modellje még egy további lépést tesz: nem csak hogy külső IDP-kre bízza a felhasználók azonosítását, ezen kívül a modellünk kiegészül még egy szereplővel: a Federation Provider-rel (FP). Innentől kezdve alkalmazásaink és az IDP-k nem közvetlenül kommunikálnak egymással.  A köztük elhelyezkedő FP szolgáltatás közvetítő szerepet tölt be a security token-ek továbbításában. Az FP feladata, hogy az IDP-től kapott, sikeres bejelentkezést reprezentáló, security token-eket olyan formátumra transzformálja, amit az alkalmazásunk kövzvetlenül, további előfeldolgozás nélkül használni tud. Ezzel az IDP-k oldalán bekövetkező változásokat egyszerűen követő, egyetlen token formátumot ismerő alkalmazásokat tudunk létrehozni.

Az Azure-ban a Federation Provider szolgáltatás  az Access Control névre hallgat. Működését részletesen megismerheted a könyv 12. fejezetéből. Ha átolvasod a fejezetet, láthatod, hogy használatával fejlesztőként gyors és hatékony eszközöket használva megoldhatjuk webalkalmazásaink autentikációs problémáit. A fejezet megírása óta eltelt időben az ott bemutatott módszerek továbbra is érvényesek a .NET 3.5 és 4 alá fejlesztett alkalmazások esetében. Ha viszont .NET 4.5-re fejlesztünk, akkor a könyvben megismert módszerekhez helyett használjuk inkább az előző bekezdésben bemutott Identity and Access Tool-t. Maga az ACS működése semmit sem változott, csak a megszokotthoz képest egy új grafikus felületen kell felkonfigurálnunk a Relying Party alkalmazásunkat az ACS használatára. Nézzük meg frissen létrehozott .NET 4.5-ös webalkalmazás példáján, hogy hogyan.

Hozz létre egy új Web Application-t. Tetszés szerint választhatsz a Web Forms és az MVC template-ek közül. A létrejövő projekten jobb gombbal kattintva a context menüből válaszd ki az “Identity and Access…” parancsot. A felugró ablakban kattints a harmadik, “Use Windows Azure ACS” rádiógombra.

4.ábra

4.ábra

Ahogy a varázsló írja, válaszd ki az ACS névteredet, amelyhez konfigurálni  szeretnéd a Relying Party (RP) alkalmazásodat. Ehhez kattints a Configure linkre.

5

5.ábra

A felugró ablakban írd be az ACS névtered nevét és a hozzá tartozó management key-t. A management key-t az ACS Managament Portálról tudod kinyerni. Az Azure Mgmt. Portálon kattints az ACS névtered kiválasztása után a bal alsó vízszintes menüben a Manage gombra. Ezzel az ACS Management Portálra kerülsz. Itt a bal oldali függőleges menüben válaszd a Management Service menüpontot. A megjelenő táblázatból válaszd ki a ManagementClient nevű alapértelmezett service account-ot, majd a kilistázott credential-jei közül kattints a Symmetric Key-re.

6.ábra

6.ábra

Kattints a “Show Key” gombra és másold át a megjlenő kulcsot az Identity and Access Tool-ba.

Ezt követően a 7. ábrán látható módon válaszd ki, melyik IDP-kben bízzon meg az alkalmazásod – alapértelmezetten csak az itt még Live ID-ként szereplő Microsoft Account van hozzáadva a megbízható IDP-k listájához. További IDP-ket az ACS Managament Portal-on tudsz hozzáadni (ld. könyv fejezet). Utolsó lépésként állítsd be a Realm URI-t valamint a Return URL-t (ez utóbbira fogja továbbítani az ACS a tokeneket). Az OK gombra kattintva az Identity and Access Tool elvégzi a web.config módosításait. Ezekről szintén a könyvben olvashatsz részletesebben.

7.ábra

7.ábra

Egy kisebb újdonság a könyvben bemutatott Federation Utility Wizard-os megoldáshoz képest, hogy az Identity and Access Tool már a ValidatingIssuerNameRegistry (VINR) osztályt használja az alkalmazásod számára megbízható token-kibocsátók konfigurációjához.  Ezzel az alkalamazás részletesebben le tudja írni, hogy milyen forrásból származó security tokeneket tekint hitelesnek. A korábbi Federation Utility eszköz még a ConfigurationBasedIssuerNameRegistry-vel (CBINR) írta le ezt a viselkedést. A két módszer közt az a különbség, hogy a VINR-rel meg tudjuk követelni, hogy a kapott tokenek-ben ne csak az őket alíró kibocsátó szolgáltatás kulcsának thumbprint-je egyezzen a token hitelesnek tekintéséhez. Hanem szükség van arra is, hogy a kapott tokenben a  kibocsátó neve a <validIssuers> tag-ben meghatározott legyen. Ellenkező esetben, ha csak a thumbprint egyezik és a kibocsátó neve nem, a token-t elutasítja az alkalmazásunk.

Kapcsolódó részlet a web.config file-ból:

<issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
<authority name="https://azurebookdemo.accesscontrol.windows.net/">
<keys>
<add thumbprint="19D335...." />
</keys>
<validIssuers>
<add name="https://azurebookdemo.accesscontrol.windows.net/" />
</validIssuers>
</authority>
</issuerNameRegistry>

Erre a részletesebb konfigurációs lehetőségre az egyre bonyolultabbá váló, több kulcsot, több ügyfelet kiszolgáló STS-ek miatt van szükség.

Kellemes hétvégét mindenkinek, hétfőn folytatjuk!

Ezeket az újdonságokat Te is kipróbálhatod! Regisztrálj az ingyenes, 90 napos Azure előfizetésre!

One thought on “Windows Azure újdonságok – Identitás-kezelés a felhőben III.

  1. Visszajelzés: Windows Azure újdonságok – Identitás-kezelés a felhőben V. | Felhők között

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s