Scenario di delega delle identità con AD FS

[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 altre informazioni su WIF in .NET Framework 4.5, noto anche come WIF 4.5, vedere la documentazione di Windows Identity Foundation nella Guida allo sviluppo di .NET Framework 4.5.

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

Con il modello di delega Kerberos nella piattaforma Windows, 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 successivo nella sequenza di delega usando la proprietà Actor.

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

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: An STS that is in the role of claims provider, and emits claims that are expected by the application (web1). Ha stabilito la fiducia con Fabrikam.com e anche con l'applicazione.
• sts2: un STS che è nel ruolo di provider di identità per Fabrikam.com e che fornisce un endpoint utilizzato dal dipendente di Fabrikam per autenticarsi. Ha stabilito 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 STS e contiene l'identità dell'utente. The Actor property contains the STS's identity.

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à Actor. Daniel ha implementato queste modifiche all'applicazione.
2. L'applicazione Contoso è configurata per passare il token ActAs al servizio back-end. Daniel ha implementato queste modifiche all'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. L'utente di Fabrikam Frank accede all'applicazione Contoso e ha accesso alle risorse back-end.

Set Up the Identity Provider (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. Build a custom STS using 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.

Set Up the Claims Provider

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 l'opzione 1 e installi AD FS 2.0 come RP-STS.

Configurare l'attendibilità 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.

Set Up Delegation

AD FS provides delegation processing. Facendo riferimento alla documentazione di AD FS, Adam abilita l'elaborazione dei token ActAs.

Application-Specific Changes

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.
• Call the back-end service's method.

Memorizzare nella cache il token bootstrap

The bootstrap token is the initial token issued by the STS, and the application extracts claims from it. 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 this sample scenario, Frank's identity has the Actor property set to web1's identity.

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();
}

Web Service-Specific Changes

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

Il servizio Web espone i metodi specifici necessari per l'applicazione. Non sono necessarie modifiche al codice specifiche 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

AD FS Development