ADFS beállítása felhőben 13_A osztály

Active Directory federált hitelesítés a felhőben lépésről-lépésre

Elkészítése nem egyszerű feladat. A nagyközönségnek szánt webalkalmazásokban nagyon jó hitelesítési megoldás az ASP.NETMembership. Céges környezetben viszont sokkal profibb a már meglévő architektúrát használni. Ha az alkalmazásunk a céges AD-val szemben hitelesít, akkor a felhasználók jogait csak egy helyen kell menedzselni, és bejelentkezéshez sem kell még egy név-jelszó párost megjegyezni. Leírásomban egy erre képes Windows Azure felhő-alkalmazás megírásán megyünk végig.
Az Active Directory kifejezés hallatára valószínűleg erőforrás-igényes, fejlesztői környezetben ritkán megtalálható Windows Serverek rémlenek fel. Ettől nem kell tartani: a lentieket úgy írtam meg, hogy egyetlen fizikai gép igénybevételével mindent ki lehessen próbálni. Paradox módon emiatt kicsit még bonyolultabb is lett a folyamat, úgyhogy aki ezt a leírást végigviszi, annak az éles telepítés sem fog nagy meglepetéseket okozni.

Mi a federált hitelesítés?

Példánkban az alkalmazás és a hitelesítést végző szerver két logikailag teljesen különálló helyen lesz (szemben azzal, amikor az autentikációt maga az alkalmazás végzi). Ezt a hitelesítési módot federált hitelesítésnek hívják. Működésére remek analógia a sörözés: ha belépünk egy kocsmába, és viszonylag fiatalos arcunk van, akkor hitelesítésre van szükségünk (igazolnunk kell nagykorúságunkat). Viszont a hitelesítést nem a kocsma saját “motorja” végzi (azaz nincs náluk egy óriási adatbázis az összes 18 évesnél idősebb magyar állampolgár adataival), hanem federálják azt a magyar államnak: elkérik a személyi igazolványunkat. Ezt a állam állította ki, és igazolja életkorunkat. A kocsma pedig megbízik a Magyar Államban, tehát elfogadja az általa kiállított igazolást, és vehetünk sört. Ugyanez szakkifejezésekkel leírva: alkalmazásunk szeretne azonosítani egy felhasználót. Ehhez nem a saját adatbázisából dolgozik, hanem elküldi a felhasználót egy hitelesítési szerverhez (esetünkben az Active Directory-hoz); ott megtörténik a bejelentkezés (konkrétan a felhasználó gépén felugrik a “név-jelszó” ablak), majd az Active Directory egy digitálisan aláírt tokent küld vissza alkalmazásunknak a felhasználó adataival. Mivel mi megbízunk a kérdéses Active Directory-ban, elfogadjuk majd a tokenen szereplő állításokat, és a felhasználót bejelentkezettnek tekintjük anélkül, hogy valaha is találkoztunk volna a hitelesítési adataival.

Teendőink

Az alkalmazásunk és az Active Directory közötti federált hitelesítést nagy vonalakban a következő módon fogjuk majd beállítani:

1. “Megágyazunk” a szerveren: Feltelepítjük és bekonfiguráljuk az Active Directoryt. (Ez lesz a leghosszadalmasabb feladat, az utána következők lényegesen könnyebbek és gyorsabbak lesznek majd.)
2. “Megágyazunk” a saját oldalunkon: Megírunk egy nagyon egyszerű demóalkalmazást.
3. Beállítjuk alkalmazásunkat, hogy megbízzon az AD-ben.
4. Beállítjuk az AD-t, hogy megbízzon az alkalmazásunkban.

1. A szerver előkészítése

1.1. A virtualizációs szoftver és a Windows Server

Szükségünk lesz egy Windows Serverre. Amint ígértem, a leírás egyetlen fizikai gépről szól, így a Server virtualizált lesz. Az operációs rendszer verziója igazából mindegy: Windows 2008 illetve 2008 R2 is megfelelő, valamint a Standard és az Enterprise változatok is működni fognak. A képernyőképek egy angol Windows Server 2008 R2 Enterprise változatról készültek.

A virtualizációs környezet gyakorlatilag bármilyen technológia lehet. Elsősorban a Microsoftos termékeket ajánlom, de ha valakinek 32 bites munkaállomása van, és ezen szeretne egy 64 bites Windows Server 2008 R2-t futtatni, akkor marad a VirtualBox nevű szoftver. Én ezt használtam. Maga a Windows Server pedig igény szerint beszerezhető: akinek van MSDN, TechNet, vagy MSDN:AA (egyetemisták figyelem!) előfizetése, az ott megtalálhatja, egyébként pedig letölthetők próbaverziók a Microsoft oldalairól.

Ha ezek megvannak, telepítsük fel a Windows Servert. A gép neve lényeges lesz; változtassuk meg valamilyen könnyen megjegyezhetőre, pl. adfsserver.

1.2. IP beállítások

Amint a bevezetőben említettem, az egygépes megoldás komplikáltabb, mint a éles, többgépes. Ennek oka az, hogy a használt technológiából eredően az általunk írt alkalmazásnak egy DNS névvel (pl. adfsserver.adfsdemo.local) kell hivatkoznia az általa megcélzott AD-re, nem elég az IP cím (pl. 192.168.120.2). Működő, fejlesztői célra használható DNS nevet pedig nehézkes szerezni, míg élesben rendelkezik ilyennel a megcélzott Active Directory. Helyi megoldásunk az lesz, hogy a feltelepített Windows Servert adjuk meg a fejlesztői gépünk egyik DNS szerverének, így létrehozhatunk bármilyen DNS nevet a szerveren, a mi gépünk fel fogja ismerni azt. (Más gépen beírva ugyanazt az URL-t természetesen nem fog működni.) A DNS tényleges beállítására később még visszatérünk.

A szervernek is hivatkoznia kell majd a mi alkalmazásunkra (hogy visszaküldhesse neki az elkészült tokent), de ehhez már elég lesz csak egy IP címet adni az alkalmazásunknak.

A fenti két kritérium miatt szükséges, hogy a saját gépünk, illetve a virtuális szerver tudjon egymással kommunikálni egy belső hálón keresztül. Ezt minden virtualizációs környezet támogatja. A demóban úgy állítottam be a fizikai és a virtuális Windows-okat, hogy a fejlesztői gépem IP címe 192.168.120.1, a virtuális szerver IP címe 192.168.120.2, és kölcsönösen tudják egymást pingelni. A használt virtuális környezetnek megfelelő módon végezzük el ezeket a beállításokat. (Ha a virtualizációs környezet nem támogat egyszerűbb megoldást, akkor a fizikai gépünkön adjunk hozzá egy Microsoft Loopback Adapter névre hallgató hálózati kártya-emulátort – a Windows beépítve tud ilyet -, a virtuális gépet pedig erre a kártyára kössük rá. Majd, a fizikai és a virtuális gépen is állítsuk be a megfelelő IP címeket erre a kártyára, és kis idő múlva létre fog jönni a hálózat. Ne felejtsük, hogy a Windows tűzfal alapértelmezésként megfogja a pingkéréseket, így tesztelés előtt ezt is konfigurálni kell!)

FIGYELEM: A továbbiakban saját Active Directoryt és DNS szervert fogunk telepíteni. Aki munkahelyi hálózaton van, győződjön meg róla, hogy a demószerver nem juthat ki arra, mert a vállalati IT haragos lesz, ha a demószerverünk elkezdi osztogatni az IP címeket!

1.3. Az IIS és az Active Directory telepítése

A Windows Server telepítése és az IP címek beállítása után után rakjuk fel a Web Server és az Active Directory Domain Services szerepköröket.

Kezdjük a Web Serverrel, amihez az összes lehetőséget válasszuk ki.

   

Utána jöhet az Active Directory. Először tegyük fel magát az Active Directory Domain Services szerepkört. Ez még ténylegesen nem csinál domain controllert a gépből, csak felmásolja az ehhez szükséges binárisokat.

   

Miután ezzel elkészültünk, következhet az AD tényleges beállítása. Ehhez parancssorból ki kell adnunk a dcpromo parancsot.

Egy domain létrehozása általában alapos tervezést igényel, de a mi demócéljainkra a legegyszerűbb beállítások is megfelelnek majd. Kövessük a képernyőképek beállításait.

Maradjunk a hagyományos telepítési módnál (nem kell az Advanced Mode), és hozzunk létre egy új erdőt (azaz a létrehozni kívánt domain teljesen új lesz, nem meglévőhöz csatoljuk hozzá).

 

A domain neve legyen adfsdemo.local (a gép teljes neve így adfsserver.adfsdemo.local lesz majd), és a domain “működési szintjének” válasszuk ki a legmagasabbat, a Windows Server 2008 R2-t.

 

Hagyjuk, hogy a varázsló feltelepítse a DNS Server funkciót is (a kapcsolódó figyelmeztetéssel ne törődjünk), és ne nyúljunk az alapértelmezett könyvtárakhoz.

  

Végül adjunk meg egy jelszót a helyreállítási üzemmód rendszergazdájának (nekünk nem lesz rá szükségünk, egy éles helyzetben az összeomlott domain helyreállításakor szükséges), majd indítsuk el a telepítést.

  

A gép újra fog indulni, ezúttal már jóval lassabban, mint eddig. A domain ezzel elkészült.

Vegyünk fel néhány demófelhasználót, akiket majd bejelentkeztetünk ide távolról. Ehhez az Active Directory Users and Computers nevű alkalmazásra lesz szükségünk, amit a Start menü Administrative Tools almenüjében találunk. Válasszuk ki a bal oldali listából az Users szervezeti egységet, és adjunk hozzá néhány felhasználót, valamilyen egyszerű jelszóval.

A felhasználó hozzáadásakor úgy állítsuk be, hogy jelszavát ne kelljen megváltoztatnia az első bejelentkezéskor, különben nem tudjuk majd megfelelően használni a demó során!

A domaint ezzel beállítottuk a virtuális gépen. Most el kell érnünk, hogy a fejlesztői gépen beírva az adfsdemo.local DNS nevet, a virtuális szerverhez jussunk  – azaz tudjuk is használni a létrehozott domaint. Ahogy korábban már említettem, ezt a virtuális kiszolgáló DNS szerverként alkalmazásával oldjuk meg. Azaz a publikus DNS szerverek helyett, amelyek nem ismerik a sehol be nem regisztrált fejlesztői domain-nevünket, a virtuális kiszolgálót magát használjuk DNS szerverként – a saját címét természetesen fel tudja majd oldani.

Látogassunk el ahhoz a hálózati adapterhez, amivel a fizikai gépen a virtuális szerverhez csatlakozunk, és állítsuk be, hogy DNS szerverként magát a virtuális szervert használja. Ez a használt virtuális környezettől függően más lesz, Loopback Adapter, VirtualBox Host-Only Network, vagy valamilyen hasonló névre hallgat majd.

Végül egy szörnyű lépés következik: a demó idejére húzzuk ki a hálózati kábelt és/vagy tiltsuk le a többi adaptert, hogy a gép bármilyen kérésnél csak ezen az adapteren (és ezen a DNS szerveren) keresztül kommunikáljon. Ha ezt nem tesszük meg, a fejlesztői gép nem mindig a saját DNS szerverünknél fog próbálkozni, és a viselkedése véletlenszerű lesz. Igen, ez sajnos azt jelenti, hogy ideiglenesen nem lesz internet. Élesben, ahol nem kell ilyen módon trükközni a DNS szerverekkel, erre természetesen nincs szükség.

Teszteljük az eredményt: látogassunk el a http://adfsdemo.local és a http://adfsserver.adfsdemo.local címekre. Ha minden jól megy (és a leírásban említett DNS- és gépnevet használtuk), meg fog jelenni az IIS7 kezdőképernyője, azaz sikeresen kapcsolódtunk a virtuális szerverhez a helyi DNS és az új domain használatával.

Az ADFS 2.0 telepítése

Elérkeztünk a szerver konfigurálásának utolsó lépéséhez: feltesszük az Active Directory-t kiegészítő Active Directory Federation Services 2.0 komponenst. A Windows Server már beépítve is tartalmaz egy ADFS nevű szerepkört; fontos, hogy nekünk nem ez kell, hanem ennek a 2.0-s verziója, amely külön tölthető le.

Szedjük le innen: http://technet.microsoft.com/en-us/evalcenter/ee476597.aspx (Ideiglenesen ehhez visszakapcsolhatjuk az internetet, de ne felejtsük el újra letiltani letöltés után. A letöltést a fejlesztői gépen végezzük el, és utána másoljuk át a virtuális gépre; ne zavarjunk bele a már beállított hálózatba.)

A telepítésnél gyakorlatilag minden beállítást változatlanul hagyhatunk. Az egyetlen nem megszokott kérdés az alábbi ablak lesz; itt válasszuk az (alapértelmezett) Federation Serverbeállítást. A beállítás arra kérdez rá, hogy az épp telepített gép maga lesz-e federációs szerver, vagy csak egy tűzfal mögött lévő másik federációs szerver elérésére használt proxyt akarunk-e létrehozni. Nekünk természetesen az első beállítás kell.

Telepítés után az ADFS menedzsment konzol magától beindul. (Ha nem tenné, az Administrative Tools alatt AD FS 2.0 Management néven megtalálható.)

Az Active Directory Domain Services-hez hasonlóan az ADFS telepítése és beállítása is két külön fázis. A telepítéssel elkészültünk, most beállítjuk a szervert. Ehhez kattintsunk a középtájon látható AD FS 2.0 Federation Server Configuration Wizard linkre.

Az első ablakban maradhatunk az alapértelmezett beállításnál: új szervert hozunk létre. A másodiknál válasszuk a Stand-alone federation server-t. Ha nagy terhelésre számítunk, akkor a federációs szervereket farmba is szervezhetjük; esetünkben elég lesz egyetlen szerver is.

   

A következő ablaknál egy SSL tanúsítványt kell kiválasztanunk, amely a szerver azonosítására szolgál majd. Az alapértelmezett beállítás valószínűleg nem lesz jó, mert az ADFS-nek olyan SSL tanúsítvány kell, ami egy DNS nevet tartalmaz (pl. adfsserver.adfsdemo.local); a számítógép telepítésekor viszont a domain még nem létezett, így az alapértelmezett SSL tanúsítvány egyszerűen csak a gép neve. Így tehát generálnunk kell egy saját SSL tanúsítványt. (Profi környezetben erre valószínűleg nem lesz szükség, mert a rendszergazda már gondoskodott erről, esetleg van is vásárolt, elismert tanúsítvány.)

Tanúsítvány generálására többféle módszer is létezik. Talán a legegyszerűbb módszer, ha az IIS-t használjuk erre a célra. Nyissuk meg az IIS kezelőt az inetmgr parancs kiadásával. Ha a bal oldali fában ráállunk a szerver nevére, akkor középen kiválaszthatjuk a Server Certificates elemet.

Nyissuk meg, és a jobb oldalt található Create Self-Signed Certificate parancs segítségével hozzunk létre egy új tanúsítványt mondjuk AdfsServerCert néven.

Ennek hatására az IIS legenerál egy SSL tanúsítványt. Ezt mi hoztuk létre, azaz mi “írtuk alá”, tehát ez egy “self-signed certificate”. Mi megbízunk benne, de rajtunk kívül más nem fogja elismerni, mert ilyen tanúsítványt bárki létrehozhat (tehát hiába van ráírva, hogy mondjuk a szuper-internetes-bank.hu állította ki, semmiféle hitelességet nem bizonyít). Céljainkra ez elegendő lesz, de éles környezetben tanúsítványt külső szolgáltatótól kell szerezni.

Visszatérve az ADFS konfigurációs varázslóhoz, kattintsunk a Back, aztán a Next gombra. A varázsló újra betölti a tanúsítványok listáját, így már kiválaszthatjuk a frissen létrehozott AdfsServerCert –et.

A további ablakokon már nincs több teendőnk, a varázsló bekonfigurálja az ADFS-t.

Teszteljük, hogy sikerült-e. Húzzuk ki ismét az internetet, hogy csak a belső DNS-en keresztül tudjunk kommunikálni, majd látogassunk el a https://adfsserver.adfsdemo.local/FederationMetadata/2007-06/federationmetadata.xmlcímre. Némi gondolkodás után egy tanúsítványhibával szembesülünk (a használt self-signed certificate miatt), majd ezen továbblépve egy XML fájlt kapunk vissza. Ez a fájl tartalmazza az ADFS használatához szükséges metainformációkat, ez alapján tudjuk majd bekonfigurálni az alkalmazásainkat.

Szerverünk ezzel elkészült. DNS név segítségével el tudjuk érni, tartalmaz egy működő Active Directory domaint, és képes kezelni a federált hitelesítési kéréseket. Most megírjuk az alkalmazásunkat, és beállítjuk az alkalmazás és a szerver közötti bizalmi viszonyt. Ígérem, ez már rövidebb lesz!

2. Az alkalmazás előkészítése

2.1. A Windows Identity Foundation telepítése

Alkalmazásunknak ismernie kell az ADFS megszólításához használható protokollokat, illetve értelmeznie kell a visszaérkező tokent. Ezeket a képességeket szerencsére nem nekünk kell megírni: a Windows Identity Foundation (WIF) nevű .NET Framework-komponens tartalmazza a federált hitelesítéshez szükséges osztályokat, nekünk csak telepítenünk kell ezt.

A WIF-nek két része van, a WIF Runtime, és a WIF SDK. Fejlesztéshez mindkettőre szükség van. Töltsük le és telepítsük őket! (És utána ne felejtsük el kihúzni az internetet.)

WIF Runtime: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=eb9c345f-e830-40b8-a5fe-ae7a864c4d76&displaylang=en

WIF SDK: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c148b2df-c7af-46bb-9162-2c9422208504&displaylang=en

2.2. Mit használjunk?

A Windows Azure Web Role-ok és az ASP.NET Web Application-ök közötti szinte teljes egyezés miatt az itt leírtak rögtön mindkettőre használhatók lesznek. A cikk ugyan felhőalkalmazásokról szól, mi viszont most mégis ASP.NET Web Applicationt fogunk írni. Amint korábban már többször is utaltam rá, az egygépes környezet több szempontból megnehezíti a dolgunkat; itt is ez szól közbe. A Windows Azure Compute Emulator (korábban Development Fabric) ugyanis úgy van megírva, hogy csak a localhost (127.0.0.1) IP-címre érkező kéréseket hajlandó fogadni. Az AD szervernek viszont mindenképpen vissza kell küldenie a tokent a webszerver (azaz a Compute Emulator) felé, amihez egy nem-localhost (esetünkben 192.168.120.1) IP címre kell adatokat küldenie. (Hiszen ha az AD az 127.0.0.1-re küld adatokat, akkor saját magára fog rátalálni, nem pedig a Compute Emulator-t futtató fizikai gépre.)

Így sajnos a Compute Emulatorral nem tudjuk megoldani a demót, ezért kénytelenek leszünk sima ASP.NET alkalmazást használni. Éles körülmények között ez a megkötés nem él; mivel a felhőben természetesen minden alkalmazás hívható kívülről, az itt leírtakat változtatás nélkül tudjuk majd felhőalkalmazásokhoz is használni.

2.3. A webalkalmazás megírása

Hozzunk létre egy új ASP.NET Empty Web Application projektet. (A “sima” Web Application projekt magával hozna számunkra felesleges állományokat is.) A projekt neve legyen AdfsClient.

A projekt alapértelmezésként teljesen üres lesz. Vegyünk fel bele egy új Web Form-ot Default.aspx néven. Majd, adjunk hozzá egy DLL referenciát a Microsoft.IdentityModel DLL-re. (Ha nem találjuk, ellenőrizzük a WIF helyes telepítését!)

Az alkalmazás kódja összesen annyi munkát végez, hogy ha van bejelentkezett felhasználó, akkor kiírja a kapott token részleteit.

A Default.aspx markupja legyen ez:

---

<%@ Page Language=”C#” AutoEventWireup=”true” CodeBehind=”Default.aspx.cs” Inherits=”AdfsClient.Default” %>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head runat=”server”>
<title>ADFS Demó</title>
</head>
<body>
<form id=”form1″ runat=”server”>
<div>
<h1>
ADFS Demó</h1>
<p>
Adataid:</p>
<asp:GridView ID=”claimsGridView” runat=”server” AutoGenerateColumns=”False”>
<Columns>
<asp:BoundField DataField=”ClaimType” HeaderText=”ClaimType” ReadOnly=”True” />
<asp:BoundField DataField=”Value” HeaderText=”Value” ReadOnly=”True” />
</Columns>
</asp:GridView>
</div>
</form>
</body>
</html>

---

A Default.aspx.cs kódja pedig ez:

---

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.IdentityModel.Claims;
using System.Threading;

namespace AdfsClient
{
public partial class Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
IClaimsIdentity claimsIdentity = ((IClaimsPrincipal)(Thread.CurrentPrincipal)).Identities.FirstOrDefault();
if (claimsIdentity != null)
{
claimsGridView.DataSource = claimsIdentity.Claims;
claimsGridView.DataBind();
}
}
}
}

---

Ezeken felül a web.config fájlban kell elvégeznünk egy módosítást. A weben gyakori támadási forma a cross-site scripting, amely során JavaScript-et visznek fel egy adatbázisba (pl. kommentként), majd amikor valaki ellátogat egy ezt megjelenítő oldalra, a gépén lefut a kérdéses JavaScript. Ez ellen az ASP.NET úgy védekezik, hogy a gyanús (HTML tag-szerű) kéréseket elutasítja. Az ADFS-től visszakapott token XML formátumú, így ez is erre a sorsra fog jutni, ha a validációs motort nem állítjuk át megfelelően.

Nem kell mást tennünk, mint a web.config-ba beszúrni egy újabb sort a <system.web> névtéren belülre:

<httpRuntime requestValidationMode=”2.0″/>

Ez visszaállítja a validációs motort az ASP.NET 2.0-nál megszokott formára, mely kevésbé paranoid, és átengedi a tokent. Ha élesben ennél kifinomultabb megoldásra van szükségünk, akkor írhatunk saját Request Validator-t is, amit teljesen testreszabhatunk.

A fejlesztéssel megvagyunk. Alkalmazásunkat kívülről is hozzáférhetővé kell tennünk, így az ASP.NET fejlesztői szerver (Cassini) nem lesz elégséges. Továbbá a biztonságos működés előfeltétele, hogy a tokeneket HTTPS fölött forgalmazzuk. Így beállítjuk a Visual Studiót, hogy futtatáskor az alkalmazásunkat rakja fel a helyi IIS-re, HTTPS fölé. (Ha fejlesztői gépünkön esetleg még nincs fent az IIS, akkor rakjuk fel; az Azure Tools telepítésekor felrakja, úgyhogy ez valószínűtlen.)

Látogassunk el a projekt tulajdonságai közé. Baloldalt válasszuk ki a Web fület, majd középen váltsunk az Use Local IIS Web server lehetőségre. URL-nek adjuk meg a https://localhost/AdfsClient URL-t. A Create Virtual Directory gomb egyelőre még nem fog működni, mert a helyi IIS-ünk valószínűleg nincs bekonfigurálva HTTPS használatára.

A HTTPS beállításához nyissuk meg a helyi IIS kezelőnket az inetmgr paranccsal. Kattintsunk jobb gombbal az alapértelmezett weboldalra, és válasszuk az Edit Bindings menüpontot.

Vegyünk fel egy új Binding-et, válasszuk ki a HTTPS lehetőséget, és jelöljünk ki egy szimpatikus tanúsítványt. Ha nincs megfelelő, akkor a korábban már látott módon generáljunk egyet.

Végül térjünk vissza a Visual Studióhoz és kattintsunk a Create Virtual Directory gombra. Most már működni fog. Futtassuk az alkalmazást, egyelőre semmit nem fog megjeleníteni (sőt, hibával le is fog állni), de látjuk majd, hogy a megfelelő URL-en fut.

Ezzel az alkalmazás elkészült. Természetesen ez egy triviális példa, de a kód könnyen átalakítható valamilyen éles célra is – pl. a claimsIdentity objektum tulajdonságait vizsgálva megállapíthatjuk, hogy van-e bejelentkezett felhasználó, milyen jogosultsági körei vannak stb.

A megírt alkalmazás egyelőre még működésképtelen, mert nincs tudomása a használandó ADFS szerverről. A következő lépésben a korábban már látott FederationMetadata.xml segítségével beállítjuk, hogy a telepített ADFS szervert használja.

3. Az alkalmazás beállítása a szerver igénybevételére

A WIF feltelepítésekor felkerült egy varázsló is, ami képes egy web.config fájlt beállítani egy federációs szerver használatára (az ADFS ilyen, de Live ID-t, Google Account-ot, Facebook-ot stb. is használhatunk az Azure Access Control Service segítségével). A Visual Studióban kattintsunk a projektünk nevére, majd válasszuk az Add STS Reference menüelemet. Ez nem mindig jelenik meg; ha nem látjuk, akkor a Start menüből indítsuk el a Windows Identity Foundation Federation Utility nevű alkalmazást.

A varázsló első oldalán meg kell adnunk az átalakítandó web.config fájlt és azt az URL-t, ahonnan alkalmazásunk futni fog majd. (Az URL azért szükséges, mert majd ez alapján azonosítja majd az AD szerver az általa ismert kliensalkalmazásokat.)

A web.config fájl elérési útját egyszerűen tallózzuk ki,  URL-nek pedig adjuk meg a https://192.168.120.1/AdfsClient/ címet (fontos a https, és a végső / is). Éles környezetben az alkalmazás végső URL-je kerül majd ide, pl. http://pelda.cloudapp.net/.

A következő oldalon adhatjuk meg a használni kívánt STS adatait. Erre a korábban már látott FederationMetadata.xml szolgál majd. Adjuk meg a lenti mezőben a https://adfsserver.adfsdemo.local/FederationMetadata/2007-06/federationmetadata.xml URL-t. Az alkalmazás figyelmeztetni fog bennünket, hogy a talált tanúsítvány nem megbízható, de erről természetesen tudunk.

A további oldalak beállításain már nem szükséges változtatnunk, haladjunk végig a varázslón. Ezzel alkalmazásunkat beállítottuk, hogy megnyitásakor jelentkeztesse be a felhasználókat az ADFS segítségével.

Próbáljuk ki, hogy működik-e! Futtatáskor két egymást követő tanúsítványhibát kapunk a saját magunk által gyártott tanúsítványok használata miatt. Az első a saját alkalmazásunkra vonatkozik. Miután továbblépünk rajta, az alkalmazás továbbirányít bennünket az ADFS szerverre, itt jön a második. Ha ezen is továbblépünk, akkor megjelenik a hitelesítő ablak.

Ide megadva egy AD-ban érvényes nevet és jelszót, hibaablakot kapunk. Ha ezt látjuk, akkor idáig jól végeztük a dolgunkat – a lenti hiba azt jelenti, hogy az alkalmazás sikeresen hitelesít az ADFS felé, de az ADFS még nem bízik az alkalmazásunkban (és természetesen egy ismeretlen helyről érkező kérést nem fog kiszolgálni, mert ez biztonsági rést jelentene).

Utolsó feladatunk tehát a szerver és a kliens közötti bizalmi kapcsolat második felének beállítása.

A szerver beállítása az alkalmazás kéréseinek elfogadására

Térjünk vissza a virtuális géphez. Legutóbb a konfigurációs varázslóval és az IIS-sel dolgoztunk rajta; ezeket bezárva visszajutunk az ADFS menedzsment konzolhoz. Középen egy új menüelem jelent meg Required: Add a trusted relying party névvel. Kattintsunk rá.

Egy újabb varázslóban találjuk magunkat. A nyitólapot továbbkattintva meg kell adnunk a kliens adatait. A szerverhez hasonlóan a kliens is egy FederationMetadata.xml-t bocsát ki magából, ami tartalmazza a szerver számára szükséges információkat. Megadhatunk ugyan URL-t is, de a tanúsítványproblémák miatt a varázsló nem tudja majd megnyitni. Így kézzel kell azt letöltenünk.

Indítsuk el a fejlesztői gépen a webalkalmazást, hogy az IIS-be felkerüljön. Ha van tűzfalunk, akkor nyissuk meg rajta a 443-mas portot, hogy a szervergép hozzá tudjon férni az IIS-hez. Majd a szervergépen nyissuk meg a https://192.168.120.1/AdfsClient/FederationMetadata/2007-06/federationmetadata.xml URL-t, és mentsük le lemezre az XML fájlt. Végül adjuk meg a varázslóban a lementett XML fájl elérési útját.

A következő képernyőn adjunk egy nevet (pl. AdfsClient) a kliensnek, a többi képernyőn pedig lépjünk túl, mert az alapértelmezett beállítások megfelelőek.

Ezekkel a beállításokkal elértük, hogy ha az alkalmazásunk kérést küld a szerver felé, akkor a szerver ki fogja azt szolgálni.

Már csaknem kész vagyunk, de azt még nem állítottuk be, hogy a visszaküldött tokenben pontosan mik szerepeljenek. Az Active Directory-ban rengeteg információ megtalálható, amiket valahogy le kell képezni a tokenen szereplő állításokra (melyek tulajdonképpen név-érték párok).

Ezeknek a beállítására automatikusan egy újabb ablak nyílik. Az Add Rule gombra kattintva adhatunk hozzá szabályokat.

A legegyszerűbb leképzési szabály az, ha a LDAP tulajdonságokat (Active Directory tulajdonságok) egy az egyben leképezzük a tokenen szereplő állításokra.

A következő képernyőn vegyük fel az alábbi leképzéseket, melyek a felhasználó loginnevét (pl. balint) és rendes nevét (pl. Farkas Bálint) leképezik állításokra. Amint látható, nem szükséges minden AD tulajdonságot kiküldeni; célszerű csak azokat, amelyekre az alkalmazásnak feltétlenül szüksége van.

Ha ezzel megvagyunk, akkor jó hírem van: elkészültünk. Megvan a szerver és az alkalmazás, és ezek kölcsönösen meg is bíznak egymásban. Nincs más hátra, mint kipróbálni a művet.

Látogassunk el a https://localhost/AdfsClient/ URL-re. 2 tanúsítványhiba árán eljutunk az Active Directory hitelesítőablakhoz. Adataink beírása után egy újabb tanúsítványhiba fogad bennünket, majd visszakapjuk a korábban fejlesztett Default.aspx-et, amely megjeleníti felhasználói adatainkat. Azaz sikeresen bejelentkeztünk egy távoli Active Directory segítségével.

És ugyanez élesben?

…Jóval egyszerűbb lesz. Nincs probléma a DNS szerverrel, hiszen az AD-nek lesz a céges, vagy esetleg nyilvános DNS szerver által feloldható címe (ez alapkövetelmény a helyes működéséhez). Továbbá használhatjuk a Windows Azure-t, mert a teljes felhőnek természetesen nincsenek a Compute Emulator-hoz hasonló megkötései.

Egy teljes felhőalkalmazás ADFS-ítése a fenti lépéseknek megfelelően történhet:

1. Előkészítjük az AD-t (valószínűleg csak az ADFS-t kell rátelepíteni és konfigurálni, nem kell a fent leírt valamennyi lépés).
2. Megírjuk, vagy kibővítjük az alkalmazásunkat.
3. Még a “földön” (fejlesztői gépen) bekonfiguráljuk az alkalmazást, hogy az AD-vel szemben hitelesítsen.
4. Feltesszük az alkalmazást a felhőbe (hogy megkapja a végleges URL-jét).
   FIGYELEM: A referencia miatt belekerül majd a Microsoft.IdentityModel DLL is az alkalmazásunkba, azonban ez a felhőben nem létezik, így kézzel kell felmásolnunk! Állítsuk True-ra a Copy Local tulajdonságát.
   
5. Miután az alkalmazás felkerült a felhőbe, bekonfiguráljuk az ADFS-t, hogy megbízzon a felhőalkalmazás felől érkező kérésekben.