Écriture d’une page de connexion personnalisée dans le cadre d’une authentification par formulaire pour SharePoint 2010 (Partie 1)

Écriture d’une page de connexion personnalisée dans le cadre d’une authentification par formulaire pour SharePoint 2010 (Partie 1)

Dans SharePoint 2007, l’écriture d’une page de connexion personnalisée pour un site avec authentification par formulaire n’était pas si compliquée. Quelques notions, qui n’étaient pas spécifiques à SharePoint pour la plupart, et certaines astuces étaient nécessaires pour que votre formulaire de connexion adopte l’apparence d’une page de dispositions SharePoint standard. Toutefois, dans l’ensemble, si vous connaissiez ASP.NET et la classe FormsAuthentication, vous pouviez vous lancer. Il s’avère que les choses sont devenues un peu plus complexes dans SharePoint 2010.

Dans ce billet, nous allons parcourir un scénario qui illustre une page de connexion personnalisée. Dans cet exemple, nous décidons qu’une page de connexion entièrement personnalisée est nécessaire : non seulement nous modifions l’apparence, mais nous avons également besoin d’une interface utilisateur complètement différente. Par exemple, peut-être est-il nécessaire de recueillir des informations d’identification d’appartenance auprès de l’utilisateur afin qu’il puisse se connecter, puis que ce dernier entre un ID d’authentification secondaire, comme dans le cas de SecurID. Dans ce cas, nous utiliserons deux zones de texte sur une page ASP.NET pour recueillir le nom d’utilisateur et le mot de passe afin de connecter l’utilisateur par programme.

Le point le plus important à noter ici est que votre ancienne amie, la classe FormsAuthentication, ne sera plus utilisée. En effet, il s’avère que dans SharePoint 2010, les utilisateurs ne recourent pas à l’authentification par formulaire, mais à l’authentification par revendications. Par conséquent, bien qu’il puisse vous sembler que vous utilisez un fournisseur de rôles et un utilisateur d’appartenance ASP.NET standard, ces objets possèdent en réalité un tout nouveau shell d’authentification par revendications. Par conséquent, nous devons utiliser certaines des classes de revendications SharePoint pour accomplir le processus de connexion avec authentification par formulaire.

Je dois ajouter une mise en garde ici ! Normalement, d’une manière ou d’une autre, avant de publier quelque chose sur mon blog, je fais de mon mieux pour m’assurer ou faire valider que les informations publiées constituent la procédure adéquate, idéale ou prise en charge. Dans le cas présent, j’ai, sans succès, essayé de soumettre cette approche à un examen minutieux. J’ai utilisé ce code pour un projet sur lequel j’étais en train de travailler et il fonctionne, mais je ne veux pas que vous ayez une attaque cardiaque si les règles de codage vous indiquent à une date ultérieure que vous devez modifier le code pour qu’il satisfasse à une autre procédure meilleure ou plus appropriée. Bon, m’étant couvert, concentrons-nous sur l’observation du code.

Avant que nous ne commencions, je dois mentionner deux références dont nous aurons besoin et que vous n’avez probablement jamais utilisées. La première est Microsoft.SharePoint.Security.dll, qui se trouve dans la ruche 14 du dossier ISAPI. La seconde est un peu plus délicate et explique en grande partie ma mise en garde plus haut. Vous avez besoin d’une référence à Microsoft.SharePoint.IdentityModel.dll. Toutefois, si vous êtes amené à ajouter des références, vous ne serez pas en mesure de trouver facilement cet assembly, d’où mon double sentiment de gêne et de méfiance légères. Comme je l’ai expliqué dans un autre billet, la meilleure chose à faire consiste à le rechercher sur le système de fichiers, à le copier dans un emplacement facilement accessible et à ajouter votre référence à la version copiée. En règle générale, la procédure que j’utilise pour effectuer cette recherche, peut-être parce que j’appartiens à la vieille école, consiste, depuis une invite de commandes, à accéder à la racine du lecteur, puis à exécuter la commande « dir Microsoft.SharePoint.IdentityModel.dll /s ». Une fois l’assembly trouvé, vous souhaiterez probablement ajouter une série d’instructions using :

using System.Web.Security;

using System.IdentityModel.Tokens;

using Microsoft.SharePoint;

using Microsoft.SharePoint.IdentityModel;

Ce souci étant dissipé, lorsque j’appelle la classe de revendications pour valider les informations d’identification utilisateur pour l’authentification par formulaire que l’utilisateur a tapées, je dois lui indiquer le fournisseur d’appartenances et de rôles qu’elle doit utiliser. Il suffit d’indiquer un nom. Dans mon cas, comme j’avais écrit un fournisseur d’appartenances et de rôles personnalisé pour ce que j’étais en train de réaliser, j’ai simplement recherché ce fournisseur en passant en revue tous les fournisseurs connus de mon application Web :

//get the provider names for our type

string userProviderName = string.Empty;

string roleProviderName = string.Empty;

//get the membership provider name

foreach (MembershipProvider p in Membership.Providers)

{

if (p.GetType().Equals(typeof(Microsoft.SE.AnonProvider.Users)))

       {

       userProviderName = p.Name;

              break;

       }

}

//get the role provider name

foreach (RoleProvider rp in System.Web.Security.Roles.Providers)

{

if (rp.GetType().Equals(typeof(Microsoft.SE.AnonProvider.Roles)))

       {

       roleProviderName = rp.Name;

              break;

       }

}

 

Bon, parfait, j’ai les noms des fournisseurs. À présent, nous devons récupérer le nom d’utilisateur et le mot de passe et renvoyer un jeton de sécurité. À cette fin, nous allons utiliser la classe SPSecurityContext. Elle possède une méthode spécialement conçue pour effectuer automatiquement cette connexion avec authentification par formulaire ; si elle réussit, elle retourne un jeton de sécurité, sinon elle retourne la valeur null. Voici ce à quoi ressemble la syntaxe lorsque nous authentifions les informations d’identification utilisateur :

SecurityToken tk = SPSecurityContext.SecurityTokenForFormsAuthentication(

new Uri(SPContext.Current.Web.Url), userProviderName, roleProviderName,

          UserNameTxt.Text, PasswordTxt.Text);

 

J’ai donc transmis une URI pour le site auprès duquel j’essaie de m’authentifier, je lui ai indiqué le nom de mes fournisseurs d’appartenances et de rôles et j’indique les valeurs de nom d’utilisateur et de mot de passe qui ont été tapées dans les zones de texte de ma page de connexion. À présent, je dois m’assurer que mon jeton de sécurité n’a pas pour valeur null, auquel cas je dois écrire un jeton de session. Cette opération est réalisée à l’aide de SPFederationAuthenticationModule. Une fois que j’ai écrit mon jeton de session, je peux rediriger l’utilisateur vers la page ou la ressource qu’il a demandée. Voici le reste du code qui effectue cette opération :

if (tk != null)

{

//try setting the authentication cookie

SPFederationAuthenticationModule fam = SPFederationAuthenticationModule.Current;

fam.SetPrincipalAndWriteSessionToken(tk);

       //look for the Source query string parameter and use that as the redirection

       string src = Request.QueryString["Source"];

       if (!string.IsNullOrEmpty(src))

       Response.Redirect(src);

}

else

{

StatusLbl.Text = "The credentials weren't valid or didn't work or something.";

}

 

À présent, si toutes les opérations se sont déroulées correctement, il suffit de récupérer le paramètre de chaîne de requête Source, qui nous indique l’endroit vers lequel l’utilisateur était initialement redirigé. Ensuite, la procédure prend fin en ce qui concerne l’utilisateur.

J’espère que ces informations vous seront utiles. Je suis conscient de la difficulté de rechercher de la documentation sur la meilleure marche à suivre pour effectuer cette procédure. Dans la partie 2, nous allons voir comment procéder différemment dans le cadre d’un autre scénario. Dans ce dernier, une personne accepte les conditions d’utilisation d’un site Web avant d’utiliser celui-ci pour la première fois. À cette fin, nous essaierons d’étendre la page de connexion de base et d’ajouter un gestionnaire au moment de la connexion.

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Writing A Custom Forms Login Page for SharePoint 2010 Part 1.