Cet article a fait l'objet d'une traduction automatique.

AD FS 2.0 dans les solutions d'identité

Utilisation d'AD FS (Active Directory Federation Services) 2.0 dans les solutions d'identité

Zulfiqar Ahmed

Télécharger l'exemple de code

En tant que développeur, vous savez probablement quelque chose sur Windows Identity Foundation (WIF), anciennement appelé “ Geneva Framework, respectez qui fournit une API puissante pour les déclarations-activer vos applications et pour créer des services de jetons de sécurité personnalisé. Moins familier pour vous est peut-être de Active Directory Federation Services version 2.0 AD FS (2.0), à l'origine du code “ Geneva serveur nommé, respectez qui est une fédération entreprise prêts et single-sign-on (SSO) solution. AD FS 2.0 est une évolution du AD FS 1.0 et prend en charge (WS-Trust) actif et passifs scénarios (WS-Federation et SAML 2.0).

Dans cet article, je démarre avec une vue d'ensemble de AD FS 2.0 et puis fournir un aperçu de la façon dont les développeurs peuvent utiliser AD FS 2.0 dans leurs solutions d'identité. Le focus est sur la fonctionnalité d'émission de jeton de AD FS 2.0, selon la version bêta 2. Comme vous pouvez le voir dans de la figure 1, cette émission de jeton est uniquement un petit morceau de AD FS 2.0, mais il s'agit d'un intérêt particulier pour les développeurs .NET déplacement vers l'identité fédérée. Point de vue architectural, AD FS 2.0 est construit par-dessus WIF et Windows Communication Foundation (WCF), donc si vous êtes familiarisé avec ces technologies, vous êtes droit à la maison avec AD FS 2.0.

Figure 1 de l'architecture de AD FS 2.0

Vue d'ensemble de AD FS 2.0

Un haut niveau, AD FS 2.0 est une collection des services illustré à la de la figure 2.

Au cœur de AD FS 2.0 est un service de jetons de sécurité (STS) qui utilise Active Directory comme banque d'identités et LDAP (Lightweight Directory Access Protocol), SQL ou une banque personnalisée comme un magasin de l'attribut. Le SJS dans AD FS 2.0 peut émettre des jetons de sécurité à l'appelant en utilisant divers protocoles, notamment WS-Trust, WS-Federation et SAML (Security Assertion Markup Language) 2.0. Le SJS FS 2.0 Active Directory prend également en charge les formats de jetons SAML 1.1 et 2.0 de SAML.

AD FS 2.0 est conçu avec une séparation claire entre les protocoles de transmission et le mécanisme d'émission de jeton interne. Protocoles de transmission différentes sont transformés en un modèle d'objet normalisé à l'entrée du système tandis qu'en interne AD FS 2.0 utilise le même modèle d'objet pour chaque protocole. Cette séparation permet AD FS 2.0 proposer un modèle d'extensibilité en mode minimal, indépendamment de la complexité des protocoles réseau différents. Plus de détails de AD FS 2.0 extensibilité est fournie dans le Kit de développement AD FS 2.0 antérieures à RTM.

La figure 2 de composants d'AD FS 2.0

AD FS 2.0 comme un fournisseur d'identité

Vous pouvez utiliser AD FS 2.0 dans plusieurs scénarios courants. Le scénario de la plus simple et la plus courant consiste à utiliser AD FS 2.0 comme fournisseur d'identité afin qu'il peut émettre des jetons SAML pour les identités qu'il gère. Pour ce faire, une nouvelle partie utilisatrice doit être créé. Une partie utilisatrice dans AD FS 2.0 est une représentation d'une application (un site Web ou un service Web) et contient toutes les liés à la sécurité informations, telles que le certificat de cryptage, déclare les règles de transformation et ainsi de suite.

Configuration d'une partie utilisatrice

Configuration d'une nouvelle partie utilisatrice via AD FS 2.0 est simple. Vous pouvez accéder à l'Assistant Ajout de fête confiance via le nœud Stratégie de l'annuaire AD FS 2.0 Management console. Une fois, vous ou votre administrateur système doit spécifier les sources de données appropriée dans la page Sélectionner la source de données de l'Assistant, qui est affiché dans de la figure 3.

La figure 3 vous fier composant Assistant Ajout d'une sélection de page de la source de données de

Les deux premières options permettent de configurer automatiquement la partie utilisatrice à l'aide de métadonnées de la fédération. Si vous avez accès aux métadonnées de la partie utilisatrice la fédération sur un réseau ou dans un fichier local, sélectionnez une de ces deux options, car ils sont moins sujets à erreur, ils automatisent l'ensemble du processus et mise à leur jour automatique si tous les détails de la partie utilisatrice modifier à l'avenir. Ces options sont une amélioration majeure par rapport à AD FS 1.0, qui n'offre pas de tels processus automatisés.

La troisième option nécessite que vous entrez manuellement tous les détails de configuration. Utilisez cette option uniquement lorsque vous n'avez pas accès aux métadonnées de la fédération ou que vous souhaitez contrôler les détails de la configuration de tiers de confiance.

Il est intéressant d'exécuter par l'intermédiaire de l'option “ Entrez configuration tiers vous fier manuellement respectez simplement pour que vous puissiez voir toutes les étapes requises pour configurer une nouvelle partie utilisatrice. Dans les pages suivantes de l'Assistant, vous serez invité à choisir un profil, choisissez AD FS 2.0 profil si vous souhaitez prendre en charge des clients à la fois fonctionnant dans un navigateur et basée sur WCF ou AD FS 1.x profil si vous avez besoin de l'interopérabilité AD FS 1.x uniquement et que vous ne prennent pas en charge les clients actifs (WCF, CardSpace); configurez le certificat qui est utilisé pour chiffrer le jeton de sorte qu'uniquement la partie utilisatrice avec la clé privée correspondante peut décrypter et utiliser le jeton émis ; et configurer l'identificateur qui sera utilisé pour identifier cette partie utilisatrice dans toutes les demandes d'émission de jeton.

Une fois que vous avez terminé l'Assistant Ajout de fête la partie de confiance, un outil de gestion des messages éditeur s'ouvre. Cet outil vous permet de configurer des règles de d'émission et de transformation de déclarations. La figure 4 affiche l'outil Éditeur de règles configurée pour émettre un jeton avec une déclaration unique dont la valeur extraite de la banque de l'attribut principal. Notez que l'attribut displayName est mappé à la déclaration de nom donné. AD FS 2.0 introduit un nouveau langage spécifiques au domaine textuel qui vous permet de définir des règles simples pour dériver le processus d'émission et la transformation de déclarations. Chaque règle se compose d'une condition et une action et se termine, comme dans [c] = > un; — par un point-virgule. La logique de transformation est une série de règles qui s'exécutent de façon séquentielle au cours du processus d'émission de jeton. Dans de la figure 4, l'onglet Affichage Simple fournit une interface utilisateur pour définir ces règles. L'onglet vue avancée vous permet de règles auteur directement à l'aide de la langue spécifique au domaine.

La figure 4 Règles éditeur outil

Cet exemple a illustré combien il est facile à configurer une partie utilisatrice approuvée dans AD FS 2.0. À ce stade, lorsque AD FS 2.0 reçoit une demande d'émission de jeton, il extrait un identificateur de protocole de connexion (par exemple, l'élément appliesTo dans le cas de WS-Trust) et l'utilise pour rechercher une partie utilisatrice cible. Une fois qu'une partie utilisatrice est trouvée, les paramètres spécifiés dans l'Assistant sont utilisées pour dériver la logique d'émission de jeton.

Maintenant examiner let’s comment vous pouvez utiliser WCF pour demander un jeton pour cette partie utilisatrice à partir d'AD FS 2.0.

Demander un jeton à l'aide de WCF

Il existe deux options permettant d'interagir avec AD FS 2.0 STS à l'aide de WCF :

• Explicitement acquérir un jeton agissant comme un client WS-Trust
• Configurer un client WCF afin que l'infrastructure acquiert implicitement un jeton dans le cadre de l'appel

Dans l'option explicit, la classe WSTrustClient fournit une API simple et directe aux jetons de demande à partir d'un STS en utilisant le protocole WS-Trust, comme illustré ici.

string baseUri = "https://bccoss.com/";

WindowsWSTrustBinding binding = new WindowsWSTrustBinding(SecurityMode.Transport);

WSTrustClient tokenClient = new WSTrustClient(binding,
    new EndpointAddress(baseUri + "Trust/2005/WindowsTransport/"),
    TrustVersion.WSTrustFeb2005,
    new ClientCredentials());

//create a token issuance issuance
RequestSecurityToken rst =
    new RequestSecurityToken(WSTrustFeb2005Constants.RequestTypes.Issue);
//Relying Party’s identifier
rst.AppliesTo = new EndpointAddress("http://local.zamd.net/");
//call ADFS STS
SecurityToken token = tokenClient.Issue(rst);

Ce code demande un jeton à l'aide de l'authentification Windows avec sécurité du transport. Comme vous pouvez le voir, en mode explicite, vous pouvez accéder au jeton brut, vous pouvez utiliser pour appeler des services plus tard. Par exemple, dans une application client intelligent, vous pourriez acquérir des jetons pour différents services au moment de démarrage ou ouverture de session d'application, enregistrez-les dans un cache de jetons et les utiliser pendant toute la durée de vie de l'application d'appeler différents services back-end. En outre, dans un scénario où de nombreux services live dans la même limite de sécurité logique, partage le même certificat, vous pouvez utiliser le mode explicite pour acquérir un jeton unique et utilisez-le lors de l'appel de tous ces services.

 Dans un environnement de test, dans lequel vous avez généralement accès à clé privée de la partie utilisatrice, vous pouvez utiliser le code suivant pour extraire une assertion SAML le jeton retourné.

//Private Key certificate of RP (local.zamd.net)
X509Certificate2 rpCertificate = new X509Certificate2("zamd.net.pfx", "pwd");
string assertion = Util.ExtractSAMLAssertion(token, rpCertificate);

<saml:Attribute AttributeName="givenname" AttributeNamespace="https://schemas.xmlsoap.org/ws/2005/05/identity/claims">
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue>
</saml:Attribute>

Le jeton SAML contient uniquement les revendications configurées pour cette partie utilisatrice particulier. Consultez figure 4 , qui montre comment le jeton de sortie de cette partie de confiance a été configuré pour renvoyer un seul attribut. Vous pouvez modifier la configuration de la partie utilisatrice pour inclure des déclarations plus dans la sortie, et vous devriez voir tous les reflétés ici. Vous pouvez également utiliser le langage de stratégie de revendications directement pour définir la transformation riche et logique du filtrage.

L'API WSTrustClient et nouvelles combinaisons de WSTrust font partie de WIF, donc pour le code précédent fonctionne, WIF doit être installé sur le client. Vous pouvez également utiliser l'API de WCF directement pour explicitement acquérir un jeton, mais la simplicité et facilité d'utilisation WIF offres peut prendre une tâche désactiver votre liste de tâches.

Dans le code dans de la figure 5, IssuedSecurityTokenProvider est l'équivalent WCF de WSTrustClient et est généralement utilisé par wsFederationBinding lors de la demande de jetons de votre part. Dans la mesure où il s'agit d'une API publique, vous êtes libre d'utiliser dans votre code devez vous avez besoin d'accéder à un jeton brut. L'élément CustomBinding est équivalente à WindowsWSTrustBinding.

La figure 5 Using IssuedSecurityTokenProvider pour accéder à un jeton RAW

sstring baseUri = "https://bccoss.com/";

//Limited edition of WSTrustClient:)
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider();
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer();

//Relying Party's identifier
provider.TargetAddress = new EndpointAddress(new Uri("http://local.zamd.net"));
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri + "Trust/2005/WindowsTransport/"));

provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
provider.MessageSecurityVersion = MessageSecurityVersion.
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

HttpsTransportBindingElement tbe = new HttpsTransportBindingElement();
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate;
CustomBinding stsBinding = new CustomBinding(tbe);

provider.IssuerBinding = stsBinding;
provider.Open();
//Request a token from ADFS STS
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));

Dans l'option implicite, vous pouvez utiliser le wsFederationHttpBinding standard, dans lequel cas l'infrastructure WCF en toute transparence acquiert le jeton et envoie au service en tant que partie de l'appel. Chaque fois que vous créez un nouveau proxy WCF et que vous utilisez pour appeler un service, l'infrastructure extrait un nouveau jeton pour vous. Évidemment, ceci serait excessif dans certains scénarios. Le code dans de la figure 6 configure un EmployeeService fictif pour exiger des jetons à partir d'AD FS 2.0.

La figure 6 Using wsFederationHttpBindingto acquérir un jeton implicitement

<system.serviceModel>
  <services>
    <service name="EmployeeService.EmployeeService">
      <endpoint address="http://localhost:9990/ES"
        binding="ws2007FederationHttpBinding"
        contract="EmployeeServiceContract.IEmployeeService"
        bindingConfiguration="adfsFed"/>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="adfsFed">
        <security mode="Message">
          <message negotiateServiceCredential="false" >
            <issuer address="https://bccoss.com/Trust13/KerberosMixed"
               binding="customBinding" bindingConfiguration="MixedKerberos"/>
          </message>
        </security>
      </binding>
     </ws2007FederationHttpBinding>
     <customBinding>
       <binding name="MixedKerberos">
         <security authenticationMode="KerberosOverTransport"/>
         <httpsTransport/>
       </binding>
     </customBinding>
   </bindings>
</system.serviceModel>

Mappage AD FS 2.0 concepts à WCF

La responsabilité principale de AD FS 2.0 est d'émettre des jetons pour les utilisateurs authentifiés. Les utilisateurs peuvent être authentifiés à l'aide de différents mécanismes d'authentification (telles que l'authentification Windows). Vous pouvez voir tous les mécanismes d'authentification pris en charge en sélectionnant le nœud de points de terminaison dans la console de gestion.

Vous remarquerez deux concepts de sécurité WCF familiers comme en-têtes de colonne dans le nœud de points de terminaison :

• Type d'authentification est AD FS 2.0 équivalente de la terminologie de clientCredentialType WCF.
• Choix de mode de sécurité sont transport, message ou mixte. Mixte équivaut AD FS 2.0 TransportWithMessageCredentials de WCF.

Différentes combinaisons de ces deux valeurs sont exposées à l'aide de différents points d'entrée, puis vous choisissez un point de terminaison spécifique en fonction de vos besoins d'authentification. Par exemple, si vous avez besoin de s'authentifier en utilisant le nom d'utilisateur/mot de passe, vous choisissez le point de terminaison de l'authentification effacer le mot de passe.

Pour SharePoint Team Services de AD FS 2.0, le mappage de ces concepts à Address, Binding et contrat (ABC) dans WCF, vous obtenez les équivalents suivants :

• Adresse = AD FS 2.0 base adresse + chemin d'URL du point de terminaison
• Liaison = mode de sécurité + type d'authentification du point de terminaison
• Contrat = protocole WS-Trust Standard

Fédération AD FS 2.0 avec un autre STS

Outre la possibilité de créer des parties, vous pouvez établir une relation d'approbation entre AD FS 2.0 et votre STS personnalisés ou un autre AD FS 2.0. Par exemple, si vous disposez déjà d'un STS qui authentifie les utilisateurs et émet des jetons, vous pouvez simplement l'ajouter comme un fournisseur d'identité approuvée dans AD FS 2.0, qui accepte les jetons émis par le STS.

Configuration d'un fournisseur d'identité

Configuration d'un fournisseur d'identité approuvés, nouvelle dans AD FS 2.0 est similaire à la configuration d'une nouvelle partie utilisatrice. L'Assistant Ajouter un fournisseur de compteur que vous utilisez a l'apparence et le comportement beaucoup l'Assistant Ajout de fête la partie de confiance (voir de la figure 3).

Pour accéder à la page Configurer un identificateur, sélectionnez l'option de configuration manuelle à nouveau (comme dans de la figure 3) et sélectionnez AD FS 2.0 profil dans la page Choisir le profil. Conservez les paramètres par défaut sur la page Configurer une URL. Vous ensuite de Choisissez un identificateur et un certificat de clé publique pour votre fournisseur d'identité et de fin de l'Assistant pour enregistrer le nouveau fournisseur d'identité.

Demander un jeton à l'aide de WCF

Une fois inscrit un fournisseur d'identité supplémentaires avec AD FS 2.0, l'architecture logique ressemble à la configuration illustrée à la de la figure 7.

De la figure 7 architecture de AD FS 2.0 avec un fournisseur d'identité supplémentaires

Le code dans de la figure 8 vous permet d'acquérir un jeton explicitement, ce qui vous donne la possibilité de mettre en cache localement le jeton et envoyer au service en fonction des besoins.

La figure 8 Using IssuedTokenWSTrustBinding à acquérir un jeton explicitement

string adfsStsUri = "http://bccoss.com/Trust/2005/IssuedTokenAsymmetricBasic256";

//binding for local STS(IP-STS)
WSHttpBinding localStsBinding = new WSHttpBinding(SecurityMode.Message);

localStsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
localStsBinding.Security.Message.EstablishSecurityContext = false;
localStsBinding.Security.Message.NegotiateServiceCredential = false;

EndpointAddress localStsEpr = new EndpointAddress(
   new Uri("http://localhost:9000/STS/"),
   new X509CertificateEndpointIdentity(new X509Certificate2(@"MyCustomSTSPublicKey.cer")));

//This binding will transparently acquire all the intermediate tokens as part of the call. (R-STS)
IssuedTokenWSTrustBinding fedBinding = new IssuedTokenWSTrustBinding(localStsBinding, localStsEpr);
fedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;

EndpointAddress adfsStsEpr = new EndpointAddress(
    new Uri(adfsStsUri),
    new X509CertificateEndpointIdentity(new X509Certificate2("AdfsStsPubicKeyOnly.cer")));

WSTrustClient trustClient = new WSTrustClient(fedBinding, adfsStsEpr, TrustVersion.WSTrustFeb2005,
null);

//Create a security token request
RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);
//Set Relying Party's identifier accordingly
rst.AppliesTo = new EndpointAddress("http://local.zamd.net");

SecurityToken finalToken = trustClient.Issue(rst);

IssuedTokenWSTrustBinding est très similaire à wsFederationHttpBinding dans la mesure où il masque tous les la complexité de jetons intermédiaires en contactant en toute transparence le STS IP pour obtenir un jeton intermédiaire qui est ensuite envoyé au R-STS sous la forme d'un jeton d'authentification.

Le code dans de la figure 9 utilise wsFederationHttpBinding pour permettre à un client WCF implicitement acquérir un jeton dans le cadre d'un appel de service.

Notez que j'utilise un customBinding lors de la communication avec le point de terminaison /IssuedTokenMixedSymmetricBasic256. Le standard wsFederationHttpBinding non-fonctionnement ici car il essaie d'établir une session sécurisée, qui est incompatible avec cette AD FS 2.0 point de terminaison. Pour fédérer des clients WCF avec AD FS 2.0, vous devez utiliser un customBinding ou une des nouvelles basés sur WS-Trust liaisons qui est livré avec WIF.

La figure 9 Using wsFederationHttpBinding à acquérir un jeton implicitement

<system.serivceModel>
   <bindings>
      <wsFederationHttpBinding>
         <binding name="R-STS">
            <security mode="Message">
               <message>
                  <issuer address="https://bccoss.com/Trust/2005/IssuedTokenMixedSymmetricBasic256" binding="customBinding" bindingConfiguration="IP-STS"/>
               </message>
            </security>
         </binding>
      </wsFederationHttpBinding>

      <customBinding>
         <binding name="IP-STS">
            <security authenticationMode="IssuedTokenOverTransport">
               <issuedTokenParameters>
                  <issuer address="http://localhost:9000/CustomSTS" binding="wsHttpBinding"/>
               </issuedTokenParameters>
            </security>
            <httpsTransport/>
         </binding>
      </customBinding>
   </bindings>

   <client>
      <endpoint address="http://localhost:9990/ES" binding="wsFederationHttpBinding" bindingConfiguration="R-STS"
contract="ServiceReference1.IEmployeeService" name="WSFederationHttpBinding_IEmployeeService"/>
      </client>
</system.serviceModel>

AD FS 2.0 et les clients navigateur

AD FS 2.0 a prise en charge de première classe pour le Web single sign-on (WebSSO) et la fédération à l'aide des protocoles WS-Federation et SAML 2.0.

Point de vue conceptuel, WS-Federation et le protocole SAML sont similaires même s'ils possèdent des représentations sous forme de transmission différents. Le format de transmission de WS-Federation est étroitement lié au protocole WS-Trust, il est le choix logique lors du service de clients actifs et passifs (basée sur le navigateur). Le protocole SAML a une meilleure interopérabilité entre les différents fournisseurs. AD FS 2.0 assure la prise en charge ces deux protocoles native. Il est conseillé de tenir à un seul protocole (par exemple, WS-Federation) à l'intérieur de votre limite de sécurité et utilisez AD FS 2.0 comme un concentrateur de broker de protocole pour SSOs entrants ou sortants.

Let’s Prenons un exemple. Supposons que vous disposez d'une application ASP.NET simple qui fournit des fonctionnalités uniquement aux utilisateurs authentifiés. En tant qu'application autonome, logique d'authentification est implémentée en tant que partie intégrante de l'application et une interaction avec cette application serait suivez les étapes présentées dans de la figure 10.

Figure 10 authentification directe dans une application ASP.NET simple

Ici les mécanismes d'authentification ASP.NET habituels, tels que l'authentification par formulaires, sont mises en œuvre. Notre objectif consiste à extraire de la fonctionnalité d'authentification à partir de cette application et utiliser AD FS 2.0 à la place.

Dans Active Directory installation FS 2.0, qui est visible dans de figure 11, l'application devient une partie utilisatrice approuvée à l'intérieur AD FS 2.0 et par conséquent approuve les jetons émis par AD FS 2.0. L'application utilise WIF pour faire tout l'essentiel de jeton de l'analyse, l'extraction des déclarations et ainsi de suite. Informations d'identité sont fournies pour l'application en utilisant les abstractions de IPrincipal/IIdentity standard.

L'authentification distribuée dans AD FS 2.0 est beaucoup plus souple que l'authentification directe, et il offre certains avantages majeurs :

• L'authentification est externalisée à partir de l'application, afin que le mécanisme d'authentification peut être modifié (par exemple, de nom d'utilisateur pour Kerberos) sans affecter l'application.
• La flexibilité d'un modèle basé sur les revendications peut représenter toutes les informations requises pour l'application (dans le cadre du jeton) directement plutôt que l'application elle-même récupérer ces informations à partir de sources différentes.

La version bêta 2 de WIF a introduit de nouveaux modèles de projet qui facilitent la logique d'authentification d'une application à un STS d'externalize. Au moment de la rédaction de ce document, ces modèles sont disponibles uniquement en c#.

De la figure 11 Distributed authentification dans AD FS 2.0

Logique d'authentification externalizing

Pour externalize logique d'authentification d'une application, vous utilisez la boîte de dialogue Nouveau Site Web de Microsoft Visual Studio. Sélectionnez le modèle Claims-aware Web Site pour créer un site ASP.NET Web standard qui est préconfiguré avec WIF.

Pour lancer l'Assistant utilitaire de la fédération, illustré à la figure 12 , cliquez avec le bouton droit sur le nœud Web Site dans l'Explorateur de solutions et sélectionnez Modifier la référence de SharePoint Team Services dans le menu.

La figure 12 de la fédération utilitaire

Pour cet exemple, choisissez l'option “ utiliser un STS existant respectez marquons spécifier AD FS 2.0 comme le STS. L'Assistant requiert l'URL du document de métadonnées automatiser toutes les configurations requises. L'URL de document de métadonnées est disponible sous la forme d'un point de terminaison à l'intérieur AD FS 2.0.

Métadonnées de la fédération contient des informations essentielles telles que le STS signature de certificat, les revendications proposées et l'URL d'émission de jeton. Avoir un format standardisé pour ces informations permet aux outils automatiser l'établissement de relations d'approbation entre un STS et compter les parties.

La page Résumé de l'Assistant résume les modifications qui vont être apportées dans le fichier web.config.

L'Assistant utilitaire de fédération configure WIF sur votre site Web pour fournir les fonctionnalités suivantes :

• Toutes les demandes non authentifiées sont redirigées pour AD FS 2.0.
• Toute demande contenant un jeton valide sera traitée, et informations d'identité seront présentées à l'application dans l'écran de ClaimsIdentity/ClaimsPrincipal. L'application va continuer à accéder aux informations d'identité en utilisant les abstractions de IPrincipal/IIdentity standard indépendamment de la source de ces informations.

Avant de tester l'application, vous devez apporter une dernière configuration modifier sur AD FS 2.0. Vous devez ajouter un point de terminaison supplémentaire à la partie utilisatrice pour des navigateurs clients. Ce point de terminaison est nécessaire car une fois AD FS 2.0 a traité une demande d'émission de jeton, deux informations est nécessaires avant qu'il puisse envoyer le jeton au navigateur :

• L'adresse où le jeton doit être envoyé
• Le protocole (SAML ou WS-Federation) pendant laquelle le jeton doit être envoyé

Vous pouvez ajouter un point de terminaison passif à la partie utilisatrice dans l'onglet points de terminaison de la boîte de dialogue Propriétés de RP de test. Par exemple, si vous sélectionnez le type de point de terminaison WS-Federation, AD FS 2.0 envoie jetons à la partie utilisatrice à l'aide du protocole WS-Federation. Dans la partie utilisatrice, WIF, qui comprend en mode natif de protocole WS-Federation, traite ces jetons.

Maintenant lorsque vous essayez de naviguer à l'application, vous êtes automatiquement redirigé vers AD FS 2.0 pour l'authentification, dans laquelle vous pouvez choisir la méthode d'authentification à utiliser : L'authentification intégrée de Windows, d'authentification par certificat ou d'un formulaire de nom d'utilisateur/mot de passe.

Une fois l'authentification réussit, vous — avec un jeton émis par AD FS 2.0 — redirigé vers l'application. WIF traite ce jeton et rend l'identité finale (sous la forme de déclarations) disponible à l'application à l'aide des mécanismes ASP.NET standard (par exemple, Page.User).

Fédération de navigateur

Vous pouvez étendre un scénario de l'authentification de base externe dans un scénario de fédération en ajoutant un fournisseur d'identité de confiance supplémentaire. Les options de fournisseur d'identité sont affichées au cours du processus d'authentification.

Vous pouvez authentifier avec AD FS 2.0 ou un autre fournisseur d'identité de confiance. Si vous sélectionnez un fournisseur d'identité différents, vous sont redirigés vers ce fournisseur d'identité et, lors de l'authentification réussie, redirigé vers AD FS 2.0, qui serait puis vous authentifier comme utilisateur basé sur le jeton émis par le fournisseur d'identité approuvée.

Combinaison puissante

Comme vous l'avez vu dans cet article, AD FS 2.0 STS fournit un simplement et solution prédéfinie pour les déclarations activer vos services WCF et les applications basées sur un navigateur. SharePoint Team Services est lui-même un seul petit morceau de AD FS 2.0, qui inclut également un CardSpace mise en service du système, un moteur de transformation de déclarations basées sur des règles, approbation automatique services d'infrastructure, la gestion et la configuration de gestion et leurs outils respectifs. Avec WIF, AD FS 2.0 crée une combinaison puissante aux solutions d'identité de programme sur la plate-forme Windows.

Zulfiqar Ahmed est consultant senior dans l'équipe Royaume-Uni Application Development Consulting (ADC) et peut être contacté à http://zamd.net de .