Scenario di delega delle identità con AD FS

  • Articolo

[A partire da .NET Framework 4.5, Windows Identity Foundation (WIF) è stato completamente integrato in .NET Framework. La versione di WIF affrontata da questo argomento, WIF 3.5, è deprecata e deve essere usata solo durante lo sviluppo con .NET Framework 3.5 SP1 o .NET Framework 4. Per ulteriori informazioni su WIF in .NET Framework 4.5, noto anche come WIF 4.5, vedere la documentazione di Windows Identity Foundation nella Guida di sviluppo di .NET Framework 4.5.

Questo scenario descrive un'applicazione che deve accedere alle risorse back-end che richiedono la catena di delega di identità per eseguire la verifica sul controllo dell'accesso. Una semplice catena di delega di identità è in genere costituita dalle informazioni sul chiamante iniziale e sull'identità del chiamante immediato.

Con il modello di delega Kerberos nella piattaforma Windows, oggi le risorse back-end hanno accesso solo all'identità del chiamante immediato e non a quella del chiamante iniziale. Questo modello viene comunemente definito modello di sottosistema attendibile. WIF mantiene l'identità del chiamante iniziale e del chiamante immediato nella catena di delega usando la proprietà Attore.

Il diagramma seguente illustra uno scenario tipico di delega di identità in cui un dipendente di Fabrikam accede alle risorse esposte in un'applicazione Contoso.com.

Identity

Gli utenti fittizi che partecipano a questo scenario sono:

  • Frank: dipendente di Fabrikam che vuole accedere alle risorse di Contoso.
  • Daniel: sviluppatore di applicazioni Contoso che implementa le modifiche necessarie nell'applicazione.
  • Adam: amministratore IT di Contoso.

I componenti coinvolti in questo scenario sono:

  • web1: un'applicazione Web con collegamenti a risorse back-end che richiedono l'identità delegata del chiamante iniziale. Questa applicazione viene compilata con ASP.NET.
  • Servizio Web che accede a SQL Server, che richiede l'identità delegata del chiamante iniziale, insieme a quella del chiamante immediato. Questo servizio viene compilato con WCF.
  • sts1: servizio token di sicurezza nel ruolo di provider di attestazioni che genera le attestazioni previste dall'applicazione (web1). Ha instaurato una relazione di trust con Fabrikam.com e anche con l'applicazione.
  • sts2: servizio token di sicurezza nel ruolo di provider di identità per Fabrikam.com che fornisce un punto finale usato dal dipendente Fabrikam per l'autenticazione. Ha instaurato una relazione di Trust con Contoso.com in modo che i dipendenti di Fabrikam siano autorizzati ad accedere alle risorse in Contoso.com.

Nota

Il termine "token ActAs", usato spesso in questo scenario, fa riferimento a un token emesso da un servizio token di sicurezza che contiene l'identità dell'utente. La proprietà Attore contiene l'identità del servizio token di sicurezza.

Come illustrato nel diagramma precedente, il flusso in questo scenario è:

  1. L'applicazione Contoso è configurata per ottenere un token ActAs che contiene sia l'identità del dipendente Fabrikam che l'identità del chiamante immediato nella proprietà Attore. Daniel ha implementato queste modifiche nell'applicazione.
  2. L'applicazione Contoso è configurata per passare il token ActAs al servizio back-end. Daniel ha implementato queste modifiche nell'applicazione.
  3. Il servizio Web Contoso è configurato per convalidare il token ActAs chiamando sts1. Adam ha abilitato sts1 per elaborare le richieste di delega.
  4. Frank, l'utente di Fabrikam, accede all'applicazione Contoso e ha accesso alle risorse back-end.

Configurare il provider di identità (IP)

Sono disponibili tre opzioni per l'amministratore Fabrikam.com, Frank:

  1. Acquistare e installare un prodotto STS, ad esempio Active Directory® Federation Services (AD FS).
  2. Abbonarsi a un prodotto STS cloud, ad esempio LiveID STS.
  3. Creare un servizio token di sicurezza personalizzato usando WIF.

Per questo scenario di esempio, si presuppone che Frank selezioni option1 e installi AD FS come IP-STS. Configura anche un endpoint, denominato \windowsauth, per autenticare gli utenti. Facendo riferimento alla documentazione del prodotto AD FS e parlando con Adam, l'amministratore IT di Contoso, Frank, stabilisce una relazione di trust con il dominio Contoso.com.

Configurare il provider di attestazioni

Le opzioni disponibili per l'amministratore Contoso.com, Adam, sono le stesse descritte in precedenza per il provider di identità. Per questo scenario di esempio, si presuppone che Adam selezioni option1 e installi AD FS 2.0 come RP-STS.

Configurare la relazione di trust con l'indirizzo IP e l'applicazione

Facendo riferimento alla documentazione di AD FS, Adam stabilisce una relazione di trust tra Fabrikam.com e l'applicazione.

Configurare la delega

AD FS fornisce l'elaborazione della delega. Facendo riferimento alla documentazione di AD FS, Adam abilita l'elaborazione dei token ActAs.

Modifiche specifiche dell'applicazione

Per aggiungere il supporto per la delega delle identità a un'applicazione esistente, è necessario apportare le modifiche seguenti. Daniel usa WIF per apportare queste modifiche.

  • Memorizzare nella cache il token bootstrap che web1 ha ricevuto da sts1.
  • Usare CreateChannelActingAs con il token rilasciato per creare un canale per il servizio Web back-end.
  • Chiamare il metodo del servizio back-end.

Memorizzare nella cache il token bootstrap

Il token bootstrap è il token iniziale rilasciato dal servizio token di sicurezza e l'applicazione estrae le attestazioni da esso. In questo scenario di esempio questo token viene rilasciato da sts1 per l'utente Frank e l'applicazione lo memorizza nella cache. L'esempio di codice seguente illustra come recuperare un token bootstrap in un'applicazione ASP.NET:

// Get the Bootstrap Token
SecurityToken bootstrapToken = null;

IClaimsPrincipal claimsPrincipal = Thread.CurrentPrincipal as IClaimsPrincipal;
if ( claimsPrincipal != null )
{
    IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity;
    bootstrapToken = claimsIdentity.BootstrapToken;
}

WIF fornisce un metodo, CreateChannelActingAs, che crea un canale del tipo specificato che aumenta le richieste di rilascio dei token con il token di sicurezza specificato come elemento ActAs. È possibile passare il token bootstrap a questo metodo e quindi chiamare il metodo di servizio necessario nel canale restituito. In questo scenario di esempio, l'identità di Frank ha la proprietà Actor impostata sull'identità di web1.

Il frammento di codice seguente illustra come chiamare il servizio Web con CreateChannelActingAs e quindi chiamare uno dei metodi del servizio, ComputeResponse, nel canale restituito:

// Get the channel factory to the backend service from the application state
ChannelFactory<IService2Channel> factory = (ChannelFactory<IService2Channel>)Application[Global.CachedChannelFactory];

// Create and setup channel to talk to the backend service
IService2Channel channel;
lock (factory)
{
// Setup the ActAs to point to the caller's token so that we perform a
// delegated call to the backend service
// on behalf of the original caller.
    channel = factory.CreateChannelActingAs<IService2Channel>(callerToken);
}

string retval = null;

// Call the backend service and handle the possible exceptions
try
{
    retval = channel.ComputeResponse(value);
    channel.Close();
} catch (Exception exception)
{
    StringBuilder sb = new StringBuilder();
    sb.AppendLine("An unexpected exception occurred.");
    sb.AppendLine(exception.StackTrace);
    channel.Abort();
    retval = sb.ToString();
}

Modifiche specifiche del servizio Web

Poiché il servizio Web viene compilato con WCF e abilitato per WIF, dopo che l'associazione è configurata con IssuedSecurityTokenParameters con l'indirizzo dell'emittente appropriato, la convalida di ActA viene gestita automaticamente da WIF.

Il servizio Web espone i metodi specifici necessari per l'applicazione. Non sono necessarie modifiche specifiche al codice nel servizio. L'esempio di codice seguente illustra la configurazione del servizio Web con IssuedSecurityTokenParameters:

// Configure the issued token parameters with the correct settings
IssuedSecurityTokenParameters itp = new IssuedSecurityTokenParameters( "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" );
itp.IssuerMetadataAddress = new EndpointAddress( "http://localhost:6000/STS/mex" );
itp.IssuerAddress = new EndpointAddress( "http://localhost:6000/STS" );

// Create the security binding element
SecurityBindingElement sbe = SecurityBindingElement.CreateIssuedTokenForCertificateBindingElement( itp );
sbe.MessageSecurityVersion = MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10;

// Create the HTTP transport binding element
HttpTransportBindingElement httpBE = new HttpTransportBindingElement();

// Create the custom binding using the prepared binding elements
CustomBinding binding = new CustomBinding( sbe, httpBE );

using ( ServiceHost host = new ServiceHost( typeof( Service2 ), new Uri( "http://localhost:6002/Service2" ) ) )
{
    host.AddServiceEndpoint( typeof( IService2 ), binding, "" );
    host.Credentials.ServiceCertificate.SetCertificate( "CN=localhost", StoreLocation.LocalMachine, StoreName.My );

// Enable metadata generation via HTTP GET
    ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
    smb.HttpGetEnabled = true;
    host.Description.Behaviors.Add( smb );
    host.AddServiceEndpoint( typeof( IMetadataExchange ), MetadataExchangeBindings.CreateMexHttpBinding(), "mex" );

// Configure the service host to use WIF
    ServiceConfiguration configuration = new ServiceConfiguration();
    configuration.IssuerNameRegistry = new TrustedIssuerNameRegistry();

    FederatedServiceCredentials.ConfigureServiceHost( host, configuration );

    host.Open();

    Console.WriteLine( "Service2 started, press ENTER to stop ..." );
    Console.ReadLine();

    host.Close();
}

Passaggi successivi

Sviluppo di AD FS