Security & Architecture : ADFS

Le basi per un Common Identity Framework

mfontana — Tue, 09 Jun 2009 12:41:55 GMT

Per chi come me sta lavorando assiduamente sull’inserimento del modello claims-based nelle attuali architetture dei clienti non può perdere il post e relativo documento di Kim Cameron dal titolo :“Proposal fo a Common Identity Framework: A User-Centric Identity Metasystem” scritto da Kim Cameron, Reinhard Posch e Kai Rannenberg tutti nomi molto conosciuti nell’ambito dell’Identity Management (come potrete leggere dal post di Kim). (download : PDF o DOC)!!!

In questo documento vengono esplicitati i principi base su cui si può fondare un Identity Metasystem capace di integrare e razionalizzare la gestione delle identità indipendentemente dagli stack tecnologici utilizzati. Il tutto, ovviamente, in conformità delle principali leggi sulla sicurezza e sorpattutto sulla privacy. Vi assicuro che questo documento è di estrema utilità perchè evidenzia con chiarezza i principali “blocchi” architetturali e relative dipendenze.

Tra l’altro questo documento è stato inserito nel libro The Future of Identity in the Information Society un trattato che raccoglie ricerche effettuate in vari stati europei sull’identificazione dei cittadini, le ID cards, gli impatti delle leggi sulla privacy e tutti gli aspetti di computer forensics legate ai crimini informatici basati sul furto di identità.

Tre sono gli aspetti di questo whitepaper che mi hanno aiutato (più di tutto) a formalizzare meglio alcuni aspetti del lavoro che sto facendo in questo periodo sulla claims-based security: la suddivisione architetturale fatta tramite gli abstract services, la tassonomia dei claims e il concetto di Data Minimization. Con la definizione degli abstract services si riesce ad avere una visione olistica dell’architettura di un Identity Metasystem senza entrare nei tecnicismi che inevitabilmente vengono introdotti quando si lavora con un determinato vendor/prodotto. Nel documento questi servizi vengono presentati come astratti perchè rappresentano le funzioni di base dell’architettura e successivamente i vendor potranno realizzare i propri sistemi reali calando questa visione astratta nei propri modelli.

Stiamo quindi parlando di abstract services come il Primordial Claim Abstract Service, Registration Abstract Service, Claims Provider Abstract Service, Claims Selector Abstract Service, Claims Approver Abstract Service, Resource Matching Abstract Service.

La tassonomia dei claims invece diventa utilissima quando si lavora a livello architetturale alla definizione dei claims gestibili in azienda e relativa suddivisione per applicazione:

Type of Claim	Comment	Examples
Static	What we have traditionally called “properties” and “attributes” of the subject – static within some window of time	National identifiers and employee numbers Date of Birth Name Address
Relationship	Subject is in some relationship with another subject (and open-ended model with multiple sources and viewpoints)	Member of arbitrary group Member of assigned role Relationship to another subject (e.g. Personal Assistant or Parent) Mandate (e.g. trustee) Acting-as / On-behalf-of relationships
Derived	Claims that convey minimum necessary information by deriving it from facts but not releasing the facts	Over 21 or Under 16 University Student Person in Drug Trial Unmarried Female in 20’s
Capability	Authentication and authorization both based on claims transformation. Capabilities are determined by relying party within a defined scope	Can-read-calendar Can-access-write-operation Denied-update-in-given-scope
Contextual Claims	Factors useful in evaluating the security presentation.	Authentication technology, location, time

Infine gli aspetti di Data Minimization ci permettono di focalizzare quali sono gli ambiti in cui è necessario garantire il minor numero di informazioni personali degi utenti come le collezioni, aggregazioni, storage, retention,replication, distribution,linkage…

Un documento quindi che NON si piò NON leggere se si lavora nel campo dell’ Identity Management !!!

--Mario

Come rendere Sharepoint 2007 Claims-Aware e integrarlo in Geneva Server BETA 2

mfontana — Wed, 27 May 2009 22:40:51 GMT

Grande enfasi sto riscontrando nelle richieste di chiarimenti sulla configurazione di Sharepoint 2007 in “versione” Claims-aware ovvero come poterlo integrare nelle nuove architetture basate su Geneva Server. In questo mio precedente post avevo dato il link al laboratorio che abbiamo messo on-line ma i requirements sono un forte deterrente :

Il laboratorio è composto da 4 macchine virtuali
Il download è poco più di 14Gb
L’ambiente gira su Hyper-V.
Sono necessari un minimo di 8 GB di RAM sulla macchina Host per far girare l’ambiente.

risultato … molte persone non possono provare il laboratorio ma (giustamente) vogliono capire come configurare Sharepoint per parlare la “nuova lingua franca dei claims” :-). A questo proposito nel post mi concentrerò su alcuni aspetti importanti di configurazione di Sharepoint che non sono descritti per intero nel documento di configurazione dello scenario (che è comunque disponibile insieme alle macchine virtuali ma con un download separato) e darò il link per scaricare i files mancanti per una configurazione “fai-da-te” :-) !!

Lo scenario di riferimento è il seguente :

Figura 1 : Struttura dello scenario implementato.

Quindi di fatto stiamo lavorando sulla configurazione della macchina CONTOSOSRV02.

Tornando a noi, i passi minimi per configurare Sharepoint in modalità claims-aware sono quelli descritti nei primi 4 step del documento, ovvero :

Configurare Sharepoint affinchè accetti i token rilasciati da Geneva Server.
Aggiungere il gruppo Domain Admins tra gli amministratori di Sharepoint.
Configurare Geneva Server a rilasciare i token per Sharepoint
Configurare i Ruoli in Sharepoint.

Sebbene i punti 2-3-4 sono ben chiari, il primo viene trattato semplicemente come l’esecuzione dello script ConfigureSharepoint.bat che altro non fa che lanciare lo script SetupSharePointIDFX.vbs con i seguenti parametri:

-appconfig <web.config del portale Sharepoint>.
-adminconfig <web.config del portale di amministrazione di Sharepoint>.
-applicationuri <URL esatto dell’applicazione sharepoint>.
-stsmetadataurl <Il metadata URL del STS (Security Token Service) di Geneva per ottenere i federation metadata . Il formato di questo URL è il seguente : https://server-name/FederationMetadata/spec-version/FederationMetadata.xml ed è definita direttamente al paragrafo 3.2.2 della specifica WS-Federation>.
-fedutilmode <modalità di esecuzione dell’ utility FedUtil.exe>.
-urlZone <la zone di Sharepoint da configurare>.

Nel caso specifico dello scenario avremo i seguenti parametri:

-appconfig C:\\inetpub\wwwroot\wss\VirtualDirectories\docs.contoso.com443\web.config.
-adminconfig C:\\inetpub\wwwroot\wss\VirtualDirectories\3526\web.config.
-stsmetadataurl https://sts1.contoso.com/federationmetadata/2007-06/federationmetadata.xml.
-fedutilmode "silent".
-urlZone "Extranet".

Ma cosa fa esattamente questo script?

Lo script inizia con l’invocazione dell’utility FEDUTIL.EXE (fornita con Geneva Framework) per configurare il Security Token Service (Geneva Server) come un trusted issuer per Sharepoint. Successivamente lo script modifica le configurazioni dei web.config passati come parametro con lo scopo principale di aggiungere i nuovi provider per Sharepoint forniti all’interno di Geneva Framework : nel caso specifico avremo il MembershiProvider (Microsoft.IdentityModel.SharePoint.SharePointClaimsMembershipProvider), il Role Provider (Microsoft.IdentityModel.SharePoint.SharePointClaimsRoleProvider) e infine un HttpModule per gestire correttamente la FBA (Forms Based Authentication) di Sharepoint (Microsoft.IdentityModel.SharePoint.OfficeDiscoveryFormsAuthenticationModule). Infine lo script invoca l’utility STSADM.EXE (fornita con sharepoint) per configurare l’ URL mapping e il metodo di autenticazione impostato a ‘none’ e ASP.NET imporsonate = false.

Una volta terminato lo script con esito positivo (lo si vede dall’output) crea un file contenente i federation metadata per Sharepoint che successivamente dovrà essere dato in pasto a Geneva Server per completare la profilazione del STS o in gergo Geneva l’ Identity Provider (IP)!! That’s all !! A questo punto potete seguire passo passo il documento e continuare la configurazione a mano.

Qui trovi il link del documento di configurazione dello scenario.

Qui puoi scaricare gli script di configurazione.

Buon lavoro…

--Mario

Geneva Server NON è la soluzione di “Identity Lifecycle Management” !!!

mfontana — Fri, 22 May 2009 11:25:10 GMT

In questi ultimi mesi sto lavorando con alcuni grandi clienti italiani nel disegno e nella realizzazione di infrastrutture Claims-Based utilizzando i vari componenti di Geneva : Geneva Server, Geneva Framework e Geneva CardSpace.

L’equivoco più ricorrente è quello di associare in prima battuta Geneva Server come LA (notare il maiuscolo) soluzione Microsoft per l’ Identity LifeCycle Management (ILM). Non è corretto !!! Al contrario, Geneva Server & CardSpace insieme a Geneva Framework sono un tassello molto importante di una architettura articolata di ILM che comprende però molte aree strategiche non gestite direttamente da Geneva. Nella figura sottostante ho elencato i tre macro layers di una infrastruttura ILM (quelli in rosso) con relative aree di competenza mentre ho evidenziato in giallo le aree coperte anche da Geneva !!!

(cliccare sull’immagine per vederla più grande)

Geneva copre quindi solo alcune parti dell’infrastruttura di ILM. Infatti Geneva è la piattaforma che permette di semplificare la fruibilità alle applicazioni tramite il modello claims-based. Per maggiori info leggete questo mio breve post intitolato : Cosa è Geneva Server in due parole.

Geneva Server quindi ci aiuta a gestire alcuni aspetti (ma non tutti) dell’ ILM soprattuto nel mondo delle Web Applications e dei Web Services, un’area quest’ultima che pone delle sfide interessanti alla disciplina dell’ ILM in quanto per loro natura possono essere “sparsi” all'interno di dipartimenti della stessa azienda, da business partners o “in the clound”.

--Mario

Microsoft e SAML 2.0 Protocol

mfontana — Wed, 20 May 2009 13:15:10 GMT

Forse non è ancora noto a tutti che Microsoft sta lavorando per integrare parte del protocollo SAML 2.0 all’interno dei servizi di Active Directory.

Come presentato durante l’ultimo PDC (Professional Developers Conference) da Kim Cameron la nuova versione di ADFS (Active Directory Federation Services) che per adesso ha il code name Geneva, oltre ad estendere il supporto alle specifiche WS-* (WS-Security, WS-Trust, WS-Federation, ecc.…) sarà in grado di “parlare” SAML 2.0 creando una vera e propria infrastruttura sistemistica ed applicativa capace di semplificare gli aspetti di autenticazione e di Single Sign On. Geneva inoltre è definita una “open platform” perchè permette di realizzare una architettura claims-based basata sui principali protocolli standard (WS-* e SAML 2.0). I componenti della specifica SAML 2.0 implementati sono i seguenti :

Web SSO AuthnRequest : HTTP redirect
Web SSO Response : HTTP POST
Identity Provider Discovery : Cookie
Web SSO Response : HTTP Artifact
Artifact Resolution : SOAP
Single Logout (IdP-initiated) : HTTP redirect
Single Logout (SP-initiated) : HTTP redirect
Enhanced Client/Proxy SSO : PAOS

Infine Geneva per automatizzare al massimo l’amministrazione degli aspetti di federazione utilizzerà il nuovo harmonized federation metadata format basato sui metadata SAML 2.0. (leggete qui la notizia da Don Schmidt)

E questo cosa significa?

Interoperabilità e Single Sign On! Infatti SAML 2.0 è il protocollo di riferimento per le principali architetture Open-Source per lo scambio di informazioni di autenticazione ed autorizzazione tra security domains mentre lo stack di specifiche WS-* (e nello specifico WS-Federation) è lo standard di riferimento utilizzato nei principali prodotti commerciali sempre con l’obiettivo di scambiare informazioni di autenticazione ed autorizzazione.

Queste specifiche hanno molti vantaggi per noi architetti ma anche un grosso svantaggio : mantenere i due mondi nettamente separati!! Questo significa che noi poveri architetti spesso siamo costretti a creare componenti di architetture più o meno custom per poter superare queste diversità. E’ il colmo ! Dover disegnare/scrivere delle soluzioni custom per integrare gli standard !!! (questo è il tipico caso in cui la presenza di standard non sempre aiuta!!).
Con Geneva questa realtà finalmente può cambiare!! Oggi siamo in grado di far interoperare questi due mondi permettendoci di disegnare scenari di Single Sign On per i nostri utenti indipendentemente dallo stack applicativo e sistemistico utilizzato. Finalmente possiamo iniziare a parlare di Interoperabilità con la I maiuscola anche in ambito Identity dove normalmente le varie architetture storicamente erano chiuse, blindate dalla propria tecnologia!

WS-* e SAML 2.0 Protocol. Perchè due stack di specifiche?

Ma allora la domanda nasce spontanea … perchè due stack ?

Cominciamo col dire che le specifiche WS-Trust/Ws-Federation (dello stack WS-*) e il protocollo SAML 2.0 hanno alcune parti in comune ma obiettivi differenti !

WS-Trust/Ws-Federation come tutte le specifiche di WS-* sono pensate prevalentemente per Web Services ovvero scenari “attivi” capaci di “parlare SOAP”. Infatti anche il nome lo dice : WS-* significa Web Services-*, e quindi WS-Trust = Web Services Trust, WS-Federation = Web Services Federation. Quindi lo stack WS-* fin dagli albori (siamo alla fine del 2000 circa) ha lo scopo di fornire un’infrastruttura per il mondo a servizi (da SOA a SaaS, S+S, ecc…). WS-Federation in quello che era chiamato “profilo attivo” rappresenta la naturale evoluzione di WS-Trust e descrive i meccanismi di trust tra Security Domains differenti (Federazioni) con una predilezione e un punto di vista a servizi.

Una architettura di questo tipo che pone tra i propri obiettivi anche il Single Sign-On tra applicazioni e Web Services sarebbe stata monca se non avesse aggiunto anche il supporto ai client Web che non sono in grado di gestire il protocollo SOAP (ovvero i Browser). E’ per questo motivo che WS-Federation ha anche il profilo passivo, ovvero una serie di regole che permettono ai browser di utilizzare i protocolli WS-Trust e WS-Federation tramite HTTP 1.1 e quindi di integrare le anche le Web Applications nel processo di Single Sign On. In questo caso (passivo) abbiamo una sovrapposizione con una parte delle funzionalità espresse da SAML 2.0 protocol !!!

Quindi per rispondere alla domanda “perchè due specifiche” posso dire che WS-Federation nasce come evoluzione di un particolare modello ormai consolidato di sicurezza e di gestione delle identità capace di gestire sia i Web Services che per le Web Application mentre questo doppio supporto non era previsto (almeno inizialmente) dal protocollo SAML 2.0 (nato prevalentemente per gli scenari Web Apps). Infatti, SAML 2.0 nasce dalla convergenza di SAML 1.1, Liberty ID-FF 1.2, e Shibboleth 1.3 con il primario obiettivo di definire uno standard per il Web Single Sign On. Successivamente SAML 2.0 ha aggiunto anche il SAML ECP (Enhanced Client Profile) per l’integrazione di client attivi.

WS-Federation quindi permette a tutti quelli che hanno investito sullo stack WS-* di continuare gli investimenti adottando un unico modello di sviluppo indipendentemente dai sistemi utilizzati - Windows/Linux – e dai linguaggi .NET/Java o altro. Dal canto suo, seguendo anche le innumerevoli (e a mio avviso, giustissime) richieste da parte di clienti da tutto il mondo, parte del protocollo SAML 2.0 è stato integrato in Geneva ponendo il primo tassello verso la realizzazione di un Identity MetaSystem capace di gestire ambienti multi piattaforma e multi player. Per ulteriori informazioni leggete questo post di Don sullo stesso tema!!

Con questo post spero di rispondere a tutti quelli che sostengono che WS-Federation è nato esclusivamente con la volontà di fare una guerra al mondo Open Source e al protocollo SAML 2.0. Personalmente , come Software Architect trovo molto frustrante quando esistono stack di infrastruttura applicativa difficilmente integrabili tra loro perchè non ci permettono di svolgere il nostro lavoro al meglio e accolgo sempre in modo positivo quando questi ostacoli vengono superati dalle infrastrutture di base siano esse Microsoft o altro.

--Mario

Agenda del WebCast sull' Identity & Access Management

mfontana — Thu, 27 Sep 2007 01:11:51 GMT

Questa è la versione definitiva dell'agenda del Webcast che ho fatto sull' Identity & Access Management presentato qui.

Agenda

Identity & Access Management Overview.
Cosa intendiamo per Digital Identity.
Identity Design Patterns.
Scenari architetturali.
Identity MetaSystem.
Identity LifeCycle Management.

Potete scaricare le slides mentre l'intero WebCast è disponibile per il download qui.

--Mario