Custom Membership Provider, People picker et web.config

Le Membership Provider étant déjà bien documentée sur la MSDN et le TechNet, je ne souhaite pas revenir sur le partie développement et configuration de celui-ci dans l’administration centrale mais plutôt sur les liens avec le people picker.

Le but étant de revenir sur l’intérêt ou non déclarer les membership provider dans les différentes zones d’une Web Application.

L’étape de déclaration est pourtant bien notée dans le step by step du MSDN mais il est aisé de passer à coté:

For the Central Administration and existing Windows authentication Web application web.config files, you make the same changes as described previously for the forms authentication zone’s web.config file—with one exception…

Sans cette déclaration dans le Web.config, il sera impossible de rechercher un utilisateur ayant un compte dans la nouvelle base de compte (LDAP, SQL, …)

Prenons l’exemple d’un site où les utilisateurs de la zone AD doivent administrer les utilisateurs Custom.

C’est le cas le plus standard et il s’applique souvent aux applications collaboratives que l’on souhaite ouvrir à des utilisateurs externes au domaine. Dans la plupart des cas, les utilisateurs externes n’auront que des droits de collaboration sur le site et ne pourront pas gérer la sécurité. Il est donc indispensable de pouvoir rechercher les utilisateurs Custom dans le peoplepicker depuis un compte AD (et donc depuis une URL AD) pour leur donner des droits.

Dans ce cas, la déclaration du MemberShip doit être la même sur les deux zones. A l’exception de l’attribut defaultprovider qui n’est pas présent dans la zone AD.

Exemple de déclaration de la zone AD:

    <membership >
      <providers>
        <add name="fbaUser" type="Microsoft.IW.customUser, fbaSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b74d22b2d68547b5" />
      </providers>
    </membership>
    <roleManager enabled="true">
      <providers>
        <add name="fbaRole" type="Microsoft.IW.customRole, fbaSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b74d22b2d68547b5" />
      </providers>
    </roleManager>

Exemple de déclaration de la zone Custom:

    <membership defaultProvider="fbaUser">
      <providers>
        <add name="fbaUser" type="Microsoft.IW.customUser, fbaSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b74d22b2d68547b5" />
      </providers>
    </membership>
    <roleManager enabled="true" defaultProvider="fbaRole">
      <providers>
        <add name="fbaRole" type="Microsoft.IW.customRole, fbaSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b74d22b2d68547b5" />
      </providers>
    </roleManager>

Dans les cas ou les users de la zone Custom ne sont pas administrés par ceux de la zone AD

Dans ce cas, pas besoin de déclarer le provider dans la zone AD. En revanche pour pouvoir affecter des droits aux premiers utilisateurs custom vous devrez déclarer le provider dans le web.config de l’administration central pour créer une stratégie sur la zone. cf Gérer les autorisations par le biais d’une stratégie

Dans tous les cas :

  • Les utilisateurs qui font une recherche dans le people picker depuis une URL en authentification Custom n’effectue jamais une requête sur l’AD.

Cela signifie que pour un utilisateurs ayant un compte par le provider Custom et un compte par le provider AD, ces deux comptes ayant les mêmes droits dans SharePoint ils ne recevront pas les mêmes résultats.

  • Peut importe leur mode d’authentification, les utilisateurs effectuant des recherches dans le people picker trouveront toujours les utilisateurs ayant des droits explicites sur cette collection de site.

Prenons l’exemple de deux utilisateurs AD : contoso\user1 et contoso\user2, où seul contoso\user1 a des droits sur la collection de site (il est dans le groupe des membres par exemple). Si je me connecte avec un compte s’authentifiant sur le custom provider en saisissant user1 dans le people picker j’aurai bien un résulat : contoso\user1 mais en saisissant user2 je n’aurai aucun résultat.

En revanche, si je saisi le nom complet à savoir contoso\user2, le compte apparaitra. Cela peut être contourné par l’application de la KB96135.

  1. 09/07/2010 à 11:04 | #1

    Voila qui éclaire beaucoup de choses !

    Mais finalement ajouter les providers non AD au web.config de l’admin centrale n’est pas vraiment nécessaire, sauf si tu veux donner des droits au niveau de la configuration de la ferme à des utilisateurs non AD ?

    A moins que cela ne reste obligatoire pour pouvoir changer des Authentication Providers dans certaines zones ?

    Jonathan

  2. 09/07/2010 à 17:03 | #2
    PACMAN

    Si tu ne déclares pas ton provider Custom dans la zone AD, ton seul moyen pour donner des droits à un administrateur custom est de déclarer ton provider dans la central admin pour pouvoir lui créer une stratégie.

  3. 14/07/2010 à 16:37 | #3

    Mais si tu ne déclare pas ton custom provider dans l’admin centrale, tu pourras toujours donner les droits d’admin de collection directement dans la collection. A condition d’avoir bien sur déclarer le custom provider dans la web app qui contient ta collection en plus de l’AD.
    Non ?

  4. 14/07/2010 à 17:45 | #4

    Ca revient à ce que je disais, non?
    Pour pouvoir donner des droits à compte en provenance de ton custom provider, il faut que celui (le provider) soit déclaré quelquepart. Sinon le people picker ne pourra jamais trouver le compte auquel tu veux donner des droits que ce soit dans la zone AD que dans l’admin centrale. Il faut donc bien déclarer ton provider dans la zone AD ou dans l’administration centrale au minimum le temps de donner des droits à un compte du custom provider.

  5. 15/07/2010 à 13:52 | #5

    Comme cela oui :)

    Enfin au final ce que je sous entendais c’est que la contrainte exprimée par MS (déclarer le custom au niveau de l’admin centrale) est plus une recommandation qu’une contrainte, on peux faire sans.

  1. |
    15/08/2014 à 18:27 | #1

    Coupons_and_Discount_2014

    Custom Membership Provider, People picker et web.config

  2. |
    29/05/2016 à 15:44 | #2

    Manchester United tröja

    Custom Membership Provider, People picker et web.config

RSS des commentaires