Conseils relatifs aux revendications 3 : authentification basée sur les revendications dans SharePoint 2010

Article
07/02/2015

Résumé : découvrez cinq conseils relatifs à l’authentification basée sur les revendications dans SharePoint 2010, notamment des informations sur l’empaquetage, l’extraction de données REST, l’ajout de stratégie, la gestion d’autorités racines de confiance et la résolution des problèmes liés aux pages de connexion.

Dernière modification : lundi 28 mars 2011

Dans cet article
Vue d’ensemble de la portée de cet article
Conseil 1 : empaquetage d’un fournisseur de revendications personnalisées SharePoint 2010 dans un projet SharePoint Visual Studio 2010
Conseil 2 : extraction de données REST dans un site à authentification basée sur les revendications dans SharePoint 2010
Conseil 3 : ajout d’une revendication personnalisée à une stratégie d’application Web à l’aide de Windows PowerShell dans SharePoint 2010
Conseil 4 : gestion d’autorités racines de confiance pour l’authentification basée sur les revendications dans l’Administration centrale de SharePoint 2010
Conseil 5 : résolution des problèmes de connexion à la page d’authentification AD FS dans SharePoint 2010
Conclusion
Ressources supplémentaires

Auteur : Steve Peschka, Microsoft Corporation

Sommaire

Vue d’ensemble de la portée de cet article
Conseil 1 : empaquetage d’un fournisseur de revendications personnalisées SharePoint 2010 dans un projet SharePoint Visual Studio 2010
Conseil 2 : extraction de données REST dans un site à authentification basée sur les revendications dans SharePoint 2010
Conseil 3 : ajout d’une revendication personnalisée à une stratégie d’application Web à l’aide de Windows PowerShell dans SharePoint 2010
Conseil 4 : gestion d’autorités racines de confiance pour l’authentification basée sur les revendications dans l’Administration centrale de SharePoint 2010
Conseil 5 : résolution des problèmes de connexion à la page d’authentification AD FS dans SharePoint 2010
Conclusion
Ressources supplémentaires

Vue d’ensemble de la portée de cet article

Cet article fournit des conseils et des réponses aux questions les plus fréquentes concernant l’authentification basée sur les revendications dans Microsoft SharePoint 2010. Il contient également des conseils et des instructions pour vous aider à résoudre les problèmes liés à l’utilisation et à la configuration des revendications et pointe vers d’autres ressources où vous trouverez davantage d’informations.

Conseil 1 : empaquetage d’un fournisseur de revendications personnalisées SharePoint 2010 dans un projet SharePoint Visual Studio 2010

Si vous développez des solutions pour SharePoint 2010 à l’aide de Microsoft Visual Studio 2010, vous aurez peut-être remarqué une petite particularité liée à l’empaquetage des fournisseurs de revendications personnalisées. Dans Visual Studio 2010, vous pouvez créer une fonctionnalité puis ajouter facilement un récepteur d’événements de fonctionnalité à cette nouvelle fonctionnalité en cliquant avec le bouton droit sur la fonctionnalité et en sélectionnant le menu Ajouter un récepteur d’événements. Cela accroît la productivité, facilite l’utilisation du code de votre solution et vous évite de passer du temps à la configuration.

Toutefois, une déconnexion a lieu car le récepteur d’événements ajouté par défaut par Visual Studio 2010 est hérité de SPFeatureReceiver. Comme vous le savez peut-être, le récepteur d’événements qui sert à enregistrer un fournisseur de revendications personnalisées doit hériter de SPClaimProviderFeatureReceiver (voir Procédure pas à pas pour les revendications : écriture de fournisseurs de revendications pour SharePoint 2010). De plus, les fonctionnalités SharePoint intégrées à Visual Studio n’offrent pas vraiment de façon intuitive d’ajouter simplement une classe à un projet SharePoint 2010 et de l’associer ensuite à une fonctionnalité.

Il existe cependant une solution de contournement assez simple et astucieuse. Je l’ai découverte récemment dans les conditions suivantes : j’avais écrit un fournisseur de revendications personnalisées et un récepteur de fonctionnalité correspondant pour l’installer. Ces deux classes faisaient partie d’un seul objet. Décidant de tirer pleinement parti de la nouvelle fonctionnalité d’empaquetage de Visual Studio 2010, je me suis rendu compte que les étapes nécessaires étaient les suivantes :

Effectuez la première série de codage de votre projet de fournisseur de revendications personnalisées et du récepteur d’événements correspondant pour l’enregistrement, puis compilez-le. Observez l’assembly compilé afin d’obtenir le nom fort de l’assembly et le nom de classe pour le récepteur d’événements.
Ajoutez un nouveau projet à votre solution. Basez ce nouveau projet sur un modèle Projet SharePoint vide pour SharePoint 2010. Configurez le projet à déployer comme solution de batterie.
Cliquez avec le bouton droit sur le nœud Fonctionnalités dans le projet, puis sélectionnez Ajouter une fonctionnalité. Votre fonctionnalité doit avoir une portée de Batterie et doit s’auto-activer. Si ce n’est pas le cas, configurez les propriétés de la fonctionnalité en fonction de ce que vous tentez d’obtenir. Voici le point le plus important : configurez les deux propriétés suivantes sur la fonctionnalité (dans la fenêtre Propriétés de Visual Studio) comme décrit :
- Assembly du récepteur Tapez le nom fort de votre assembly décrit à l’étape 1.
  
  Par exemple, tapez ce qui suit : MyClaimProvider.ClaimTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=edb00fee02fa0701
- Classe du récepteur Tapez le nom de la classe de récepteur d’événements que vous avez écrite pour votre fournisseur de revendications personnalisées à l’étape 1.
  
  Par exemple, tapez ce qui suit : MyClaimProvider.ClaimTest.MyClaimsFeatureReceiver
Ajoutez votre assembly de fournisseur de revendications personnalisées compilé à la liste des assemblys déployés par votre solution d’empaquetage, comme suit :
1. Double-cliquez sur le nœud Package.package dans le projet d’empaquetage Visual Studio.
2. Sous l’onglet Avancé, cliquez sur Ajouter, puis sur Ajouter un assembly existant.
3. Recherchez l’emplacement correct de votre assembly de fournisseur de revendications personnalisées compilé et laissez la Cible de déploiement : GlobalAssemblyCache par défaut sélectionnée.
4. Cliquez sur OK pour enregistrer les modifications, puis fermez la fenêtre de propriétés Package.

Une petite remarque concernant l’étape 4 : en règle générale, je crée simplement un dossier dans mon projet d’empaquetage où je copie mes assemblys compilés issus d’autres projets que je souhaite distribuer avec la solution. Lorsque je configure les assemblys supplémentaires dans la fenêtre Package, je sélectionne simplement les assemblys du dossier de mon projet d’empaquetage. Dans mes autres projets, j’ai un script post-build qui copie automatiquement l’assembly compilé dans ce dossier d’assemblys dans mon projet d’empaquetage. Il s’agit d’une simple ligne de code post-build qui copie l’assembly (qu’il s’agisse d’une version Debug ou d’une version Release) et m’évite d’avoir à le faire manuellement à chaque fois. Voici le code (en supposant que vous créez un dossier nommé GacFiles pour stocker ces assemblys).

copy "$(TargetPath)" ..\..\..\MyPackagingProject\GacFiles /Y

Votre package est maintenant terminé. Il vous suffit de compiler le projet de package puis, dans le menu contextuel du projet (clic droit), de sélectionner Package. Vous disposez alors d’un package de solution (fichier .wsp) distribuable et pouvez faire en sorte que celui-ci déploie automatiquement votre fournisseur de revendications personnalisées.

Conseil 2 : extraction de données REST dans un site à authentification basée sur les revendications dans SharePoint 2010

Notes

Ce conseil est une petite partie d’une section d’un livre blanc relatif aux revendications et à SharePoint 2010.

SharePoint 2010 autorise l’extraction de données de liste par le biais d’une interface REST (Representational State Transfer). Dans cet exemple, je réutilise le code qui obtient le cookie FedAuth fourni par le billet de blog Utilisation du modèle objet client avec un site à authentification basée sur les revendications dans SharePoint 2010(éventuellement en anglais). Une fois ce cookie FedAuth en ma possession, je le réutilise pour effectuer un appel en vue d’extraire des données de liste par le biais de REST.

L’appel est légèrement différent car nous devons effectuer des opérations GET HTTP directement sur le service de données de liste dans SharePoint 2010. Ce service est accessible dans tout site en naviguant jusqu’au répertoire _vti_bin. Par exemple, si vous avez un site sur https://contoso, pour obtenir tous les éléments de la liste Contacts sur ce site, vous pourriez exécuter une requête à https://contoso/_vti_bin/listdata.svc/Contacts. Les données sont renvoyées au format XML, que vous pouvez ensuite traiter selon les besoins de votre application.

Voici un exemple de code qui réutilise la méthode pour obtenir un ticket FedAuth, puis extrait une liste de tous les éléments dans la liste Contacts.

private void GetRestDataBtn_Click(object sender, EventArgs e)
{
try
{
//This is the REST endpoint that I want to use to get all Contacts.
string endpoint = "https://fc1/_vti_bin/listdata.svc/Contacts";
//Get the FedAuth cookie.
string FedAuth = GetSamlToken();
//Make a request to the REST interface for the data.
HttpWebRequest webRqst = (HttpWebRequest)WebRequest.Create(endpoint);
webRqst.UseDefaultCredentials = true;
webRqst.Method = "GET";
webRqst.Accept = "*/*";
webRqst.KeepAlive = true;
//Create the FedAuth cookie that goes with our request.
CookieContainer cc = new CookieContainer();
Cookie samlAuth = new Cookie("FedAuth", FedAuth);
samlAuth.Expires = DateTime.Now.AddHours(1);
samlAuth.Path = "/";
samlAuth.Secure = true;
samlAuth.HttpOnly = true;
Uri samlUri = new Uri(SamlTxt.Text);
samlAuth.Domain = samlUri.Host;
cc.Add(samlAuth);

//Plug our cookie into the request.
webRqst.CookieContainer = cc;
//Read the response now.
HttpWebResponse webResp = webRqst.GetResponse() as HttpWebResponse;
//Make the request and get the response.
StreamReader theData = new StreamReader(webResp.GetResponseStream(), true);
string payload = theData.ReadToEnd();
theData.Close();
webResp.Close();

//Create the XML classes for working with the results.
XmlDocument xDoc = new XmlDocument();
//XML doc, loaded with the results.
xDoc.LoadXml(payload);
//Namespace manager, used for querying.
XmlNamespaceManager ns = new XmlNamespaceManager(xDoc.NameTable);
ns.AddNamespace("b",
"http://www.w3.org/2005/Atom");
ns.AddNamespace("m",
"https://schemas.microsoft.com/ado/2007/08/dataservices/metadata");
ns.AddNamespace("d",
"https://schemas.microsoft.com/ado/2007/08/dataservices");
//Query for items.
XmlNodeList nl = xDoc.SelectNodes("/b:feed/b:entry/b:content/m:properties", ns);
//Create a list to hold the results.
List<Contact> Contacts = new List<Contact>();
//Enumerate the results.
foreach (XmlNode xNode in nl)
{
Contacts.Add(new Contact(
xNode.SelectSingleNode("d:FirstName", ns).InnerText,
xNode.SelectSingleNode("d:LastName", ns).InnerText,
xNode.SelectSingleNode("d:Company", ns).InnerText,
xNode.SelectSingleNode("d:JobTitle", ns).InnerText,
xNode.SelectSingleNode("d:EMailAddress", ns).InnerText));
}
//Bind to the DataGridView on my form.
ContactGrd.DataSource = Contacts;
}
catch (Exception ex)
{
//Add your error code handling here.
}
}
public class Contact
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string Company { get; set; }
public string JobTitle { get; set; }
public string Email { get; set; }
public Contact(string First, string Last, string Company, string Title, string Email)
{
this.FirstName = First;
this.LastName = Last;
this.Company = Company;
this.JobTitle = Title;
this.Email = Email;
}
}

En parcourant ce code, on constate qu’il obtient tout d’abord le cookie FedAuth à partir de SharePoint 2010, comme illustré dans le billet de blog mentionné plus haut : Utilisation du modèle objet client avec un site à authentification basée sur les revendications dans SharePoint 2010(éventuellement en anglais). Une fois le cookie obtenu, une nouvelle HttpWebRequest est exécutée pour appeler l’interface REST dans SharePoint afin d’extraire tous les éléments de la liste Contacts. Un nouveau cookie est créé lorsque le cookie FedAuth qui a été extrait peut être placé ; c’est cela qui permet à SharePoint de voir notre demande comme authentifiée. Une fois le cookie ajouté, la demande est effectuée auprès de l’interface REST dans SharePoint en vue d’extraire les données. Les résultats sont placés dans la charge utile de la variable chaîne.

Conseil 3 : ajout d’une revendication personnalisée à une stratégie d’application Web à l’aide de Windows PowerShell dans SharePoint 2010

Je me suis rendu compte que ce processus était beaucoup plus difficile que prévu, puis beaucoup plus facile que prévu une fois terminé ; j’ai donc décidé de créer un conseil rapide à ce sujet. La tâche consiste à ajouter une revendication personnalisée à une application Web à l’aide de Windows PowerShell.

L’ajout d’une revendication personnalisée à une application Web est simple à effectuer à l’aide de l’interface utilisateur de l’Administration centrale de SharePoint. Toutefois, utiliser Windows PowerShell est une paire de manches, en particulier lorsqu’on ne l’a jamais fait. L’approche que j’ai initialement adoptée consistait à créer un objet New-SPClaimsPrincipal à ajouter aux stratégies de la zone. Juste pour informations, voici quelques approches différentes que j’ai examinées (il existe une multitude d’autres permutations possibles).

#$tp = Get-SPTrustedIdentityTokenIssuer -Identity "ADFS with Roles"
#$cp = Get-SPClaimProvider -Identity "BasketballTeamProvider"

#$account = New-SPClaimsPrincipal -ClaimValue "Wingtip Toys" -ClaimType "Role" -TrustedIdentityTokenIssuer $tp
#$account = New-SPClaimsPrincipal -Identity "Wingtip Toys" -TrustedIdentityTokenIssuer $tp
#$account = New-SPClaimsPrincipal -Identity "c:0ǹ.c|basketballteamprovider|wingtip toys" -IdentityType EncodedClaim
#$account = New-SPClaimsPrincipal -ClaimValue "Wingtip Toys" -ClaimType "http://schema.steve.local/teams" -ClaimProvider $cp.ClaimProvider
#$account = New-SPClaimsPrincipal -EncodedClaim "c:0ǹ.c|basketballteamprovider| wingtip toys "

Une grande partie de ces approches ont permis d’ajouter la revendication, mais l’identificateur était clairement incorrect car la stratégie n’était pas implémentée (autrement dit, j’accordais un Contrôle total, mais les utilisateurs disposant de cette revendication ne pouvaient pas se connecter). Là était la phase « plus difficile que prévu initialement ».

Pour que cela fonctionne, aucun objet New-SPClaimsPrincipal n’était nécessaire. Au lieu de cela, le code Windows PowerShell suivant a ajouté la revendication et tout a fonctionné correctement.

$WebAppName = "https://contoso1"
$wa = get-SPWebApplication $WebAppName
$account = "c:0ǹ.c|basketballteamprovider|wingtip toys "

$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"Claims Role")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

Ainsi donc, la solution consistait à ajouter la revendication personnalisée comme simple chaîne. Notez que pour obtenir la valeur $account, j’ai juste ajouté la stratégie à l’aide de l’Administration centrale, puis copié la valeur de revendication affichée une fois terminé. J’utilise ensuite la valeur de revendication que j’ai copiée à partir de l’interface utilisateur dans mon code. Avec un peu de chance, cela vous permettra de gagner un peu de temps dans le cas où vous rencontreriez ce scénario.

Conseil 4 : gestion d’autorités racines de confiance pour l’authentification basée sur les revendications dans l’Administration centrale de SharePoint 2010

J’ai décidé de créer ce conseil pour mettre en évidence une autre manière de gérer les autorités racines de confiance dans SharePoint 2010. Ceux d’entre vous qui ont déjà créé des sites à authentification basée sur les revendications savent qu’il faut ajouter tous les certificats de la chaîne de certificats de signature de jeton à la liste SharePoint qui contient les sites approuvés SharePoint. Tous les exemples que j’ai fournis dans mes billets de blogs l’ont fait par le biais de Windows PowerShell. Il faut savoir que la même opération peut s’effectuer par le biais de l’Administration centrale.

Vous pouvez ajouter, modifier ou supprimer une autorité racine de confiance pour votre chaîne de certificats de signature de jeton à l’aide de l’Administration centrale. Pour cela, accédez à l’Administration centrale de SharePoint 2010, cliquez sur Sécurité, puis sur Gérer la relation d’approbation. Vous accédez alors à la page Relation d’approbation, qui répertorie les autorités racines de confiance définies. Vous pouvez ajouter ou modifier des approbations en naviguant jusqu’à un certificat téléchargé et utilisé par SharePoint pour établir une approbation. Assurez-vous simplement de ne pas supprimer le certificat approuvé local, qui est réservé au Service d’émission de jeton de sécurité (STS) interne de SharePoint.

Conseil 5 : résolution des problèmes de connexion à la page d’authentification AD FS dans SharePoint 2010

Ayant souvent eu des difficultés à résoudre des problèmes de connexion à la page d’authentification AD FS (Active Directory Federation Service), j’ai pensé qu’il serait judicieux de présenter le problème suivant et sa résolution car je suis sûr que d’autres l’ont rencontré également.

Supposons que vous avez configuré une application Web SharePoint de façon à utiliser des revendications SAML et que le service IP-STS (Identity Provider Security Token Service) est le Services ADFS (Active Directory Federation Services) 2.0. Parfois, j’observe qu’après que SharePoint a redirigé l’utilisateur vers la page de connexion AD FS, le navigateur se « bloque ». L’état indique « terminé », comme si la page était chargée entièrement, mais seule une page vierge est affichée. La barre d’adresses du navigateur mentionne l’URL de serveur AD FS correcte. Aucune erreur n’est signalée et le navigateur semble indiquer qu’il est à la page de connexion AD FS. Mais vous n’êtes jamais authentifié, aucune information d’identification ne vous est demandée et vous n’êtes jamais renvoyé à votre site SharePoint.

Dans ce cas, je me suis rendu compte que le problème est dû au fait que j’ai un serveur proxy configuré dans mon navigateur et que la demande est redirigée vers le nom de domaine complet du serveur AD FS (autrement dit, https://adfs.contoso.com).

Pour résoudre le problème, dans Internet Explorer, procédez comme suit :

Dans le menu Outils, cliquez sur Options Internet.
Sous l’onglet Connexions, cliquez sur Paramètres réseau.
Cliquez sur Avancé pour ouvrir la fenêtre Paramètres du proxy.

Dans la fenêtre Paramètres de proxy se trouve une zone de texte pour les exceptions. C’est dans cette zone de texte Exceptions que vous ajoutez les URL que vous souhaitez que le serveur proxy ne tente pas de résoudre pour vous. Si vous ajoutez l’URL de votre serveur AD FS à cette liste et que vous enregistrez les modifications, vous devriez pouvoir être redirigé et authentifié correctement.

Malheureusement, dans ce scénario le navigateur ne fournit aucun retour quant à la cause du problème. Si vous recevez une page de navigateur vierge, considérez ce conseil comme une solution éventuelle.

Conclusion

Cet article fournit des réponses aux questions les plus fréquentes concernant l’authentification basée sur les revendications dans SharePoint 2010. Il contient également cinq conseils et des instructions pour vous aider à résoudre les problèmes liés à l’utilisation et à la configuration des revendications et pointe vers d’autres ressources où vous trouverez davantage d’informations.

Ressources supplémentaires

Pour plus d’informations, voir les ressources suivantes :