PAC Blog

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.