Condividi tramite

Federazione

  • Articolo

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 automatica Contoso Ltd vuole consentire ai dipendenti autorizzati del cliente Fabrikam Inc di accedere in modo sicuro ai componenti di Contoso order Web Service. Una soluzione di sicurezza per questo scenario consiste nel configurare un meccanismo di attendibilità con Fabrikam per delegare la decisione di autorizzazione di accesso a Fabrikam. Questo processo può funzionare nel modo seguente:

  • Fabrikam, quando diventa partner di Contoso, configura un contratto di trust con Contoso. L'obiettivo di questo passaggio è concordare il tipo di token di sicurezza e il contenuto che rappresenteranno l'autorizzazione di Fabrikam e saranno accettabili 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 tale SAML da accettare dal servizio Web Contoso. Inoltre, può essere deciso che l'attestazione di sicurezza nel token SAML rilasciato deve essere 'https://schemas.contoso.com/claims/lookup' (per l'autorizzazione di ricerca parte) o 'https://schemas.contoso.com/claims/order' (per l'autorizzazione di ordinamento parte).
  • Quando un dipendente di Fabrikam usa l'applicazione di ordinamento delle parti interne, contatta innanzitutto 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 del dominio Windows), l'autorizzazione per ordinare le parti viene verificata e viene emesso 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, il servizio token di sicurezza di Fabrikam funge da "entità emittente" e il servizio parti contoso funge da "relying party". Diagramma che mostra un'entità emittente e una relying party in una federazione.

Funzionalità di 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 token di sicurezza, è possibile usare funzione di WsRequestSecurityToken. In alternativa, è possibile usare una libreria del provider di token di sicurezza lato client, ad esempio CardSpace o LiveID, e quindi usare il relativo output per creare localmente un token di sicurezza usando WsCreateXmlSecurityToken. In entrambi i casi, una volta che il client ha il token di sicurezza, può creare un canale per il 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 emette 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.
  • StS-side: si noti che il servizio token di sicurezza è un'applicazione del servizio Web e può specificare i requisiti di sicurezza per coloro che richiedono un token di sicurezza tramite una descrizione di sicurezza struttura al momento della creazione del listener esattamente come qualsiasi altro servizio Web sicuro. Può quindi analizzare i payload dei messaggi di richiesta in ingresso per convalidare le richieste di token e inviare i token rilasciati come payload del messaggio di risposta. Attualmente, non sono disponibili funzionalità per facilitare l'analisi e l'esecuzione 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 comprenderlo 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 di federazione può includere più stS che formano una catena federativa. Si consideri l'esempio seguente:

  • Il client esegue l'autenticazione al servizio token 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, il servizio token di sicurezza LiveID, STS1, STS2 e S formano la catena di federazione. Il servizio token di sicurezza in una catena di federazione può eseguire diversi ruoli per lo scenario dell'applicazione generale. Esempi di tali ruoli funzionali del servizio token di sicurezza includono provider di identità, decision maker di autorizzazione, anonimizzatore e resource manager.

Parametri della richiesta STS e scambio di metadati

Affinché il client esequisire una chiamata WsRequestSecurityToken, deve conoscere i parametri di tale chiamata (ad esempio il tipo di token e i tipi di attestazione necessari), la descrizione di sicurezzarequisiti del canale di richiesta al servizio token di sicurezza e l'indirizzo dell'endpoint del servizio token di sicurezza. L'applicazione client può usare una delle tecniche seguenti per determinare queste informazioni:

  • Hardcoded le informazioni nell'applicazione come parte delle decisioni in fase di progettazione.
  • Leggere queste informazioni da un file di configurazione a livello di applicazione configurato dal deployer dell'applicazione locale.
  • Individuare in modo dinamico 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 la 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 tali informazioni per eseguire un MEX dinamico con STS2 per individuare informazioni su T2 e STS1 e così via.

Di conseguenza, i passaggi MEX dinamici si svolgono nell'ordine 4, 3, 2, 1 per creare la catena di federazione e i passaggi di richiesta e presentazione del token vengono completare 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.