Condividi tramite

Interoperabilità di Federated Identity Management

 

Microsoft Corporation

Maggio 2004

Riepilogo: Man mano che le aziende estendono i sistemi interni agli utenti esterni, è importante assicurarsi che i sistemi possano interagire con le applicazioni di altre organizzazioni. I principali provider di soluzioni di gestione delle identità hanno dimostrato le proprie soluzioni che soddisfano questa esigenza in un recente workshop sull'interoperabilità. (7 pagine stampate)

Nota Questo documento descrive i risultati di tale workshop in cui sono state testate le implementazioni di uno scenario di interoperabilità usando il profilo richiedente passivo WS-Federation basato sul set di standard di sicurezza dei servizi Web.

Contenuto

Federated Identity Management
Workshop sul protocollo dei servizi Web
Interoperabilità del profilo richiedente passivo WS-Federation
Risultati e discussione del workshop
Collegamenti correlati

Federated Identity Management

Per soddisfare la sfida delle attuali tendenze del settore, ad esempio la crescita del commercio business-to-business, una maggiore mobilità e la necessità di connettività persistente, le organizzazioni stanno estendendo i sistemi interni agli utenti esterni fornendo connettività a clienti, partner, fornitori e dipendenti mobili. Fornire connettività efficiente e trasparente richiede la creazione di relazioni "basate su attendibilità" che consentono alle organizzazioni di condividere in modo sicuro le informazioni sull'identità di un utente. Le relazioni di trust consentono il flusso delle informazioni sulle identità e sui criteri tra organizzazioni indipendenti dal modello di piattaforma, applicazione o sicurezza. Le relazioni di trust devono essere create rapidamente ed in modo efficiente per ottimizzare la produttività ed eliminare i processi manuali che spesso si svolgono oggi. La federazione descrive la tecnologia e gli accordi aziendali necessari per questa interconnessione.

I sistemi federati devono interagire tra i limiti dell'organizzazione e connettere i processi che usano tecnologie diverse, archiviazione delle identità, approcci di sicurezza e modelli di programmazione. All'interno di un sistema federato, le identità e le credenziali associate vengono comunque archiviate, di proprietà e gestite separatamente. Ogni singolo membro della federazione continua a gestire le proprie identità, ma è in grado di condividere e accettare in modo sicuro identità e credenziali da altre origini dei membri.

All'interno di un sistema federato, un'organizzazione necessita di un modo standardizzato e sicuro di esprimere non solo i servizi che rende disponibili a partner e clienti attendibili, ma anche i criteri in base ai quali gestisce la propria attività, ad esempio quali altre organizzazioni e utenti considera attendibili, quali tipi di credenziali e richieste accetta e i relativi criteri di privacy.

Rispondendo a questa esigenza, Microsoft collabora con i leader del settore per sviluppare un set di specifiche per l'architettura distribuita delle applicazioni comunemente denominata servizi Web. L'architettura dei servizi Web si basa su standard di settore come SOAP, XML, WSDL e UDDI e fornisce una base per offrire soluzioni aziendali complete e interoperabili per l'azienda estesa, inclusa la possibilità di gestire identità e sicurezza federate. Il modello di servizi Web si basa sull'idea che i sistemi aziendali siano scritti in linguaggi diversi, con modelli di programmazione diversi, che vengono eseguiti su e sono accessibili da molti tipi diversi di dispositivi. I servizi Web sono un mezzo indipendente dalla piattaforma e dal linguaggio per la creazione di sistemi distribuiti in grado di connettersi e interagire tra loro in modo semplice ed efficiente su Internet. Altre informazioni sui servizi Web e sulle specifiche dei servizi Web sono disponibili in MSDN Web Services Developer Center.

Interoperabilità

Il successo dell'architettura dei servizi Web e delle applicazioni che consente dipende dalla capacità di queste applicazioni di interagire in una rete attendibile di aziende, partner e servizi indipendentemente dalla piattaforma, dal linguaggio di programmazione o dall'applicazione con cui interagiscono. A tale scopo, le aziende aziendali che implementano servizi Web vogliono che le applicazioni siano conformi agli standard dei servizi Web per garantire l'interoperabilità. Gli standard dei servizi Web, tra cui SOAP, XML, WSDL e UDDI, consentono agli sviluppatori di creare soluzioni di servizio Web interoperabili tra più piattaforme, linguaggi di programmazione e applicazioni. Uno dei modi principali per confermare questa interoperabilità esiste e che le specifiche dei servizi Web stanno fornendo su questi obiettivi aziendali, è attraverso workshop di interoperabilità del protocollo.

Workshop sul protocollo dei servizi Web

I workshop sul protocollo dei servizi Web sono un modo per coinvolgere la community dei servizi Web (incluse le società degli utenti finali, gli ISV e altri fornitori) nel processo di convalida e affinamento delle specifiche WS-*. Esistono due tipi di workshop: feedback e interoperabilità. I workshop di feedback consentono all'autore di ogni protocollo di servizi Web di condividere informazioni di base sulla progettazione e ricevere feedback dai partecipanti sulla praticità dell'implementazione. I workshop di interoperabilità si svolgono per gli stessi motivi e consentono inoltre alle aziende di testare l'interoperabilità della loro implementazione con altri partecipanti al workshop.

Dopo che tutti i commenti e i risultati dell'implementazione sono stati raccolti dai workshop, gli autori aggiornano e affinano la specifica per l'invio a un'organizzazione che imposta gli standard.

Workshop di interoperabilità del profilo richiedente passivo WS-Federation

Il 29 marzo e il 30 marzo 2004, gli autori della specifica del profilo del richiedente passivo WS-Federation hanno ospitato un workshop di interoperabilità di due giorni nel campus Microsoft a Redmond, Washington.

Il workshop di due giorni è stato un forum aperto per le aziende che hanno implementazioni basate sulla specifica WS-Federation pubblicata l'8 luglio 2003 e il WS-Federation Profilo richiedente passivo, pubblicato anche l'8 luglio 2003. È stato fornito un documento di scenario prima che l'evento e i partecipanti siano stati invitati a testare le implementazioni dello scenario con implementazioni di altre aziende. I partecipanti al workshop includono IBM Corporation, Microsoft Corporation, Netegrity Inc., Oblix Inc., OpenNetwork Corporation, Ping Identity Corporation e RSA Security Inc. Altre informazioni su questo e altri workshop sul protocollo dei servizi Web sono disponibili in MSDN.

specifica WS-Federation

La specifica WS-Federation fa parte del set di specifiche di sicurezza dei servizi Web. Definisce un modello e un set di messaggi per la brokeratura dell'attendibilità e la federazione delle informazioni di identità e autenticazione in aree di autenticazione diverse.

La specifica WS-Federation identifica due origini di richieste di identità e autenticazione tra aree di autenticazione: i richiedenti attivi, ad esempio le applicazioni abilitate per SOAP, e i richiedenti passivi definiti come browser HTTP in grado di supportare su larga scala HTTP (ad esempio, HTTP 1.1).

Profilo richiedente passivo WS-Federation

Il WS-Federation profilo richiedente passivo è un'implementazione di WS-Federation e propone un protocollo standard per il modo in cui i richiedenti passivi (ad esempio i Web browser) applicano il framework federativo. All'interno di questo protocollo, i richiedenti del servizio Web devono comprendere i nuovi meccanismi di sicurezza e poter interagire con i provider di servizi Web.

Interoperabilità del profilo richiedente passivo WS-Federation

Profilo di interoperabilità del richiedente passivo WS-Federation

Il profilo di interoperabilità del richiedente passivo WS-Federation è un ulteriore vincolo per il profilo richiedente passivo con lo scopo di offrire maggiori garanzie di interoperabilità. Il profilo definisce uno standard per la richiesta, lo scambio e l'emissione di token di sicurezza all'interno del contesto di un richiedente passivo tramite SAML (Security Assertion Markup Language) come tipo di token.

Il profilo di interoperabilità del richiedente passivo WS-Federation è stato creato e distribuito ai partecipanti prima del workshop come guida alla creazione di implementazioni interoperabili del profilo richiedente passivo WS-Federation. Per testare il protocollo consigliato, i fornitori hanno collaborato alla creazione di uno scenario di implementazione. Questo scenario riflette la necessità comune per le organizzazioni di esternalizzare servizi, ad esempio vantaggi, a terze parti, ma fornire l'accesso branded al servizio tramite un sito Web interno (il richiedente passivo in questo scenario).

Scenario di interoperabilità

Nello scenario per il workshop di interoperabilità, un'azienda, My Employer (ME), esternalizza la gestione dei vantaggi dei dipendenti a terze parti, Benefits Company (BC). My Employer and Benefits Company hanno stabilito fiducia e criteri per una federazione aziendale. Nell'ambito del coordinamento della federazione aziendale con Benefits Company, il mio datore di lavoro accetta di inviare determinati attributi specifici dell'utente, insieme alla richiesta di risorsa a Benefits Company. L'applicazione di gestione dei vantaggi in Benefits Company richiede che questi attributi esistano prima di visualizzare la risorsa specifica richiesta dal dipendente in My Employer.The benefits management application at Benefits Company requires these attributes to exist before displaying the specific resource the employee at My Employer has requested.

L'obiettivo di questo scenario è stato tre volte:

  • Illustrare una federazione business-to-business tra un'organizzazione e un provider di servizi di terze parti consentendo a ME di esternalizzare la gestione dei vantaggi dei dipendenti.
  • Testare l'interoperabilità tra diverse soluzioni fornitore create usando gli standard descritti nel profilo del richiedente passivo WS-Federation.
  • Realizzare il vantaggio di una federazione aziendale tramite:
    • Eliminando la necessità di BC per gestire le identità e le password per i dipendenti di ME per amministrare i vantaggi.
    • Fornire l'accesso Single Sign-On (Web Single Sign On) attendibile per i dipendenti me al dominio BC.

Procedura dettagliata dello scenario

Un dipendente me è al lavoro e accede a una pagina del portale dei vantaggi interni. Se il dipendente non ha ancora eseguito l'accesso al proprio dominio all'indirizzo ME, deve farlo prima di poter accedere alla pagina del portale dei vantaggi. La pagina del portale dei vantaggi visualizza le informazioni pertinenti al singolo utente o all'utente corrente e include collegamenti per gestire i vantaggi dell'utente.

Il dipendente fa clic sul collegamento di gestione dei vantaggi e viene autenticato nell'azienda benefit usando le credenziali fornite in precedenza per l'autenticazione nella pagina del portale dei vantaggi me.

Il dipendente viene presentato con una "pagina di benvenuto" personalizzata dall'applicazione di gestione dei vantaggi che fornisce informazioni personalizzate sulle scelte dei vantaggi del dipendente.

In questo caso, un'implementazione effettiva dell'applicazione dei vantaggi consente a un dipendente di aggiornare le opzioni del piano di integrità e di fare clic su un collegamento per gestire il piano di integrità. Il dipendente mostra le diverse opzioni del piano di integrità disponibili e il costo di ogni piano. Il dipendente seleziona un nuovo piano di integrità e mostra il nuovo importo da dedurre da ogni assegno. Al dipendente viene chiesto di confermare la transazione.

Il dipendente conferma la selezione e torna alla "Pagina iniziale" personalizzata che ora visualizza le informazioni aggiornate sul piano di integrità.

Se il dipendente fa di nuovo clic sul collegamento al piano di integrità, vengono visualizzati i dettagli del piano di integrità scelto e hanno la possibilità di modificare la propria scelta prima della fine del periodo di registrazione.

Dopo aver completato la transazione, il dipendente fa clic su un collegamento di disconnessione nel sito BC e viene trasferito di nuovo a un portale interno in ME che visualizza la conferma che il dipendente è stato disconnesso dall'applicazione Benefit Company.

Risultati e discussione del workshop

Il workshop di interoperabilità del profilo del richiedente passivo WS-Federation ha dimostrato elevati livelli di interoperabilità tra tutte le implementazioni di tutti i fornitori partecipanti e questo è stato raggiunto molto più rapidamente del previsto e con un minor numero di problemi, che è un chiaro segno della crescente maturità di queste implementazioni.

I clienti che implementano i servizi Web oggi vogliono sapere che le applicazioni sono conformi agli standard esistenti e sono in grado di interoperabilità con altri prodotti che supportano i servizi Web. Le implementazioni dello scenario di interoperabilità testate nel workshop hanno dimostrato l'interoperabilità tra tutte le soluzioni del fornitore.

Fornire un modello completo, coerente ed estendibile per i servizi Web e Federated Identity Management richiede sforzi coordinati da fornitori di piattaforme, sviluppatori di applicazioni, provider di rete e infrastruttura e clienti. Eventi come il recente WS-Federation Workshop di interoperabilità del profilo del richiedente passivo promuovono un ampio coinvolgimento del settore nell'evoluzione degli standard dei servizi Web e garantiscono ai clienti, agli sviluppatori e ai fornitori protocolli collaudati per la creazione di servizi Web coerenti, affidabili e interoperabili tra piattaforme, applicazioni e linguaggi di programmazione.

L'interoperabilità è e continuerà a essere un fattore crescente nelle decisioni dei clienti relative alle implementazioni dei servizi Web. Per supportare l'interoperabilità nell'implementazione dei servizi Web, Microsoft consiglia di:

  • Seguire i protocolli di implementazione dei servizi Web stabiliti. Le specifiche dei servizi Web e il supporto aggiuntivo per lo sviluppo e l'implementazione dei servizi Web sono disponibili in MSDN Web Services Developer Center.
  • Partecipare ai prossimi workshop di feedback e interoperabilità sui servizi Web. Fare clic per ottenere altre informazioni workshop.
  • Acquisire familiarità con le linee guida per l'interoperabilità WS-I. Altre informazioni sulle linee guida e altre risorse per sviluppatori WS-I sono disponibili all'indirizzo http://www.ws-i.org/.
  • Usare gli strumenti di test WS-I per verificare che l'applicazione servizi Web sia conforme alle linee guida per l'interoperabilità WS-I.

Il set di specifiche di sicurezza dei servizi Web offre una soluzione completa per Federated Identity Management, consentendo comunicazioni sicure ed efficienti e collaborazione tra organizzazioni e utenti esterni. La creazione di soluzioni interoperabili basate sugli standard di sicurezza WS accelera ulteriormente l'adozione di Federated Identity Management e consente ai clienti di implementare soluzioni di servizi Web con costi e rischi di implementazione ridotti.

Per altre informazioni, vedere le risorse seguenti:

© 2004 Microsoft Corporation. Tutti i diritti sono riservati.

Questo è un documento preliminare e può essere modificato notevolmente nel tempo. Le informazioni contenute in questo documento rappresentano la posizione attuale di Microsoft Corporation sulle problematiche trattate alla data di pubblicazione. Poiché Microsoft deve rispondere alle condizioni di mercato mutevoli, non deve essere interpretato come un impegno da parte di Microsoft e Microsoft non può garantire l'accuratezza di tutte le informazioni presentate dopo la data di pubblicazione.

La presentazione, la distribuzione o l'altra diffusione delle informazioni contenute in questo documento non è una licenza, espressamente o implicitamente, a qualsiasi proprietà intellettuale o controllata da Microsoft e\o da qualsiasi altra terza parte. Microsoft e\o qualsiasi altra terza parte può avere brevetti, brevetti, marchi, copyright o altri diritti di proprietà intellettuale che coprono la materia in questo documento. L'arredamento di questo documento non concede alcuna licenza a Microsoft o a qualsiasi altra terza parte di brevetti, marchi, copyright o altre proprietà intellettuale. Le società, le organizzazioni, i prodotti, i nomi di dominio, gli indirizzi di posta elettronica, i loghi, le persone, i luoghi e gli eventi di esempio qui riportati sono fittizi. Nessuna associazione con nessuna società, organizzazione, prodotto, nome di dominio, indirizzo di posta elettronica, logo, persona, luogo o evento è intenzionale o può essere presupposta.

Questo documento e le informazioni contenute nel presente documento vengono fornite in base a "AS IS" e al massimo limite consentito dalla legge applicabile, Microsoft fornisce il documento AS IS E WITH ALL FAULTS e di conseguenza disclaime tutte le altre garanzie e condizioni, sia esplicite, implicite o legali, incluse, ma non limitate a, qualsiasi garanzia implicita (se presente) implicita, compiti o condizioni di commerciabilità, di idoneità per uno scopo particolare, di accuratezza o completezza delle risposte, dei risultati, del lavoro, della mancanza di virus e di mancanza di negligenza, tutto per quanto riguarda il documento. INOLTRE, NON VI È ALCUNA GARANZIA O CONDIZIONE DI TITOLO, QUIET GODIMENTO, QUIET POSSESSO, CORRISPONDENZA A DESCRIZIONE O NON VIOLAZIONE DEI DIRITTI DI PROPRIETÀ INTELLETTUALE PER QUANTO RIGUARDA IL DOCUMENTO.

IN NESSUN CASO MICROSOFT SARÀ RESPONSABILE DI QUALSIASI ALTRA PARTE PER IL COSTO DI ACQUISTO DI BENI O SERVIZI SOSTITUTIVI, PROFITTI PERSI, PERDITA DI UTILIZZO, PERDITA DI DATI, CONSEQUENZIALI, INDIRETTI, INDIRETTI O DANNI SPECIALI SE SOTTO CONTRATTO, TORT, GARANZIA O ALTRIMENTI, DERIVANTI IN ALCUN MODO DA QUESTO O QUALSIASI ALTRO CONTRATTO RELATIVO A QUESTO DOCUMENTO, INDIPENDENTEMENTE DAL FATTO CHE TALE PARTE ABBIA RICEVUTO UNA NOTIFICA ANTICIPATA DELLA POSSIBILITÀ DI TALI DANNI.

Microsoft e Microsoft Web Services sono marchi o marchi registrati di Microsoft Corporation nei Stati Uniti e/o in altri paesi.

I nomi di società e prodotti reali citati nel presente documento possono essere marchi dei rispettivi proprietari.

  • Last updated on