Federazione

In questo argomento viene illustrato brevemente il concetto di protezione federata. Viene inoltre descritto il supporto Windows Communication Foundation (WCF) per la distribuzione di architetture di protezione federata. Per un'applicazione di esempio sulla federazione, vedere Federation Sample.

Definizione di protezione federata

La protezione federata consente di separare con precisione il servizio al quale sta accedendo un client dalle procedure pertinenti di autenticazione e di autorizzazione. La protezione federata consente inoltre la collaborazione attraverso più sistemi, reti e organizzazioni in diverse aree di attendibilità.

WCF fornisce il supporto per creare e distribuire sistemi distribuiti che utilizzano la protezione federata.

Elementi di un'architettura di protezione federata

L'architettura di protezione federata è composta da tre elementi principali, come descritto nella tabella seguente.

Scenario di esempio

Nella figura seguente viene illustrato un esempio di protezione federata.

In questo scenario sono incluse due organizzazioni: A e B. L'organizzazione B ha una risorsa Web (un servizio Web) che alcuni utenti dell'organizzazione A ritengono preziosa.

L'organizzazione B richiede in genere che un utente dell'organizzazione A fornisca un tipo valido di autenticazione prima di accedere al servizio. Potrebbe inoltre richiedere che l'utente venga autorizzato ad accedere alla risorsa specifica in questione. Un modo per risolvere questo problema e consentire agli utenti dell'organizzazione A di accedere alla risorsa nell'organizzazione B è il seguente:

• Gli utenti dell'organizzazione A registrano le proprie credenziali (un nome utente e una password) presso l'organizzazione B.
• Durante l'accesso alla risorsa, gli utenti dell'organizzazione A presentano le proprie credenziali all'organizzazione B e vengono autenticati prima di accedere alla risorsa.

Questo approccio ha tre grandi inconvenienti:

• L'organizzazione B deve gestire le credenziali degli utenti dell'organizzazione A, oltre a quelle dei propri utenti locali.
• Gli utenti dell'organizzazione A devono mantenere un insieme aggiuntivo di credenziali (ovvero, ricordare un nome utente e una password in più), oltre a quelle normalmente utilizzate per accedere alle risorse all'interno dell'organizzazione A. Ciò incoraggia la pratica dell'utilizzo dello stesso nome utente e della stessa password in più siti del servizio, il che non è una misura efficace di protezione.
• L'architettura non si adatta, in quanto più organizzazioni percepiscono la risorsa dell'organizzazione B come di un qualche valore.

Un approccio alternativo, che risolve gli inconvenienti menzionati in precedenza, consiste nell'utilizzare la protezione federata. In questo approccio, le organizzazioni A e B stabiliscono una relazione di trust e utilizzano il servizio token di protezione (STS, Security Token Service) per consentire la negoziazione della relazione di trust stabilita.

In un'architettura di protezione federata, gli utenti dell'organizzazione A sanno che se vogliono accedere al servizio Web dell'organizzazione B devono presentare un token di protezione valido dall'STS dell'organizzazione B, che autentica e autorizza il loro accesso al servizio specifico.

Quando contattano l'STS B, gli utenti ricevono un altro livello di riferimento indiretto dal criterio associato a STS. Devono presentare un token di protezione valido da STS A (ovvero, l'area di attendibilità del client) prima che STS B possa rilasciare loro un token di protezione. Si tratta di un corollario della relazione di trust stabilita tra le due organizzazioni e implica che l'organizzazione B non deve gestire le identità degli utenti dell'organizzazione A. In pratica, STS B in genere ha issuerAddress e issuerMetadataAddress nulli. Per ulteriori informazioni, vedere Procedura: configurare un emittente locale. In quel caso, il client consulta un criterio locale per individuare STS A. Questa configurazione è chiamata federazione dell'area di autenticazione principale e si adatta meglio perché STS B non deve conservare informazioni su STS A.

Gli utenti contattano quindi l'STS dell'organizzazione A e ottengono un token di protezione presentando le credenziali di autenticazione che utilizzano normalmente per accedere a qualsiasi altra risorsa all'interno dell'organizzazione A. In tal modo, si evita loro di dover conservare più insiemi di credenziali o utilizzare lo stesso insieme di credenziali in più siti del servizio.

Una volta ottenuto un token di protezione da STS A, gli utenti lo presentano a STS B. L'organizzazione B procede per eseguire l'autorizzazione delle richieste degli utenti e rilascia loro un token di protezione preso dal proprio insieme di token di protezione. Gli utenti possono presentare quindi il proprio token alla risorsa dell'organizzazione B e accedere al servizio.

Supporto per la protezione federata in WCF

WCF fornisce un supporto chiavi in mano per la distribuzione di architetture di protezione federata tramite wsFederationHttpBinding element.

L'elemento wsFederationHttpBinding element offre un'associazione sicura, affidabile e interoperativa che comporta l'utilizzo di HTTP come meccanismo di trasporto sottostante per lo stile di comunicazione request/reply, utilizzando testo e XML come formato wire per la codifica.

L'utilizzo di wsFederationHttpBinding element in uno scenario di protezione federata può essere separato in due fasi logicamente indipendenti, come descritto nelle sezioni seguenti.

Fase 1: Progettazione

Durante la fase di progettazione, il client utilizza ServiceModel Metadata Utility Tool (Svcutil.exe) per leggere il criterio esposto dall'endpoint del servizio e raccogliere i requisiti di autenticazione e autorizzazione del servizio. Vengono costruiti proxy adatti per creare il modello di comunicazione di protezione federata seguente nel client:

• Ottenere un token di protezione da STS nell'area di attendibilità del client.
• Presentare il token a STS nell'area di attendibilità del servizio.
• Ottenere un token di protezione da STS nell'area di attendibilità del servizio.
• Presentare il token al servizio per accedere ad esso.

Fase 2: Runtime

Durante la fase runtime, il client crea un'istanza di un oggetto della classe client WCF e fa una chiamata utilizzando il client WCF. Il framework sottostante di WCF gestisce i passaggi menzionati in precedenza nel modello di comunicazione di protezione federata e consente al client di utilizzare facilmente il servizio.

Implementazione di esempio utilizzando WCF

Nella figura seguente viene illustrata un'implementazione di esempio per un'architettura di protezione federata utilizzando il supporto nativo da WCF.

Esempio MyService

Il servizio MyService espone un singolo endpoint tramite MyServiceEndpoint. Nella figura seguente vengono illustrati l'indirizzo, l'associazione e il contratto associati all'endpoint.

L'endpoint del servizio MyServiceEndpoint utilizza wsFederationHttpBinding element e richiede un token Security Assertions Markup Language (SAML) valido con un'attestazione accessAuthorized rilasciata da STS B. Questo è specificato in modo dichiarativo nella configurazione del servizio.

<system.serviceModel>
  <services>
    <service type="FederationSample.MyService"    
        behaviorConfiguration='MyServiceBehavior'>
        <endpoint address=""
            binding=" wsFederationHttpBinding"
            bindingConfiguration='MyServiceBinding'
            contract="Federation.IMyService" />
   </service>
  </services>

  <bindings>
    <wsFederationHttpBinding>
    <!-- This is the binding used by MyService. It redirects 
    clients to STS-B. -->
      <binding name='MyServiceBinding'>
        <security mode="Message">
           <message issuedTokenType=
"http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1">
           <issuer address="https://localhost/FederationSample/STS-B/STS.svc" />
            <issuerMetadata 
           address=
"https://localhost/FederationSample/STS-B/STS.svc/mex" />
         <requiredClaimTypes>
            <add claimType="http://tempuri.org:accessAuthorized" />
         </requiredClaimTypes>
        </message>
      </security>
      </binding>
    </wsFederationHttpBinding>
  </bindings>

  <behaviors>
    <behavior name='MyServiceBehavior'>
      <serviceAuthorization 
operationRequirementType="FederationSample.MyServiceOperationRequirement, MyService" />
       <serviceCredentials>
         <serviceCertificate findValue="CN=FederationSample.com"
         x509FindType="FindBySubjectDistinguishedName"
         storeLocation='LocalMachine'
         storeName='My' />
      </serviceCredentials>
    </behavior>
  </behaviors>
</system.serviceModel>

In fase di esecuzione, questo criterio viene imposto dalla classe MyServiceOperationRequirement implementata come parte di MyService.

STS B

Nella figura seguente viene illustrato STS B. Come dichiarato precedentemente, un servizio token di protezione (STS) è anche un servizio Web a cui possono essere associati endpoint, criterio e così via.

STS B espone un singolo endpoint, chiamato STSEndpoint che può essere utilizzato per richiedere token di protezione. Nello specifico, STS B rilascia token SAML con l'attestazione accessAuthorized, che può essere presentata al sito del servizio MyService per accedere al servizio. STS B richiede tuttavia che gli utenti presentino un token SAML valido rilasciato da STS A, contenente l'attestazione userAuthenticated. Questo è specificato in modo dichiarativo nella configurazione STS.

<system.serviceModel>
  <services>
    <service type="FederationSample.STS_B" behaviorConfiguration=
     "STS-B_Behavior">
    <endpoint address=""
              binding="wsFederationHttpBinding"
              bindingConfiguration='STS-B_Binding'
      contract="FederationSample.ISts" />
    </service>
  </services>
  <bindings>
    <wsFederationHttpBinding>
    <!-- This is the binding used by STS-B. It redirects clients to 
         STS-A. -->
      <binding name='STS-B_Binding'>
        <security mode='Message'>
          <message issuedTokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1">
          <issuer address='https://localhost/FederationSample/STS-A/STS.svc' />
          <issuerMetadata address='https://localhost/FederationSample/STS-A/STS.svc/mex'/>
          <requiredClaimTypes>
            <add claimType='http://tempuri.org:userAuthenticated'/>
          </requiredClaimTypes>
          </message>
        </security>
    </binding>
   </wsFederationHttpBinding>
  </bindings>
  <behaviors>
  <behavior name='STS-B_Behavior'>
    <serviceAuthorization   operationRequirementType='FederationSample.STS_B_OperationRequirement, STS_B' />
    <serviceCredentials>
      <serviceCertificate findValue='CN=FederationSample.com'
      x509FindType='FindBySubjectDistinguishedName'
       storeLocation='LocalMachine'
       storeName='My' />
     </serviceCredentials>
   </behavior>
  </behaviors>
</system.serviceModel>

In fase di esecuzione, questo criterio viene imposto dalla classe STS_B_OperationRequirement implementata come parte di STS B.

Se il controllo di accesso è chiaro, STS B rilascia un token SAML con l'attestazione accessAuthorized.

STS A

Nella figura seguente viene illustrato STS A.

Anche STS A, come STS B, è un servizio Web che rilascia token di protezione ed espone a tale fine un solo endpoint. Utilizza tuttavia un'associazione diversa (wsHttpBinding) e richiede che gli utenti presentino una CardSpace valida con un'attestazione emailAddress. In risposta, rilascia token SAML con l'attestazione userAuthenticated. Questo è specificato in modo dichiarativo nella configurazione del servizio.

<system.serviceModel>
  <services>
    <service type="FederationSample.STS_A" behaviorConfiguration="STS-A_Behavior">
      <endpoint address=""
                binding="wsHttpBinding"
                bindingConfiguration="STS-A_Binding"
                contract="FederationSample.ISts">
       <identity>
       <certificateReference findValue="CN=FederationSample.com"  
                       x509FindType="FindBySubjectDistinguishedName"
                       storeLocation="LocalMachine" 
                       storeName="My" />
       </identity>
    <endpoint>
  </service>
</services>

<bindings>
  <wsHttpBinding>
  <!-- This is the binding used by STS-A. It requires users to present
   a CardSpace. -->
    <binding name='STS-A_Binding'>
      <security mode='Message'>
        <message clientCredentialType="CardSpace" />
      </security>
    </binding>
  </wsHttpBinding>
</bindings>

<behaviors>
  <behavior name='STS-A_Behavior'>
    <serviceAuthorization operationRequirementType=
     "FederationSample.STS_A_OperationRequirement, STS_A" />
      <serviceCredentials>
  <serviceCertificate findValue="CN=FederationSample.com"
                     x509FindType='FindBySubjectDistinguishedName'
                     storeLocation='LocalMachine'
                     storeName='My' />
      </serviceCredentials>
    </behavior>
  </behaviors>
</system.serviceModel>

In fase di esecuzione, questo criterio viene imposto dalla classe STS_A_OperationRequirement implementata come parte di STS A.

Se l'accesso è true, STS A rilascia un token SAML con l'attestazione userAuthenticated.

Client nell'organizzazione A

Nella figura seguente viene illustrato il client nell'organizzazione A, insieme ai passaggi necessari per eseguire una chiamata al servizio MyService. A fini di completezza, sono inclusi anche gli altri componenti funzionali.

Riepilogo

La protezione federata offre una divisione netta della responsabilità e contribuisce a creare architetture del servizio sicure e scalabili. Come piattaforma per la creazione e distribuzione di applicazioni distribuite, WCF fornisce supporto nativo per implementare la protezione federata.

Vedere anche

Altre risorse

Funzionalità di protezione di Windows Communication Foundation