Dec.07

[WSS] Fournisseurs d’authentification sous Windows SharePoint Service 3.0

Avant de rentrer dans le vif du sujet, je vous rappelle que WSS (Windows Sharepoint Service) version 3.0 est sortie en version RTM depuis le 13 novembre. Vous pouvez le téléchargement librement (à condition d’avoir un Windows authentique!) à cette adresse : http://www.microsoft.com/downloads/…. Vous y trouverez les versions US, FR, et autres.
La procédure d’installation est sensiblement la même que celle que j’avais décrite pour la beta 2 (lire mon post du 20/07) hormis que vous installerez directement le .NET 3.0 étant sortie en RTM à la place des runtimes du Workflow Foundation.
Si vous ne connaissez pas WSS, je vous invite également à lire mon précédent post qui en fait une courte introduction.

Par défaut un site WSS est configuré pour utiliser une authentification de type Windows où chaque compte utilisateur du site est un utilisateur NT (stocké dans la base SAM local ou Active Directory sur un domaine). Pratique dans le cadre d’un portail entreprise ou école mais sur internet cela n’est pas forcement une bonne chose !

Sous WSS vous avez la possibilité de changer le fournisseur d’authentification et donc « facilement » de pouvoir utiliser celui de l’ ASP.NET2 (SqlMembershipProvider/SqlRoleProvider) où les comptes utilisateur seront stockés sur une base SQL ce qui sera plus appréciable pour l’administration.

1/ Préparation de la base
L’instance SQL de WSS (SSEE) n’est exploitable (car verrouillé), il vous faudra donc une autre instante en installant, par exemple, la version Express d’ SQL Server 2005. Une fois opérationnelle, créez une base « MonSiteWSS » ainsi qu’un utilisateur SQL pouvant lire et écrire dans la base.
Enfin utilisez l’utilitaire aspnet_regsql.exe (contenu dans C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727) sur votre base pour préparer les tables ASP.NET

2/ Configuration du Web.config
Editez le fichier Web.config de votre application WSS (C:\Inetpub\wwwroot\wss\VirtualDirectories\xxx) pour y rajouter :

  • La chaine de connexion à votre base. Exemple (à placer dans la balise <configuration>) :

  • Le MembershipProvider (dans <system.web>) et RoleProvider :

Effectuez aussi ces changements dans le Web.config de l’application central de Sharepoint vous comprendrez plus tard pourquoi (merci TheMit ^^) !!

3/ Gestion des comptes
Le but ici est d’avoir une page (ou un site) d’administration des comptes. Pour cela plusieurs solutions sont viables. Par exemple :

  • En créant un site ASP.NET sous Visual Studio 2005, y rajouter la connection string, membership et role provider dans le web.config. Puis dans le menu « Web Site » cliquer sur « ASP.NET Configuration » pour lancer le site d’administration. Dans l’onglet Security l’on pourra administrer les comptes et les rôles.

  • En créant une simple page ASP.NET que l’on vient placer dans le site WSS (dans un dossier admin par exemple) et qui utilise la classe System.Web.Security.Membership et System.web.Security.roles pour gérer vos comptes. (possibilité d’utiliser la MasterPage de WSS pour votre page histoire d’intégrer à fond votre page d’admin dans votre site WSS).

Une fois que vous avez mis en place un moyen d’administration de vos comptes, créez un 1er compte (nommé Admin par exemple).

4/ Changer le fournisseurs d’authentification de votre site WSS
Le changement est assez simple :

  1. Connectez vous à l’ Administration centrale de SharePoint 3.0 (dans les Outils d’administrations)
  2. Dans l’onglet « Gestion des applications », cliquez sur « Fournisseurs d’authentification ».
  3. Sélectionnez la zone de l’application que vous souhaitez modifié (Zone : Par défaut, Internet, Intranet, …)
  4. Sur la page « Modifier l’authentification », sélectionnez l’authentification de type « Formulaires »
  5. Entrez dans « Nom du fournisseur d’appartenances » le nom de votre Membership Provider (dans notre exemple monMembershipProvider) et dans « Nom du gestionnaire de rôles » le nom de votre Role Provider (ici monRoleProvider).
  6. Puis enregistrez les modifications

Avant de quitter l’administration central, n’oubliez pas de définir votre 1er compte comme « Administrateurs de collections de sites » pour qu’il puisse se connecter ! Pour cela toujours dans l’onglet « Gestion des applications », sélectionnez « Administrateurs de collections de sites » et entrez le nom du compte (ex: Admin). C’est la que les informations (connstring, membership, etc..) ajoutées dans le Web.config du site de l’administration central prend tout son sens sinon l’administration central ne reconnaitra pas votre utilisateur !

En retournant sur votre site, vous verrez une belle page de login

.. avec la possibilité de gérer tous vos comptes online (on peut ensuite créer une page d’inscription, récupération des pwd perdu et tout cela très facilement/rapidement avec les objets ASP.NET2)

Alors pas si compliqué 🙂 Un bon article de Andrew Connell est disponible ici. La procédure est un peu différente et l’article beaucoup plus détaillé. A lire !

Moi je dis, vive WSS 🙂

.NET,WSS
Share this Story:
  • facebook
  • twitter
  • gplus

Comments(11)

  1. Dealous
    le 18 décembre 2006 à 18:05

    Pourrais-tu détailler un peu plus l’etape 3 STP dans le cas de la masterpage de wss car tu me perds et comme je ne suis pas un développeur une erreur est vite arrivée. Je te remercie par avance pour cet article vraiment excellent.

    En créant une simple page ASP.NET que l’on vient placer dans le site WSS (dans un dossier admin par exemple) et qui utilise la classe System.Web.Security.Membership et System.web.Security.roles pour gérer vos comptes. (possibilité d’utiliser la MasterPage de WSS pour votre page histoire d’intégrer à fond votre page d’admin dans votre site WSS).

  2. Nucleo-Nix
    le 19 janvier 2007 à 16:00

    L’article réponds en partie à l’une de mes questions, à savoir si une autre base d’authentification que celle d’active Directory etait possible.

    Mais je voudrais maintenant savoir si il est possible d’interroger 2 bases d’authentification, l’Active Directory pour la gestion "interne" du site et l’acces aux modules propres à l’entreprise, et en parallele une Base SQL pour les utilisateurs et intervenant exterieurs (accés Web).

    Le but de la démarche est d’éviter à l’utilisateur AD (une fois logué sur sa machine) d’avoir a se ré-identifer lorsqu’il parcours le Site Web en Qestion.

    Merci

  3. Jean
    le 24 septembre 2007 à 13:10

    Pour Nucleo-Nix… très bon tutoriel en anglais pour faire une authentification dual :
    http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx

  4. Guigui
    le 24 juin 2008 à 14:00

    (Je viens de lire ton article, et une question me turlupine….. je viendrais y répondre ssi personne ne l’a fait avant…)

    Peut on utiliser des SqlMembershipProvider presonnalisé ?

    Ce qui permettrait de taper sur plusieurs sources d’authentifications avant de retourner un échec….
    et aussi de conserver une maitrise total de la structure de la base de donnée.

    Le SqlMembershipProvider (dérivé) nous servirait donc d’interface (program) .

    🙂 si il n’y a pas plus simple !!

  5. Vincent
    le 16 septembre 2008 à 17:26

    Bonjour,

    Merci pour ce tutoriel très bien fait. Je bute juste sur un point : « Effectuez aussi ces changements dans le Web.config de l’application central de Sharepoint vous comprendrez plus tard pourquoi »

    Je comprends bien l’utilité de cette action, mais comment puis je me connecter à l’administration centrale de sharepoint, les compte que j’ai defini précedement dans SQL server ne sont pas encore reconnu, et mon compte windows ne l’est plus? Comment fais je pour m’identifier???

    Merci d’avance pour la reponse

  6. Kalvador
    le 29 septembre 2008 à 16:31

    Salut Sebastien!
    Merci pour ce tutoriel. Dans mon cas je voudrais utiliser SLDAP (secured LDAP) authentification. C’est signifie que sharepoint-server meme fait un secured canal vers centre d’identification (dans mon cas c’est OpenLDAP). La Forme based authentication dans mon cas fonctionne tres bien sans SSL (c’est le port 389), mais quand je change la part de la ligne « useSSL= »false » de « useSSL=true » (port 636) ca ne marche pas 🙁

    Merci d’avance pour toute reponse

  7. Stef
    le 29 octobre 2008 à 20:55

    ATTENTION
    Lorsque je met la config pour le site d’administration je suis incapable de me connecter dans la gestion des applications pour mettre l’autorisation de gestion de site à mon compte ADMIN
    Si qqn a une solution, partagez là s.v.p.

  8. Stef
    le 29 octobre 2008 à 21:58

    SOLUTION :

    Voici la solution à mon problème ainsi que le problème soumis par Vincent le 16 septembre 2008 à 17:26

    La section RoleManager doit être sous ce format:

  9. Stef
    le 29 octobre 2008 à 22:00

    [roleManager enabled= »true » defaultProvider= »AspNetWindowsTokenRoleProvider »]

    PS. Remplacer les [ ] par le signe d’ouverture de tag XML

  10. Kalvador
    le 6 novembre 2008 à 16:47

    Merci a tous, mon problem est resolu …. c’est lie avec les certificas

  11. James West
    le 16 juillet 2009 à 15:26

    salut,
    J’ai fait le tours des tuto concernant la double authentification. Il s’agit d’un travail de longue haleine pour a mettre en place l’authentification par base SQL. En effet il faut egalement agir sur le fichier machine.config et ca personne n’en parle nulle par. De plus meme avec la modification des fichiers web.config, sharepoint ne fait le lien entre les utilisateurs crees dans l’outil d’administration web asp.net. Si quelqu’un peut me donner un lien vers un tutoriel detaillé pas a pas qui marche (c’est a dire: un tutoriel teste par d’autre personne que le redacteur du tutoriel), je suis fortement interesse.

Leave a comment

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Comment