Exemple de scénario de délégation, de fédération et d’authentification dans SharePoint
Cet article fournit des exemples de scénarios de délégation d'identité et la fédération d'identité.
Exemples de scénarios
Les sociétés fictifs suivantes et leurs imposés à l'entreprise a besoin sont utilisés dans les exemples de scénarios qui sont décrites dans cet article :
Hybride de Contoso est une société internationale moteur automobile logistique spécialisée dans la fabrication des moteurs hybrides électrique et basée sur des cellules pour les fabricants de voiture à l'intérieur et en dehors des États-Unis. Dans un effort stratégique pour satisfaire les composants de l'ordre des demandes de ses clients, le service informatique de Contoso est chargé de développer et déployer des pièces accessibles sur Internet sécurisé classement application par le biais de leur nom d'hôte, Contoso.com. Cette application doit également fournir plusieurs niveaux d'accès pour différents utilisateurs internes (employés de Contoso) et les utilisateurs externes (employés du fabricant de voiture). Afin de réduire les coûts associés à la maintenance de l'application, l'ordre de composants informatiques doit également éviter la nécessité de l'application à utiliser et mettre à jour un magasin de comptes supplémentaires pour les utilisateurs internes et externes d'accéder à l'application.
Les moteurs de Fabrikam est un fabricant suédois de voitures compacte peu consommatrices de carburant et les petites voitures qui est connu dans le monde entier pour son point faible prix sur les automobiles hybride. Bien que les ventes ont accéléré constamment ans pour Fabrikam, il a été une amélioration notable des taux de défaillance du moteur hybride au sein de leur première année, en voitures vendus aux clients. Pour les moteurs de Fabrikam maintenir son standard pour hauts niveaux de service, il doit implémenter une méthode plus efficace pour les composants du moteur hybride à être commandés via hybride de Contoso.
Concepts connexes sont les suivantes :
Fédération des identités. Explique l'établissement de la fédération entre hybride de Contoso et Fabrikam auto afin que les utilisateurs de Fabrikam obtiennent une expérience d'authentification unique lorsqu'ils accèdent aux ressources hybrides de Contoso.
Délégation d'identité. Explique la possibilité d'accéder aux ressources d'un service web hybride de Contoso qui requiert un jeton ActAs ; en d'autres termes, le service nécessite l'identité de l'appelant immédiat (généralement, l'identité du service) et l'utilisateur d'origine qui a initié la demande (généralement, l'identité de l'utilisateur interactif).
Délégation d'identité
Ce scénario décrit une application qui doit accéder aux ressources principales qui nécessitent la chaîne de la délégation d'identité pour effectuer des vérifications de contrôle d'accès. Une chaîne de la délégation d'identité simple se compose généralement des informations sur l'appelant initial et l'identité de l'appelant immédiat.
Avec le modèle de délégation Kerberos sur la plateforme Windows aujourd'hui, les ressources de serveur principal ont uniquement accès à l'identité de l'appelant immédiat et non à celle de l'appelant initial. Ce modèle est communément appelé le modèle de sous-système approuvé. Windows Identity Foundation (WIF) conserve l’identité de l’appelant initial et de l’appelant immédiat dans la chaîne de délégation à l’aide de la propriété Delegate().
La figure 1 illustre un scénario de délégation des identités classique dans lequel un employé de Fabrikam accède aux ressources exposées dans une application de Contoso.com. Figure 1. Authentification de fédération des revendications
Les utilisateurs fictifs participent à ce scénario sont les suivants :
Frank : Un employé de Fabrikam souhaitant accéder à des ressources de Contoso.
Daniel : Un Contoso développeur d'application qui implémente les modifications nécessaires dans l'application.
ADAM : Contoso administrateur informatique.
Les composants impliqués dans ce scénario sont les suivants :
web1 : une application web avec des liens vers les ressources de serveur principal qui requièrent l'identité de l'appelant initial déléguée. Cette application est générée avec ASP.NET.
Un service web qui accède à un ordinateur exécutant Microsoft SQL Server, ce qui nécessite l'identité déléguée de l'appelant initial et de l'appelant immédiat. Ce service est généré avec Windows Communication Foundation (WCF).
STS1 : une forme de service de jeton de sécurité (STS) qui se trouve dans le rôle de fournisseur de fédération et émet basée sur les revendications qui est attendues par l'application (web1). Il a établi approbation Fabrikam.com et sert également à l'application.
sts2 : un STS qui se trouve dans le rôle de fournisseur d'identité pour Fabrikam.com et qui fournit un point de terminaison que les employés de Fabrikam utilise pour s'authentifier. Il a établi la relation d'approbation avec Contoso.com afin que les employés de Fabrikam sont autorisés à accéder aux ressources de Contoso.com.
Notez que le terme « Jeton ActAs » fait référence à un jeton qui est émis par un STS et qui contient l'identité de l'utilisateur. La propriété Delegate() contient l’identité du STS. Comme le montre la figure 1, le flux dans ce scénario est le suivant :
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é Delegate(). Daniel implémente ces modifications à l'application.
L'application de Contoso est configurée pour transmettre le jeton ActAs au service principal. Daniel implémente ces modifications à l'application.
Le service web de Contoso est configuré pour valider le jeton ActAs en appelant sts1. ADAM permet de sts1 traiter les demandes de délégation.
Utilisateur de Fabrikam Frank accède à l'application de Contoso et reçoit l'accès aux ressources principale.
Authentification fédérée
L'authentification fédérée permet à un service d'émission de jeton de sécurité (STS) dans un domaine d'approbation pour fournir des informations d'authentification à un service STS dans un autre domaine d'approbation lorsqu'il existe une relation d'approbation entre les deux domaines. Un exemple est illustré dans la Figure 2.
Figure 2. Scénario de fédération des revendications
Un client dans le domaine d'approbation de Fabrikam envoie une demande à une application de tiers de confiance dans le domaine d'approbation de Contoso.
La partie de confiance redirige le client vers un service STS dans le domaine d'approbation de Contoso. Ce service STS n'a pas connaissance du client.
Le service STS Contoso redirige le client vers un service STS dans le domaine d'approbation de Fabrikam, avec lequel le domaine d'approbation de Contoso a une relation d'approbation.
Le service STS Fabrikam vérifie l'identité du client et émet un jeton de sécurité pour le service STS Contoso.
Le service STS Contoso utilise le jeton de Fabrikam pour créer son propre jeton, qu'il envoie à la partie de confiance.
La partie de confiance extrait les revendications du client à partir du jeton de sécurité et rend une décision d'authentification.
Ce scénario décrit une expérience d’authentification pour un employé partenaire lorsqu’elle tente d’accéder aux ressources à partir du domaine d’un autre partenaire. Elle ne doit se connecter qu’une seule fois. Il existe trois principaux acteurs dans un scénario de fédération : un fournisseur d’identité, un fournisseur de fédération et une partie de confiance. WIF propose des API pour générer les trois joueurs. La figure 3 illustre un scénario de fédération classique dans lequel un employé Fabrikam souhaite accéder à Contoso.com ressources sans avoir à se reconnecter ; autrement dit, l’employé fabrikam souhaite utiliser l’authentification unique. Figure 3. Scénario de délégation des identités basées sur les revendications
Les utilisateurs fictifs participent à ce scénario sont les suivants :
Frank : Un employé de Fabrikam souhaitant accéder à des ressources de Contoso.
Daniel : Un Contoso développeur d'application qui implémente les modifications nécessaires dans l'application.
ADAM : Contoso administrateur informatique.
Les composants impliqués dans ce scénario sont les suivants :
web1: A classement application web qui est générée avec ASP.NET et contrôle l'accès aux parties significatives de composants WebPart.
STS1 : un STS qui se trouve dans le rôle de fournisseur de fédération contoso.com et émet des revendications qui sont attendues par l'application (web1). Il a établi une confiance avec Fabrikam.com et est configuré pour autoriser l'accès aux employés de Fabrikam.
sts2 : un STS qui se trouve dans le rôle de fournisseur d'identité dans Fabrikam.com et fournit un point de terminaison vers lequel les employés de Fabrikam sont authentifié. Il a établi la relation d'approbation avec Contoso.com afin que les employés de Fabrikam sont autorisés à accéder aux ressources de Contoso.com.
Comme le montre la Figure 3, le flux dans ce scénario est :
Administrateur de Contoso Adam configure l'approbation entre les applications (relying party) et sts1.
Administrateur de Contoso Adam configure l'approbation avec sts2 en tant que fournisseur d'identité.
Administrateur de Fabrikam Frank configure l'approbation avec sts1 en tant qu'un fournisseur de fédération et accède ensuite à l'application.