Federazione

La federazione consente la delega dell'autorità di autorizzazione ad altri membri di un interprise. Si consideri ad esempio il problema aziendale seguente: l'azienda di produzione di parti auto Contoso Ltd vuole consentire ai dipendenti autorizzati del cliente Fabrikam Inc di accedere in modo sicuro ai componenti di Contoso per l'ordine del servizio Web. Una soluzione di sicurezza per questo scenario consiste nel configurare un meccanismo di trust con Fabrikam per delegare la decisione di autorizzazione di accesso a Fabrikam. Questo processo può funzionare come indicato di seguito:

• Fabrikam, quando diventa partner di Contoso, configura un contratto di trust con Contoso. L'obiettivo di questo passaggio è quello di accettare il tipo di token di sicurezza e il contenuto che rappresenta l'autorizzazione di Fabrikam e sarà accettabile per Contoso. Ad esempio, potrebbe essere deciso che un certificato X.509 attendibile con nome soggetto "CN=Fabrikam Inc Supplier STS" deve firmare un token SAML per l'accettazione da parte del servizio Web Contoso. Inoltre, può essere deciso che l'attestazione di sicurezza nel token SAML rilasciato deve essere '' (per l'autorizzazione di ricerca parte) o 'https://schemas.contoso.com/claims/lookuphttps://schemas.contoso.com/claims/order' (per l'autorizzazione per l'ordinamento di parte).
• Quando un dipendente di Fabrikam usa l'applicazione di ordinamento delle parti interne, contatta prima un servizio token di sicurezza (STS) all'interno di Fabrikam. Tale dipendente viene autenticato usando il meccanismo di sicurezza interno di Fabrikam (ad esempio, nome utente/password di dominio Windows), l'autorizzazione per ordinare le parti viene verificata e viene rilasciato un token SAML di breve durata contenente le attestazioni appropriate e firmato dal certificato X.509 deciso in precedenza. L'applicazione di ordinamento delle parti contatta quindi il servizio Contoso che presenta il token SAML rilasciato per autenticare ed eseguire l'attività di ordinamento.

In questo caso, Fabrikam STS funge da "parti di emissione" e il servizio parti Contoso funge da "relying party".

Funzionalità della federazione

Di seguito sono riportate le funzionalità di sicurezza supportate per le parti o i ruoli coinvolti in uno scenario federativo:

• Lato client: per ottenere il token di sicurezza dal servizio di sicurezza, è possibile usare la funzione WsRequestSecurityToken . In alternativa, uno può usare una libreria del provider di token di sicurezza lato client, ad esempio CardSpace o LiveID, quindi usare il relativo output per creare in locale un token di sicurezza usando WsCreateXmlSecurityToken. In entrambi i casi, una volta che il client ha il token di sicurezza, può quindi creare un canale al servizio specificando WS_XML_TOKEN_MESSAGE_SECURITY_BINDING per presentare il token, insieme a un'associazione di sicurezza del trasporto, ad esempio WS_SSL_TRANSPORT_SECURITY_BINDING per proteggere il canale.
• Lato server: in uno scenario federativo con un servizio token di sicurezza che rilascia token SAML, il server può usare il WS_SAML_MESSAGE_SECURITY_BINDING, insieme a un'associazione di sicurezza del trasporto, ad esempio WS_SSL_TRANSPORT_SECURITY_BINDING per proteggere il canale.
• Lato STS: si noti che il servizio di sicurezza è un'applicazione del servizio Web e può specificare i requisiti di sicurezza per coloro che richiedono un token di sicurezza da esso usando una struttura di descrizione di sicurezza in fase di creazione del listener proprio come qualsiasi altro servizio Web sicuro. Può quindi analizzare i payload dei messaggi di richiesta in ingresso per convalidare le richieste del token e inviare token rilasciati come payload dei messaggi di risposta. Attualmente, nessuna funzionalità viene fornita per facilitare l'analisi e l'emissione di passaggi.

Si noti che il lato client può gestire il token di sicurezza rilasciato in modo generico come token di sicurezza XML senza conoscere il tipo di token o eseguire l'elaborazione specifica del tipo di token. Tuttavia, il server deve comprendere il tipo di token di sicurezza specifico per comprendere ed elaborarlo. I passaggi di richiesta e risposta del token di sicurezza usano i costrutti definiti nella specifica WS-Trust.

Scenari di federazione più complessi

Uno scenario federativo può comportare più stS che formano una catena federativa. Prendere in considerazione gli esempi seguenti:

• Il client esegue l'autenticazione al servizio di sicurezza LiveID usando un nome utente/password LiveID e ottiene un token di sicurezza T1.
• Il client esegue l'autenticazione a STS1 usando T1 e ottiene un token di sicurezza T2.
• Il client esegue l'autenticazione a STS2 usando T2 e ottiene un token di sicurezza T3.
• Il client esegue l'autenticazione al servizio di destinazione S usando T3.

In questo caso, liveID STS, STS1, STS2 e S formano la catena di federazione. I servizi di sicurezza del servizio di sicurezza in una catena federativa possono eseguire vari ruoli per lo scenario dell'applicazione generale. Esempi di tali ruoli funzionali del servizio di sicurezza includono provider di identità, decision maker di autorizzazione, anonimizzatore e resource manager.

Parametri di richiesta STS e Exchange metadati

Per consentire al client di eseguire una chiamata WsRequestSecurityToken riuscita, è necessario conoscere i parametri di tale chiamata, ad esempio il tipo di token e i tipi di attestazione necessari, i requisiti di descrizione di sicurezza del canale di richiesta al servizio di sicurezza e l'indirizzo endpoint del servizio di sicurezza del servizio di sicurezza. L'applicazione client può usare una delle tecniche seguenti per determinare queste informazioni:

• Codice rigido le informazioni nell'applicazione come parte delle decisioni relative al tempo di progettazione.
• Leggere queste informazioni da un file di configurazione a livello di applicazione configurato dal deployer dell'applicazione locale.
• Individuare dinamicamente queste informazioni in fase di esecuzione usando la funzionalità di importazione dei metadati con la struttura WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT .

Per illustrare l'uso di mex dinamico con federazione, prendere in considerazione l'esempio 3 STS precedente. Il client eseguirà prima di tutto un MEX dinamico con S per ottenere informazioni su T3 (ad esempio, cosa chiedere da STS2) e l'indirizzo MEX dinamico STS2 (ad esempio, dove trovare STS2). Userà quindi queste informazioni per eseguire un MEX dinamico con STS2 per individuare informazioni su T2 e STS1 e così via.

Pertanto, i passaggi dinamici del MEX si svolgono nell'ordine 4, 3, 2, 1 per compilare la catena federativa e i passaggi di richiesta e presentazione del token si svolgono nell'ordine 1, 2, 3, 4 per rimuovere la catena di federazione.

Nota

Windows 7 e Windows Server 2008 R2: WWSAPI supporta solo Ws-Trust e Ws-SecureConversation come definito da Lightweight Web Services Security Profile (LWSSP). Per informazioni dettagliate sull'implementazione di Microsoft, vedere la sezione Sintassi MESSAGE di LWSSP.