Écriture d'une page de connexion personnalisée avec authentification par formulaire pour SharePoint 2010

Cet article est la traduction la plus fidèle possible de l'article original de Steve Peschka, Writing A Custom Forms Login Page for SharePoint 2010 Part 1.

Dans SharePoint 2007, écrire une page de connexion personnalisée pour un site avec l'authentification par formulaire n'était pas si difficile. Il y avait quelques trucs à savoir, qui n'étaient pas spécifiques à SharePoint pour la plupart, et certaines astuces à connaître pour que votre formulaire de connexion adopte l'apparence et l'ergonomie d'une page avec la disposition SharePoint standard. Dans l'ensemble, toutefois, si vous connaissiez ASP.NET et la classe FormsAuthentication, vous étiez prêt à vous lancer. Il se trouve que les choses se compliquent un peu plus dans SharePoint 2010.

Dans cet article, nous allons parcourir un scénario illustrant une page de connexion personnalisée. Dans cet exemple, nous décidons que nous avons besoin d'une page de connexion entièrement personnalisée - nous ne modifions pas que l'apparence et l'ergonomie, mais nous avons également besoin d'une interface utilisateur complètement différente. Par exemple, peut-être avons-nous besoin de recueillir les informations d'identification d'appartenance qui sont utilisées pour se connecter, et peut-être avons-nous besoin que quelqu'un saisisse un ID d'authentification secondaire, comme dans le cas de SecurID. Dans ce cas, nous allons avoir deux zones de texte sur une page ASP.NET afin de recueillir le nom d'utilisateur et le mot de passe, et nous allons devoir les utiliser afin de connecter l'utilisateur par programme.

Le point le plus important à se rappeler ici est que votre vieille amie, la classe FormsAuthentication, ne sera plus utilisée. La raison en est que dans SharePoint 2010, les utilisateurs n'ont pas recours pas à l'authentification par formulaire (« FBA users »), mais à l'authentification par revendications (« claims users »). Donc, bien que vous puissiez penser que vous utilisez un fournisseur de rôles et d'appartenance ASP.NET standard, sous le capot ces objets ont en fait une belle enveloppe d'authentification par revendications. Par conséquent, nous devons utiliser certaines des classes de revendications SharePoint pour mettre en œuvre 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 savoir - ou faire valider par quelqu'un - que les informations publiées constituent la procédure adéquate, idéale ou prise en charge. Dans le cas actuel, j'ai essayé plusieurs fois de soumettre cette approche à un examen minutieux, mais sans succès. 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 quelqu'un fasse un arrêt 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 façon meilleure ou plus appropriée de faire les choses. Maintenant que j'ai bien couvert mes arrières, regardons tout simplement un peu de code.

Avant que nous ne commencions, il y a deux références dont nous allons avoir besoin et que vous n'avez probablement jamais utilisées auparavant. La première est Microsoft.SharePoint.Security.dll, et elle se trouve dans la ruche 14 du dossier ISAPI. L'autre est un peu plus délicate et explique en grande partie ma mise en garde ci-dessus. 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, ce qui explique que je sois à la fois un peu embarrassé et méfiant. Comme je l'avais décrit dans un autre article, la meilleure chose que j'ai trouvée à 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. La façon dont je procède d'habitude, peut-être parce que je suis de 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 » et ainsi effectuer cette recherche. Une fois celui-ci trouvé, vous souhaiterez probablement ajouter un groupe d'instructions using :

using System.Web.Security;
using System.IdentityModel.Tokens;
using Microsoft.SharePoint;
using Microsoft.SharePoint.IdentityModel;

Donc, maintenant que nous sommes libérés de ce petit côté gênant, lorsque j'appelle la classe de revendications pour valider les informations d'identification utilisateur pour l'authentification par formulaire que l'utilisateur a saisies, je dois lui indiquer le fournisseur d'appartenances et de rôles qu'elle devrait utiliser. Il suffit d'indiquer un nom. Dans mon cas particulier, j'avais écrit un fournisseur d'appartenances et de rôles personnalisé pour ce que j'étais en train de réaliser, donc j'ai simplement passé en revue tous les fournisseurs connus de mon application Web jusqu'à trouver le mien :

//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, super, j'ai les noms de mes fournisseurs. Maintenant, nous devons récupérer le nom d'utilisateur et le mot de passe et renvoyer un SecurityToken (jeton de sécurité). Pour faire cela, nous allons utiliser la classe SPSecurityContext. Elle possède une méthode justement conçue pour effectuer cette connexion avec authentification par formulaire pour nous ; si elle réussit, elle renvoie un SecurityToken, sinon elle renvoie la valeur null. Voici à quoi cela ressemble 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 un 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 je transmets les valeurs de nom d'utilisateur et de mot de passe qui ont été saisies dans les zones de texte de ma page de connexion. Maintenant, je dois vérifier pour m'assurer que mon SecurityToken n'a pas pour valeur null, et si tel est le cas je dois écrire un jeton de session. Ceci est réalisé à l'aide de SPFederationAuthenticationModule. Une fois que j'ai écrit mon jeton de session, je peux aller de l'avant et rediriger l'utilisateur vers la page ou la ressource qu'il a demandée. Voici le reste du code qui effectue cela :

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 vous voyez que si j'ai tout effectué correctement, il suffit de récupérer le paramètre de chaîne de requête Source, parce qu'il nous indique l'endroit vers lequel l'utilisateur était initialement redirigé. Une fois que j'ai cela, je peux envoyer les utilisateurs à leur destination.

Espérons que ceci vous aidera à vous mettre en selle. Je sais que ce fut vraiment difficile de trouver de la documentation sur la meilleure marche à suivre lorsque je la cherchais. Dans la partie 2, nous allons voir comment réaliser cela d'une manière différente dans le cadre d'un autre scénario. Dans ce scénario nous voudrons qu'un utilisateur accepte des conditions d'utilisation d'un site Web avant d'utiliser celui-ci pour la première fois. Pour cela, nous allons essayer d'étendre la page de connexion de base et d'ajouter un gestionnaire au moment de la connexion.

Je tiens ici à remercier Steve Peschka de m'avoir autorisé à traduire son article.
Je remercie tomlev pour sa relecture technique et ses propositions.
Je remercie également ClaudeLELOUP pour sa relecture orthographique et ses propositions.