Cercar en aquest blog

22/4/10

Proveïdor d’Identitats: Un exemple per entendre-ho tot (I)

Per fer referència a tota una arquitectura de gestió d’identitats que fan servir aplicacions actives (winforms, windows presentation foundation, windows communication services, workflow services, aplicacions RIA, windows mobile, etc) i aplicacions passives (ASP.Net, aplicacions Web en general), unificada, centralitzada i basada en estàndards, que millor que presentar un escenari i fer-ne el desenvolupament.

Com que d’exemples d’aplicacions passives n’està ple a Internet, ens centrarem en un escenari actiu.

Descripció Escenari: Suposem un domini d’aplicació format per una aplicació client desenvolupada en winforms, que accedeix a un servei distribuït (WCF), i aquest a un altre servei distribuït (WCF). Fins ara cap cosa nova. Però ara hi posarem unes petites regles:
  • L’ usuari s’haurà d’autenticar per accedir a l’aplicació winforms, al servei fronterer i al darrer. Amb un cop n’hi hauria d’haver prou, no?
  • Ha de suportar que els serveis definits estiguin en nivells (servidors) diferents, inclòs en xarxes diferents i dominis diferents (en l’exemple no ho farem per falta de recursos, però és del tot possible i fàcil de fer).
  • La transmissió de credencials entre aplicacions actives ha de ser segura.
  • Els components de seguretat que fan referència a l’autentificació, autorització i transmissió de credencials entre aplicacions han de ser transparents pel desenvolupador. Afegir els components ha de ser un automatisme de posada en producció dins un entorn empresarial, seguin les normes establertes.
Per poder desenvolupar l’ escenari, disposarem d’una serie de recursos:
  • Dos servidors amb Windows 2008 R2, IIS + WAS, Windows Identity Foundation (WIF). En un dels dos hi instal•larem AD+ADFS 2.0 RC (hi ha molta documentació per Internet). Frameworks fins al 3.5.1. Podem instal.lar el 4.0 però a hores d’ara no és una versió publicada.
  • Una estació client amb Windows 7 o XP, amb els frameworks i WIF mencionats.
  • Una eina de desenvolupament com pot ser VS2008 o VS2010 Beta o RC, instal.lada en una de les màquines anteriorment citades. (Jo personalment, instal•lo un Visual Studio a cada servidor de desenvolupament).


Si ens fixem bé en les dependències, els serveis depenen directament de la capa de seguretat per funcionar, i per tant les aplicacions client indirectament també necessiten d’aquesta per utilitzar-los.

I per tant la seqüència que haurà de seguir l’ aplicació client per accedir al servei frontera serà:

  1. Demanar usuari i contrasenya.
  2. Connectar amb la capa de seguretat, presentar les credencials d’usuari i sol•licitar un token per accedir al servei. Si està autoritzat, aquesta li servirà un token amb la informació que necessita de l’usuari el servei per funcionar, per ser operatiu.
  3. L’agent del servei (client del servei, Proxy del servei) presentarà el token a aquest, per tal de que doni accés a la invocació de les seves operacions.
  4. El servei veurà la identitat de l’usuari que està executant l’aplicació client. Si volem transmetre-la cap al servei final, em de tenir en compte algunes coses. Primer de tot, l’usuari que executa el procés del servei al servidor, és el que hi hagi definit en el pool del IIS on estigui allotjat el servei (Normalment NetWorkService). Per tant, hem de guardar el token que arriba sense desxifrar, per poder-lo utilitzar per invocar al servei final, ja que aquest porta les credencials del usuari tal i com les entén la capa de seguretat. I a l’agent del servei final li hem de dir que encara que l’usuari executor del procés sigui el NetWorkService, actuí com a l’usuari que ha iniciat a l’aplicació client. Aquesta sol•licitud de delegació la gestiona la capa de seguretat i aquesta l’ha de permetre.
  5. Finalment, al servei final hem de tenir dues identitats. Un Actor que serà el NetWorkService i un usuari principal que serà l’usuari que ha iniciat l’aplicació client. O sigui el NetWorkService actua com a l’usuari de l’aplicació client en el servei final, el qual pot està allotjat a la Xina. Transmetem una tarja d’identitat des de l’ inici fins al final.
Anem per feina: Implementació
Primer de tot creem una solució al Visual Studio (jo utilitzo el 2010). Si hem instal•lat bé el WIF SDK, tindrem uns templates i un Add-in que ens facilitaran la feina. Alhora de crear WCF Serveis preparats per treballar amb identitats i per posar-los en producció amb un gestor d’identitats (IDP) com pot ser ADFS 2.0.
Si ens hi fixem els serveis els ubiquem al IIS local. La solució final ha de tenir una aparença semblant a la de la imatge següent.


Dos serveis habilitats per treballar amb “claims” i una aplicació Winforms.