Accéder à Sharepoint dans une application Silverlight pour Windows Phone 7 (2/3) : Côté Sharepoint

Article
12/15/2010

Cet article est le second d’une série de 3:

Accéder à Sharepoint dans une application Silverlight pour Windows Phone 7 (1/3) : Introduction
Accéder à Sharepoint dans une application Silverlight pour Windows Phone 7 (2/3) : Côté Sharepoint
Accéder à Sharepoint dans une application Silverlight pour Windows Phone 7 (3/3) : Côté client Silverlight pour WP7

Je vous recommande vivement de lire le premier article qui définit le besoin et introduit les concepts qui seront mis en place pour arriver à nos fins.

Cette deuxième partie est consacrée à la configuration de Sharepoint pour permettre une authentification Forms Based avec les claims. En effet, une application Silverlight devra s’authentifier à Sharepoint en Forms. Or, Sharepoint permet l’authentification Forms Based uniquement à travers les Claims.

Ampoule N’hésitez pas à lire ce post qui explique simplement le fonctionnement des Claims et les mécanismes d’authentification en général dans Sharepoint 2010.

Il y a 2 grandes parties dans ce post:

La migration de la WebApp existante pour qu’elle supporte les Claims
La configuration Forms Based avec un provider d’identité basé sur un AD existant

Dans ce chapitre, je pars du principe que vous souhaitez accéder à un site existant et donc utiliser une WebApp existante. C’est ce point qui rend l’opération délicate car cette opération est irréversible !
L’opération est plus simple si vous partez d’une nouvelle WebApp, ce que vous pouvez faire dans un premier temps, pour tester votre dextérité à la configuration de Sharepoint dans ce contexte précis. Dans ce cas, vous passer directement à l’étape 3
Si vous ne savez pas comment est configurée votre Web App, l’étape 1. vous permettra d’en avoir le coeur net. Elle permet uniquement de vérifier si elle déjà en mode Claims.

Les étapes

[Vous pouvez sauter les étapes 1 et 2 si vous créez une nouvelle WebApp]

Déterminer si ma WebApp possède un provider d’authentification standard ou Claims
Migrer ma WebApp pour qu’elle passe en mode Claims si ce n’est pas encore le cas
Configurer ma WebApp pour qu’elle supporte 2 modes d’authentification :
- NTLM c’est à dire un mode d’authentification qui utilise les credentials de l’utilisateur authentifié dans la session courante (NetworkCredentials).
  Ainsi mon site reste accessible comme auparavant depuis un PC.
- Forms Based (FBA) qui va me permettre de spécifier un nom d’utilisateur et un mot de passe à l’aide de 2 chaines de caractères (en clair ).
  C’est le mode d’authentification qui sera utilisée par mon application Silverlight pour Windows Phone 7
Configurer le mode d’authentification FBA : utiliser mon AD existant comme un provider pour que les credentials passés en mode FBA soient vérifiés dans mon annuaire d’entreprise (comme c’est le cas pour mon authentification NTLM)
Ajouter les utilisateurs qui sont autorisés à accéder depuis une application WP7 dans la policy pour ma WebApp

1. Vérifier le provider d’authentification de ma WebApp

Cette étape va nous permettre d’identifier la WebApp à traiter, et de vérifier s’il faut la faire évoluer en mode Claims pour supporter l’authentification FBA.

Lancez la console d’administration de Sharepoint :

Allez dans Site Actions/Site Settings :

Puis dans Application Management à partir du menu de gauche, choisissez Manage Web Applications :

Sélectionnez la Web App qui héberge la collection de sites à laquelle vous souhaitez accéder depuis un Windows Phone 7 (la colonne URL devrait vous permettre de l’identifier facilement), puis cliquez sur “Authentication Providers” dans le bandeau:

Cliquez sur Default pour voir la configuration du mode d’authentification de votre Web App :

Si vous voyez “Windows” apparaitre en tant que provider c’est qu’il faut convertir votre WebApp pour utiliser les claims.

2. Migration à partir du provider standard vers les Claims

Attention, cette procédure est irréversible ! Doigts croisés

Je vous encourage fortement à faire un backup avant de convertir votre WebApp pour qu’elle supporte les Claims

La procédure de conversion ne peut s’effectuer qu’en Power Shell.

Lancez le management shell en mode administrateur:

Tapez le script suivant, en spécifiant l’URL de votre WebApp (ex : “https://stephe-msft:16483”) et votre identifiant d’administrateur (ex: “EUROPE\stephe”) :

 $WebAppName = "https:// yourWebAppUrl"
$account = "yourDomain\yourUser"
$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default

Tapez ‘O’ au prompt de confirmation de migration. Attention, cette commande peut prendre un certain temps pendant lequel votre WebApp sera indisponible.

Tapez le script suivant pour définir l’administrateur du site :

 $wa = get-SPWebApplication $WebAppName
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

Tapez ce script pour définir la stratégie qui donnera tous les accès à l’utilisateur

 $zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

Tapez ce script pour déclencher la migration des utilisateurs (et patientez !)

 $wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)

Après ces étapes, vos sites sont accessibles par vos anciens utilisateurs du domaine.

Ampoule Après plusieurs essais, sur différentes WebApp j’ai remarqué que la réactivité du site pouvait parfois être altérée dans les premiers moments, voir les premières heures (en tout cas, c’est ce qui s’est passé dans mon cas).

Ampoule Si après avoir laissé “reposer” votre Sharepoint vous avez toujours des soucis de connexion, consultez technet à cette page qui vous aidera à identifier l’origine possible de problèmes liés à une migration

3. Configurer ma WebApp pour qu’elle supporte 2 modes d’authentification : NTLM et Forms

A ce stade, vous disposez d’une WebApp en mode Claims.

Rejouez la séquence de l’étape 1. dans la console d’administration, pour vous retrouver devant le menu “Authentication Providers” de la WebApp qui doit à présent afficher un provider de type Claims :

Cliquez sur Default pour éditer les paramètres d’authentification, et activez :

l’authentification NTLM (qui est déjà cochée normalement)
l’authentification Forms Based en indiquant un nom de provider que l’on spécifiera dans les fichiers de configuration tout à l’heure

Cliquez Save en base de l’écran

4. Configuration du mode d’authentification Forms

Nous allons modifier 3 fichiers de configuration pour y définir le provider “admembers”.

Pour cela, il faut passer par le Gestionnaire de Services IIS que vous pouvez lancer en tapant “iis” dans l’intitulé de commande du menu démarrer.

Les fichiers de configurations se trouvent respectivement dans les répertoires associés aux 3 éléments encadrés, qui sont accessibles en faisant un click droit sur l’élément, puis “Explorer”.

4.1. Modification du web.config de la WebApp

Dans notre exemple ma WebApp est “Sharepoint – 16483”.

Editez le fichier web.config avec notepad, un quelconque éditeur xml ou même Visual Studio.

Recherchez la section suivante dans le fichier :

     <membership defaultProvider="i">
      <providers>
        <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      </providers>
    </membership>

Puis ajoutez notre provider admembers dans la liste des membership providers à l’aide du snippet suivant:

 <add name="admembers" 
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
connectionStringName="adconn" 
enableSearchMethods="true" 
attributeMapUsername="sAMAccountName" />

Nouvelle version de la section dans le fichier :

 <membership defaultProvider="i">
  <providers>
     <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
     <add name="admembers" 
    type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
    connectionStringName="adconn" 
    enableSearchMethods="true" 
    attributeMapUsername="sAMAccountName" />
    
  </providers>
</membership>

A présent nous avons besoin d’une chaine de connexion référençant l’annuaire contenant vos utilisateurs.

Dans notre exemple, c’est LDAP://europe.corp.microsoft.com et la chaine de connexion correspondante est :

 <connectionStrings>
  <add name="adconn" connectionString="LDAP://europe.corp.microsoft.com/DC=europe,DC=corp,DC=microsoft,DC=com" />
</connectionStrings>

Ajoutez la chaine de connexion adconn dans une nouvelle section, juste au-dessus de la balise <system.web>, ce qui nous donne pour la nouvelle version :

 ...
</Sharepoint>
  <connectionStrings>
    <add name="adconn" connectionString="LDAP://europe.corp.microsoft.com/DC=europe,DC=corp,DC=microsoft,DC=com" />
  </connectionStrings>
  <system.web>
    <securityPolicy>
      <trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\config\wss_mediumtrust.config" />
...

Enregistrez le fichier.

4.2. Modification du web.config de la console d’administration

Editez le fichier web.config.

Ajoutez la chaine de connexion adconn dans une nouvelle section, juste au-dessus de la balise <system.web>.

 <connectionStrings>
  <add name="adconn" connectionString="LDAP://europe.corp.microsoft.com/DC=europe,DC=corp,DC=microsoft,DC=com" />
</connectionStrings>

Ajoutez le provider ci-dessous dans la balise <system.web>:

 <membership defaultProvider="admembers"> 
    <providers> 
        <add name="admembers" 
        type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
        connectionStringName="adconn" 
        enableSearchMethods="true" 
        attributeMapUsername="sAMAccountName" /> 
    </providers> 
</membership>

Enregistrez.

4.2. Modification du web.config du SecurityTokenService Application

Editez le fichier web.config.

Placez-vous en fin de fichier juste au-dessus de la balise </configuration> et insérez la chaine de connexion et le provider en collant le snippet suivant:

 
  <connectionStrings>
    <add name="adconn" connectionString="LDAP://europe.corp.microsoft.com/DC=europe,DC=corp,DC=microsoft,DC=com"/>
  </connectionStrings>

  <system.web>
    <membership defaultProvider="admembers">
      <providers>
        <add name="admembers"
        type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
        connectionStringName="adconn"
        enableSearchMethods="true"
        attributeMapUsername="sAMAccountName" />
      </providers>
    </membership>
  </system.web>

Enregistrez.

Lancez un intitulé de commandes en mode administrateur et tapez iisreset

A ce stade là, si vous tentez d’atteindre un site de votre WebApp dans un navigateur, vous serez promptés pour choisir le mode d’authentification : Windows ou FBA. L’authentification en mode Windows (NTLM) fonctionne toujours si tout se passe bien.

5. Ajouter les utilisateurs qui sont autorisés à accéder depuis une application WP7 dans la policy pour ma WebApp

Dans l’administation centrale de Sharepoint, placez-vous sur la page de configuration des WebApp (suivez l’étape 1. si vous souhaitez être guidés) :

Sélectionnez votre WebApp et dans le bandeau cliquez sur “User Policy”. Seuls les utilisateurs NTLM sont présents dans la policy, nous allons y ajouter ceux qui sont autorisés à se connecter en FBA. Cliquez sur “Add Users”.

Puis Next

Dans la section Users, cliquez sur l’annuaire pour rechercher des utilisateurs:

Dans mon cas, j’autorise tous les membres du provider LDAP admembers à avoir le contrôle total. Vous pouvez être plus restrictif en choisissant certains comptes de l’AD, mais il faut les rechercher dans la section “Forms Auth” et non pas “Active Directory” pour qu’ils soient associés à l’authentification FBA.

Cliquez Ok.

Cochez les permissions adéquates (Full Control dans mon cas) et cliquez sur Finish.

Vous pouvez à présent vous connecter à votre site Sharepoint avec 2 modes d’authentification différents, mais tous deux basés sur le même Active Directory:

en NTLM
en Forms

D’une part, vos utilisateurs peuvent toujours accéder au site comme auparavant, à partir d’un navigateur en utilisant les credentials de la session(authentification NTLM). Evidemment, ils peuvent également utiliser l’authentification Forms Based dans le navigateur s’ils le souhaitent et si vous leur en avez donné les autorisations. Dans ce cas, ne préfixez pas l’identifiant par le nom de domaine lorsque vous saisissez les credentials (ex : “stephe” et non pas “EUROPE\stephe”).

D’autre part, vos applications Windows Phone 7 accèderont à Sharepoint en passant par l’authentification Forms Based.

En fait, le plus dur est fait. Vous pouvez maintenant vous attaquer à l’application Windows Phone 7 Rire :

Accéder à Sharepoint dans une application Silverlight pour Windows Phone 7 (3/3) : Côté client Silverlight pour WP7

Comments

Anonymous
December 14, 2010
Merci pour toutes ces infos Stéphanie :) Je teste ça ce week-end!
Anonymous
December 19, 2010
Merci pour ce post très utile et bien illustré. Une question cependant : est-il possible d'accorder des permissions à un compte, qu'il vienne par la zone AD ou la zone formulaire, sans ête obligé d'ajouter 2 autorisations (une pour chaque provider d'authent) ? Est-ce que Claims permet de faire ça ? Merci.
Anonymous
December 21, 2010
Bonjour Cédric, je n'ai pas creusé la question, il faut dire que je suis plutôt "dev driven" ;o). Mon premier avis (à prendre avec des pincettes) est qu'il faut forcément renseigner les utilisateurs NTLM et FB séparément, car ils sont effectivement vus comme des utilisateurs différents, avec une provenance différente, lors de ce premier filtre. Ce n'est qu'ensuite au niveau du provider que l'on pioche dans la même source (=AD). Le fait qu'on utilise un AD commun est finalement transparent pour SP. A bientôt

Share via