Scénario de délégation d’identité avec AD FS

[À compter du .NET Framework 4.5, Windows Identity Foundation (WIF) est entièrement intégré au .NET Framework. La version de WIF traitée par cette rubrique, WIF 3.5, est déconseillée et ne doit être utilisée que lors du développement sur .NET Framework 3.5 SP1 ou .NET Framework 4. Pour plus d’informations sur WIF dans .NET Framework 4.5, également appelé WIF 4.5, consultez la documentation de Windows Identity Foundation dans le Guide de développement .NET Framework 4.5.]

Ce scénario décrit une application qui doit accéder aux ressources back-end qui nécessitent la chaîne de délégation d’identité pour effectuer des vérifications de contrôle d’accès. Une chaîne de délégation d’identité simple se compose généralement des informations sur l’appelant initial et de l’identité de l’appelant immédiat.

Avec le modèle de délégation Kerberos sur la plateforme Windows aujourd’hui, les ressources back-end ont accès uniquement à l’identité de l’appelant immédiat et non à celle de l’appelant initial. Ce modèle est communément appelé modèle de sous-système approuvé. WIF conserve l’identité de l’appelant initial ainsi que de l’appelant immédiat dans la chaîne de délégation à l’aide de la propriété Actor.

Le diagramme suivant illustre un scénario de délégation d’identité classique dans lequel un employé Fabrikam accède aux ressources exposées dans une application Contoso.com.

Les utilisateurs fictifs participant à ce scénario sont les suivants :

• Frank : Un employé Fabrikam qui souhaite accéder aux ressources Contoso.
• Daniel : Développeur d’applications Contoso qui implémente les modifications nécessaires dans l’application.
• Adam : Administrateur informatique de Contoso.

Les composants impliqués dans ce scénario sont les suivants :

• web1 : application web avec des liens vers des ressources back-end qui nécessitent l’identité déléguée de l’appelant initial. Cette application est générée avec ASP.NET.
• Service Web qui accède à un SQL Server, qui nécessite l’identité déléguée de l’appelant initial, ainsi que celle de l’appelant immédiat. Ce service est créé avec WCF.
• sts1 : STS qui joue le rôle de fournisseur de revendications et émet des revendications attendues par l’application (web1). Il a établi l’approbation avec Fabrikam.com et avec l’application.
• sts2 : STS qui joue le rôle de fournisseur d’identité pour Fabrikam.com et fournit un point de terminaison que l’employé Fabrikam utilise pour s’authentifier. Il a établi une relation de confiance avec Contoso.com afin que les employés de Fabrikam soient autorisés à accéder aux ressources sur Contoso.com.

Comme indiqué dans le diagramme précédent, le flux dans ce scénario est le suivant :

1. L’application Contoso est configurée pour obtenir un jeton ActAs qui contient à la fois l’identité de l’employé Fabrikam et l’identité de l’appelant immédiat dans la propriété Actor. Daniel a implémenté ces modifications dans l’application.
2. L’application Contoso est configurée pour passer le jeton ActAs au service principal. Daniel a implémenté ces modifications dans l’application.
3. Le service Web Contoso est configuré pour valider le jeton ActAs en appelant sts1. Adam a permis à sts1 de traiter les demandes de délégation.
4. L’utilisateur Fabrikam Frank accède à l’application Contoso et a accès aux ressources back-end.

Définir le fournisseur d'identité (IP)

Il existe trois options disponibles pour l’administrateur Fabrikam.com, Frank :

1. Achetez et installez un produit STS tel que Active Directory® Federation Services (AD FS).
2. Abonnez-vous à un produit STS cloud tel que LiveID STS.
3. Créez un STS personnalisé à l’aide de WIF.

Pour cet exemple de scénario, nous partons du principe que Frank sélectionne option1 et installe AD FS comme IP-STS. Il configure également un point de terminaison, nommé \windowsauth, pour authentifier les utilisateurs. En se référant à la documentation du produit AD FS et en discutant avec Adam, l’administrateur informatique de Contoso, Frank établit l’approbation avec le domaine Contoso.com.

Configurer le fournisseur de revendications

Les options disponibles pour l’administrateur Contoso.com, Adam, sont les mêmes que celles décrites précédemment pour le fournisseur d’identité. Pour cet exemple de scénario, nous partons du principe qu’Adam sélectionne l’option 1 et installe AD FS 2.0 en tant que RP-STS.

Configurer l’approbation avec l’adresse IP et l’application

En se référant à la documentation AD FS, Adam établit une relation de confiance entre Fabrikam.com et l’application.

Configurer la délégation

AD FS fournit le traitement de la délégation. En se référant à la documentation AD FS, Adam active le traitement des jetons ActAs.

Étiquette spécifique de l’application

Les modifications suivantes doivent être apportées pour ajouter la prise en charge de la délégation d’identité à une application existante. Daniel utilise WIF pour apporter ces modifications.

• Mettez en cache le jeton de démarrage que web1 a reçu de sts1.
• Utilisez CreateChannelActingAs avec le jeton émis pour créer un canal vers le service Web principal.
• Appelez la méthode du service principal.

Mettre en cache le jeton de démarrage

Le jeton d’amorçage est le jeton initial émis par le STS, et l’application en extrait les revendications. Dans cet exemple de scénario, ce jeton est émis par sts1 pour l’utilisateur Frank et l’application le met en cache. L’exemple de code suivant montre comment récupérer un jeton de démarrage dans une application 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 fournit une méthode, CreateChannelActingAs, qui crée un canal du type spécifié qui augmente les demandes d’émission de jetons avec le jeton de sécurité spécifié en tant qu’élément ActAs. Vous pouvez passer le jeton de démarrage à cette méthode, puis appeler la méthode de service nécessaire sur le canal retourné. Dans cet exemple de scénario, l’identité de Frank a la propriété Actor définie sur l’identité de web1.

L’extrait de code suivant montre comment appeler le service web avec CreateChannelActingAs , puis comment appeler l’une des méthodes du service, ComputeResponse, sur le canal retourné :

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

Modifications de Service-Specific web

Étant donné que le service Web est généré avec WCF et activé pour WIF, une fois la liaison configurée avec IssuedSecurityTokenParameters avec l’adresse de l’émetteur appropriée, la validation des ActAs est automatiquement gérée par WIF.

Le service Web expose les méthodes spécifiques requises par l’application. Aucune modification de code spécifique n’est nécessaire sur le service. L’exemple de code suivant montre la configuration du service Web avec 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();
}

Étapes suivantes

Développement des services AD FS