SharePoint 2013 : Création et migration d’une application web (et nouveautés sur l’authentification)

[MAJ – 07.04.2013]

Concernant ma phrase de l’article original « Le cmdlet New-SPWebApplication devrait être modifié pour que les applications web utilisent par défaut le provider Claims », et rapport aux différentes versions de SharePoint 2013 :

• 15.0.4128.1014 (Preview) : Le cmdlet crée des applications web n’utilisant pas les claims par défaut,
• 15.0.4420.1017 (RTM) : Pas de changement,
• 15.0.4481.1005 (CU 03.0213) : Pas de changement.

[/MAJ – 07.04.2013]

Ce post va présenter les procédures de création et de migration d’une application web (via l’administration centrale et via PowerShell), ainsi que les nouveautés liées à l’authentification.

Création d’une application web via l’administration centrale

Dans SharePoint 2010, quand vous créez une application web via l’administration centrale, vous avez le choix entre le mode « Classic » ou « Claims » :

Ce choix n’existe plus dans SharePoint 2013, car le provider l’authentification par défaut est désormais Claims; le mode « Classic » est néanmoins toujours supporté mais il est obsolète.

Lorsque vous créez une application web via l’admin. centrale, elle utilise bien le mode « Claims »,

Création d’une application web via PowerShell

La création d’une application web se fait comme dans SharePoint 2010, à savoir via le cmdlet New-SPWebApplication.

Comme nous l’avons vu au chapitre précédent, le provider par défaut est désormais « Claims »; le message qui s’affiche lorsque vous créez une application web comporte des informations intéressantes :

• Le mode d’authentification « Classic » est désormais obsolète,
• Il est recommandé d’utiliser le provider Claims,
• Le cmdlet New-SPWebApplication devrait être modifié pour que les applications web utilisent par défaut  le provider Claims.

Je crée ici une application web avec les paramètres classiques pour voir ce qu’il en résulte.

Et effectivement par défaut cette application web utilise le mode « Classic » (le paramètre « UseClaimsAuthentication » est à « False »).

Création d’une application web en mode Claims

En regardant de plus près la page concernant le cmdlet New-SPWebApplication, on note qu’un paramètre nommé « AuthenticationProvider » existe, sa description : « Specifies the authentication provider or providers that apply to a Web application ».

La méthode de création va donc être la suivante :

• Création d’un provider d’authentification via le cmdlet New-SPAuthenticationProvider,
• Création de l’application web en lui spécifiant ce provider.

Le script PowerShell correspondant est le suivant :

$claimsProvider = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication -DisableKerberos

New-SPWebApplication -Name « Web App ClaimsT » -ApplicationPool « Sharepoint – 80 » -Port « 80 » -DatabaseName « SP15_Content_ClaimsT » -HostHeader « WAClaimsT.spasipe.local » -AuthenticationMethod -NTLM -AuthenticationProvider $claimsProvider

Cette fois, on constate que l’application web utilise bien les Claims.

Migration d’une application web

Etant donné ce qui a été vu plus haut, il va falloir un moment ou à un autre se poser la question de la migration des applications web, du mode « Classic » vers le mode « Claims ».

La méthode MigrateUsers utilisée avec SharePoint 2010 est désormais obsolète et vous devrez utiliser le nouveau cmdlet Convert-SPWebApplication.

L’exemple suivant va migrer l’application web créée plus haut dans ce post vers le mode Claims.

Si on jette un oeil dans SQL Server sur la table « UserInfo ».

Avant :

Après : les login ont bien été encodés.

A titre d’information, concernant le nouveau login de « SPASIPE\administrator » devenu « i:0#.w\SPASIPE\administrator », les parties identifiables sont les suivantes :

• i : identity claim
• # : user logon name
• . : type « string »
• w : délivré par Windows

Vous pouvez consulter ce très bon article  si vous voulez en savoir plus sur l’encodage des claims.