simple hit counter
Come funzionano i Security Token Services. - Innovation, Technology & Digital Startups - Site Home - MSDN Blogs

Come funzionano i Security Token Services.

Come funzionano i Security Token Services.

  • Comments 4

image Oggi per la serie MSDN Talks siamo in compagnia di Alessio Mannelli - Senior Developer - della divisione Servizi di Microsoft Italia. Con Alessio negli anni passati abbiamo speso insieme parecchio tempo nella definizione e realizzazione di infrastrutture applicative (a partire da WSE 2.0) fino ad arrivare ai giorni più recenti con WCF (WIndows Communicatino Foundation). In questo breve video Alessio ci parlerà dei meccanismi di autenticazione tra servizi nei modelli definiti da WS-Security, WS-Trust e SAML 1.1. Particolare attenzione viene posta al concetto di Authority (detto anche STS - Security Token Service). Questa breve introduzione teorica sull'argomentè essenziale per capire scenari più complessi di Single-Sign-On in architetture SOA. Inoltre, i meccasismi spiegati da Alessio sono i medesimi che troviamo in tecnologie come ADFS (Active Directory Federation Services), CardSpace, nel nuovo Zermatt (di cui parleremo a breve) e nelle future tecnologie che verranno presentati tra poco al PDC.

L’authority gestisce il riconoscimento dei chiamanti e la profilazione degli utenti sui servizi offrendo al sistema un punto centrale per la gestione delle politiche di sicurezza. Il chiamante prima di poter effettuare una richiesta al servizio deve autenticarsi presso l’authority e farsi rilasciare un ticket di accesso al servizio richiesto.

L’autenticazione presso l’authority avviene mediante l’invio dell'identità del servizio client che può essere espressa sotto varie forme: credenziali di rete, credenziali custom, certificati X509 oppure Ticket Granting Ticket (TGT) preventivamente rilasciati dalla stessa authority.

Alessio, ci parlerà prevalentemente del modello di autenticazione di un servizio tramite certificati X509. L’utilizzo di certificati X509 consente di realizzare un’infrastruttura di sicurezza basata su algoritmi asimmetrici che utilizzano chiavi pubbliche e private per firmare e criptare le comunicazioni verso l’authority.

Lo scenario basato sull’utilizzo di certificati X509 richiede la presenza di una Certification Authority (interna o esterna all'azienda) riconosciuta da tutte le entità dell’infrastruttura che rilascia certificati X509 per l’identificazione dei vari attori e per l’utilizzo degli algoritmi di crittografia e firma. Ad ogni componente (chiamante, servizio e authority) è associato uno specifico certificato. La specifica WS-Trust definisce come i servizi in gioco possano autenticarsi tra loro. Riassumento lo scenario descritto da Alessio avremo :

image

1) il servizio/applicazione chiamante si autentica all'authority via X509. In questo contesto la specifica WS-TRust definisce un tipo di messaggio chiamato RST (Request Security Token).

2) l'authority autentica il servizio/applicazione client, verifica le policy autorizzative e crea un nuovo security token di tipo SAML che descrive l'identity del client ed eventuali informazioni aggiuntive sui ruoli e applicative.In questo contesto la specifica WS-TRust definisce un tipo di messaggio chiamato RSTR (Request Security Token Response).

3) Il chiamante passa il security token di tipo SAML al servizio target che può effettuare la verifica dell' identità del client e procedere all'esecuzione del processo di business.

 

 

 

Buona visione

--Mario

Leave a Comment
  • Please add 5 and 4 and type the answer here:
  • Post
Page 1 of 1 (4 items)