Security & Architecture : Interoperabilità

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

Microsoft, Apache… un ossimoro??

mfontana — Sun, 07 Jun 2009 11:06:00 GMT

Innanzitutto prima di generare uno sciopone a qualcuno vi prego di notare la punteggiatura nel titolo di questo post !!! Microsoft VIRGOLA Apache e non Microsoft Apache :-) Nessuna paura quindi , non abbiamo acquistato Apache !!!! Però c’è da dire che questa notizia, come architetto, mi ha reso proprio contento. Alzi la mano (tanto vi vedo) chi di voi si è trovato almeno una volta nella situazione di far parlare del codice .NET con quello JAVA e/o PHP o viceversa? E tenga su la mano chi ha incontrato qualche “piccolissima” difficoltà nella configurazione e settaggi vari nei rispettivi ambienti !!!! Nessuno ?? ok allora questo post non fa per voi :-)

Diciamo che c’è stato un evento epocale… Microsoft partecipa alla keynote della conferenza JavaOne!! Infatti durante la conferenza JavaOne Steven Martin - Senior Director, Developer Platform Product Management – e Aisling MacRunnels - Sun Vice President- hanno annunciato durante la keynote che Sun parteciperà attivamente al progetto open-source Stonehenge inizialmente creato da Microsoft, WS02, University of Moratuwa, Progress Software, Red Hat e Eviware. In particolare Sun si occuperà della realizzazione Java/Metro della soluzione StockTrader.

Microsoft (anche se molti non lo sanno) ha partecipato e sta partecipando a molti progetti open source ma questa è la prima volta che Microsoft partecipa come code contributor in un progetto Apache!!

Lo scopo di questo progetto è nobile : realizzare in concreto degli scenari di interoperabilità e di best practices tra applicazioni e web services sviluppati su stack tecnologici diveri. Come dissi in questo mio post “non basta avere delle specifiche standardizzate per realizzare veramente degli scenari di interoperabilità” (sintetizzato) !!! I motivi sono molteplici : non tutti i vendor implementano le medesime specifiche anche se standardizzate, non sempre è chiaro come configurare i vari ambienti e prodotti, spesso ci sono delle piccole differenze in termini di serializzazione, encoding che se non gestite possono rendere difficile la realizzazione del progetto…

Per questo motivo il progetto Stonehenge realizza delle applicazioni di esempio basate su stack Java, .NET, PHP ma anche Python e Ruby in grado di interoperare utilizzando un set comune di specifiche standard definte dal W3C e OASIS. Stiamo parlando in prevalenza di comunicazioni basate sugli standard WS-*. I vari sorgenti li potete trovare nel repository di stocktrader :

--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