Nucli d'un model d'identitat

Està clà que, dins un sistema on és gestionen dades assistencials, dades de confidencialitat alta, és del tot necessàri saber en cada moment qui hi està accedint, perque, i quines accions s'efectuen sobre elles. Tot això cal aplicar-ho a diferents nivells del sistema (visió vertical) i per tant cal definir bé quines entitats i relacions entre aquestes formen part del gestor d 'identitats de mencionat sistema. Ha de ser flexible, per poder-se adaptar als requisits actuals i futurs, per diferents tipus d'autentificació, assignació d'usuaris als serveis, delegacions d'autoritat, etc, etc, etc.

Entitats bàsiques en el model de la identitat

Els següents termes descriuen les entitats que representen la identitat bàsica:

• Usuari (demandant) - l'individu a ser identificat, autenticat i autoritzat a utilitzar certs serveis.
• Identitat - representa i identifica a un usuari en el sistema de gestió d'identitat. Un usuari pot triar
  mantenir diverses identitats separades, en general que representen diferents rols o grups de serveis que romandre separats.
• Credencials - la informació o altres elements que són verificables d'afirmar una identitat. Poden ser moltes les credencials associats amb la mateixa identitat. Els exemples típics són, un identificador d'usuari i contrasenya, un certificat digital, etc.
• Servei - És una agrupació lògica de funcionalitat de negoci que ofereix un proveïdor de serveis, amb regles coherents d'autorització i accés dels usuaris. Una "agència de salut" poden oferir diversos serveis diferents, i les normes d'accés i els nivells d'autenticació requerit pot ser diferent per a cada un. Alternativament, l'agrupació de la funcionalitat de negoci de diverses agències com un servei únic és possible sempre que aquestes siguin compatibles i hi ha una participació clara i la responsabilitat assignada pel servei afegit.
• Inscripció - el vincle d'identitat per a un servei particular, amb el servei corresponent context específic de atributs (identificadors). Una inscripció vàlida i activa dóna dret al propietari (o degudament autoritzat representant) per accedir al servei en el marc definit pels identificadors.
• Identificadors - Informació sobre els atributs adjunts a una inscripció, que identifiquen i proporcionen el context per a la relació d'una identitat amb el servei respectiu. Exemples d'aquests identificadors són un impost ciutadà de referència, un nombre d'assegurança nacional, un nombre d'assegurança social, un identificador de registre d'empreses, un valor que afegeix el número de registre d'impostos, un identificador d'impostos a la propietat, un identificador de proveïdor de serveis públics, o un número de compte.
  
• Grup - representa un conjunt d'usuaris que comparteixen la mateixa matrícula/identitat, en general com a representants d'una organització.
• Rol - una àmplia categoria d'identitat utilitzada per definir o limitar l'accés als serveis apropiats per a tots els els usuaris dins d'aquesta identitat. El conjunt típic de funcions inclou:
  
• individual (ciutadà, pacient, el metge, consumidor, client, etc) - presenta els clients per als serveis de la salut.
  
• Organització (grup) - representa les organitzacions (empreses), on diversos individus en un grup de poden compartir la mateixa matrícula/identitat i actuar en nom de l'organització.
  
• intermediari (agent, delegat) - permanent o temporal, nomenat representant d'una persona o organització autoritzada a actuar en el seu nom en el context del servei especificat.
  
• de la salut - les persones i els sistemes de representació dels organismes de salut i autorització per accedir a serveis específics.

El model d'identitat

La figura il.lustra les relacions entre les entitats esmentades en el model d'identitat. Tingueu en compte que:

• Un usuari pot tenir diverses credencials.
• Cada un dels mapes de credencials de la Identitat, i la mateixa identitat que podrà ser utilitzada per diversos accessos en diferents "verificadors de poders/permisos".
• Cada un dels vincles d'identitat té un paper únic de participació, que determina el subconjunt de serveis a disposició d'aquesta identitat.
• Múltiples identitats es podesn enllaçar a un grup.
• Un grup pot ser amo d'inscripcions múltiples per als diferents serveis.
• Cada un dels mapes d'inscripció pertany a un únic servei.
• Cada inscripció a un servei s'ha associat a identificadors exclusius al context de la relació entre el propietari de la inscripció i el Servei.
  

Deu temes clau en els sistemes sanitaris

• Com crear registres de salut d'un pacient.
• Com construir la història clínica d'un pacient a partir de la informació emmagatzemada en múltiples i diversos sistemes d ' informació.
• Com gestionar la identitat i les autoritzacions d'accés.
• Com identificar un pacient (o un professional de la salut) de manera única i fiable.
• Com combinar els diferents sistemes que puguin existir.
• Com interconnectar diferents sistemes i com fer-los interactuar.
• Com comunicar-se amb sistemes remots.
• Com seguir utilitzant sistemes heretats.
• Com aconseguir que tot això sigui flexible i àgil.
• Com aconseguir un alt rendiment i escabilitat per garantir el futur.
  

Dades

No cal dir que en tot sistema d' informació, les dades són el més important de tot. Els SI serveixen bàsicament per crear, modificar, cercar, transformar, facilitar.... DADES.

En un Hospital, evidentment és manipulen dades, un gran volum de dades, expressades en diferents formats, text, imatges, video, etc. Aquestes, han estat generades a partir de diferents entorns (aplicacions) que juntes i d'una manera distribuida interacctuen entre elles.

Recordem però que volem implementar un sistema nou, que doni resposta a tot el que fa referencia a l'assitència mèdica. Aquest sistema treballarà en dades del propi sistema i dades originaries d'altres sistemes.

Imaginem un sistema del més normal. Les dades d'aquest segurament estaràn enmagatzemades en una BD. I, l'accés a elles en última instància segurament es farà en SQL.

Molt bé doncs, abans de pensar quina solució oferir a aquesta part tant important (Data Acces Layer) la capa d'accés a dades, cal fer un esforç i marcar-se uns objectius, que si es pot més tard es dissenyerant per una futura implementació.

Que volem aconseguir, quins objectius volem assolir en aquest projecte pel que fa a l'accés a dades?

• Transparència d’origen de dades: El lloc on estiguin allotjades ha de ser indiferents respecta al seu accés. Això no vol dir que qualsevol lloc és bo.
• Model d'entitats únic, independent de la BD: Això vol dir que sigui quina sigui la BD el model d'entitats (mapejos a objectes, més o menys) ha de seguir el mateix patró.
• Facilitar la lectura de dades relacionades en diferents BD: Cercar dades d'un origen a partir de dades tretes d'un altre.
• Veure les dades com si fossin totes d’un mateix context: Totes les dades han de formar un context de dades únic (Conjunt de contextos).
• Augmentar la productivitat en els desenvolupament de capes de procés (Bussiness Layer)
• Facilita-ne, si cal, l' accés remot (Serveis de dades).
• Evitar cadenes SQL dins el codi de les aplicacions (no es una tonteria).

Recordo que plantajem la solució en .Net.

Si mirem que ens ofereix aquesta tecnologia sobre accésos a dades i models d'entitas ens trobem que els de Microsoft estàn fent feina.

ADO.Net Entity Data Model

• System.Data


• System.Data.Entity

El mateix nom es defineix com a una possible solució al que volem. Un model de dades accessible sense SQL (també si pot accedir amb SQL). I, com si accedeix?, amb LINQ.

LINQ: Increíble, incríble, increíble.

Però, no tot es bonic. Amb SQL Server funciona a la perfecció, amb origens XML també, amb coleccions carregades a memòria també, però amb les altres bases de dades (Intersystems Cache, Oracle, MySQL, etc) dependrà dels seus fabricants, o, de la nostre imaginació. Només cal implementar una llibreria que transformi expressions LINQ a sentancies SQL amb la sintaxi de la BD corresponent.(linQToSQL)

I que aconseguim ?

• Tenir uns contextes de dades accesibles des de LINQ
• Desde LINQ podem tractar diferents contextes de dades com si fossin un de sol.
• Podem interrogar dades d’un contexte a partir de dades d’un altre, de manera fàcil i transparent.
• Projectar les dades a través de serveis de dades (ADO Data Services).
• Definir un cotext de dades (virtual) que actui com a proxy de tots els cotextes existents, al qual li demanarem les dades des de capes superiors (BL).

Una simple aproximació de disseny. Comencem a veure la llum?

Gestor d' identitats: solució inicial pel sistema

Bé, continuant amb les identitats, i després d'un periode de recerca, i pensant en la infraestructura de servidors i la tecnologia de desenvolupament "Microsoft", fem-li una ullada a les següents imatges

En un moment en que està de moda la col.laboració, el cloud computing i el SAAS (Software As A Service) i mirant el contexte en el que ens movem (HCCC, SIRE, ICAM, RCA, Factura Electronica) crec que hem de pensar en la col.laboració entre serveis de diferents entitats o coorporacions sanitaries de manera que s' aprofiti al màxim la feina feta. Per fer això s'han de complir uns requsits de seguretat que cal aplicar als diferents serveis exposats i unes politiques de col.laboració pactades entre els diferents participants.

Es de suposar que no tots els desenvolupadors coneixen tecniques de seguretat aplicades a la autentificació i autorització d'usuaris (identitat). Els desenvolupadors s'han de dedicar al negoci de la empresa i deixar els temes de seguretat als que en saben. O sigui, en termes desenvolupament, diriem que separem la lògica de seguretat de la lògica de negoci. Quan això només ha de funcionar dins la intranet, el problema es bastant senzill tant de desenvolupar com d'aplicar algún model existent (forms, windows,etc). Ara bé quan els límits sobrepassen la intranet, estem parlant de sistemes que confien els uns amb els altres. Per donar solució a això podem fer dues coses:

1. Donar usuaris i passwords a tots els usuaris externs (empresa forana) per tal de que puguin entrar a les nostres aplicacions




2. Dir-li al nostre sistema d'identitas(usuaris) que confii amb el sistema d'identitats de la empresa forana(amb tots o un grup de membres d'aquest)

Això és el que s'anomena federar sistemes (per dir-li d'alguna manera) i actualment es pot aconseguir amb Active Directory Federation Services, dins les tecnologies de microsoft.
Però com es de suposar això ha d'evolucionar, de manera que la seva tecnologia de desenvolupament, Microsoft .Net pugui aqprofitar el màxim aquesta visió de col.laboració en les seves tecnologies presentades als usuaris (un usuari pot ser una persona, una empresa o una aplicació) Asp.Net, WCF (Serveis), Winforms, SilverLigth, WPF, etc. I si, actualment es troba en la seva Beta 2, es diu Microsoft Code Name Geneva i disposa de bastante informació per començar-hi a treballar. Finalment serà anomenat Windows Identity Foundation i es distribuirà amb les noves versions de Windows 2008 (anira inclós en el producte).
Es basa amb estandars de seguretat i xifratge, soporta tarjes de identitats, pot generar assertions SAML, etc.

En aquests moments hi estic treballant.

Gestor d' identitats: Autentificació, autorització, pas de credencials entre aplicacions

La meva intenció no és explicar que és un gestor de identitats, però si deixar cla de la necessitat de disposar-ne d'un.
En el sistema a desenvolupar, aquesta feina serà delegada al servidor/s que allotgin el Servei de Active Directory.
Com tots sabem, l' AD és capaç d'enmagatzemar identitats d'usuari, maquinari, grups, unitats organitzatives, dominis, etc.

Per si no ho havia esmentat abans, utilitzarem sistemes microsoft tant en servidors com en clients, dins un domini d'AD. Per tant, els usuaris es validaran quan iniciin una sessió. Però, el usuari validat a la sessió a vegades no és nominal, sino que representa un lloc de treball on l'ordinador es utilitzat per diferents usuaris no concurrents alhora. Per tant, quan iniciien una aplicació del sistema, tots els usuaris s'han de tornar a loginar, per ser nominals, identificats en el programari per poder autoritzar les funcionalitats a les quals tenen accés.
I si no hi ha un sistema centralitzat per autentificar i autoritzar usuaris desde les aplicacions, cada cop que obrin una de les aplicacions que formen part del sistema senzer, els usuaris han de realitzar el procés d'autentificació. I si està centralitzat amb un AD, però les aplicacions no saben pasar-se credencials les unes a les altres, quan es criden entre elles, cal fer el procés d' autentificació. I si la crida entre aplicacions és entre aplicacions de tecnologies diferents, la cosa comença a complicar-se.
Bé, el que porti uns anys en el món de dels sistemes distribuits (en molts sistemes) suposo que ja ha entés el que vull dir.

La ideia, o proposta per solucionar aquest problemes, és dissenyar un sistema SSO (Single Sing-on) amb algunes particularitats pròpies, que un cop hagi validat un usuari, es puguin fer crides entre aplicacions de tecnologies diferents (ASP.Net, WinForms), allotjades en servidors diferents o subdominis diferents.

I això és possible? Si ho és, i ho farem.