Freigeben über

Microsoft e SAML 2.0 Protocol

  • Artikel

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

Comments