Archive

Archive for the ‘Authentication’ Category

SharePoint 2013 Authentication

Hello !!

Dans cet article nous allons voir les modes d’authentification sur SharePoint 15 !

 

Claims no more Classic !

 

Cette nouvelle version continuera de supporter les modes d’authentification Claims et Classic. Légère différence avec 2010 quand même les claims deviennent LA méthode d’authentification par défaut. L’option NTLM à la création de la Web Application disparait … (du moins de l’UI), mais reste heureusement gérable en PowerShell et uniquement en PowerShell.

 

Par ailleurs, le mode NTLM disparaitra dans les prochaines versions de SharePoint mais au fur et a mesure (comme l’apparition et la gestion de PowerShell des Applications SharePoint). Donc il est donc vivement recommandé de passer en Claims.

 

Ouais, … mais la migration … comment on va faire :

Concernant cette migration il y a plusieurs possibilités :

 

La migration des utilisateurs en 2010 ce faisait avec la commande MigrateUser, cette commande n’existe plus. Elle est remplacée par une nouvelle commande « Convert-SPWebApplication »

La conversion se fera donc ainsi si vous êtes en NTLM : Convert-SPWebApplication –Identity http://webapp –ToClaims –RetainPermissions

Dans la mesure où vous avez une application web en authentification classic en 2010, afin de la migrer en claims pour 2013 il y a deux méthodes :

 

La version rapide :

  1. Attacher la DB à une WebApp en claims
  2. Convert-SPWebApplication –Identity http://webapp –toclaims –retainpermissions

 

La version sécurisé :

  1. Créer une webapp SP15 qui utilise les claims
  2. Attacher la DB à cette webapp
  3. Le schéma de la base ce met à jour (vérifier ensuite la fonctionnalité après l’attachement)
  4. Convert-SPWebApplication pour convertir les users NTLM en claims
  5. Détacher la DB de SP15 de l’authentification classic
  6. Attacher la DB à la webApp claims

 

Une des BIG nouveauté est que SharePoint suit les cookies FedAuth dans le Service Distribué de Cache (Distributed Cache Service), dans SP2010 chaque serveur frontal avait sa propre copie, donc si vous changiez de WFE vous deviez vous ré-authentifier. Donc plus besoin des sticky sessions avec les Claims J je vous invite à lire le blog de Steve Peschka sur le sujet http://goo.gl/DGXTj.

 

Dans la continuité des nouvelles fonctionnalités des claims, vous pouvez choisir le type de claim et s’il doit être appliqué, ainsi que l’ordre des types de claims. Vous pouvez aussi ajouter plusieurs certificats au STS de SharePoint, (Set-SecurityTokenServiceConfig).

 

STS supporte la fédération metadata endpoint, SharePoint publie un endpoint qui décris la configuration, les certificats et peut utiliser le même pour plusieurs config. Le problème est que le format utilisé est en JSON, et AD FS ne supporte pas JSON… du moins aujourd’hui (à voir avec une mise à jour de ADFS peut-être ou du dev autour de ADFS)

Il est plus simple de troobleshooter les problématiques d’authentification 🙂 on y retrouve l’ajout / suppression des FedAuth cookies du cache, vers où la requête d’authent est redirigée, quel fournisseur de claims est utilisé, et les raisons pourquoi le cookie tombe en échec (expiration, erreur de decrypt, …)

 

L’authentification : OAuth

 

C’est quoi l’OAuth ?

C’est un protocole open, qui permet de s’authentifier à une API sécurisée de manière simple depuis son poste ou une application web. C’est relativement récent car OAuth Core 1.0 a été finalisé en Octobre 2007.

Pour le côté historique, son créateur Blaine Cook l’a inventé lors de l’implémentation d’OpenID avec Twitter 🙂

 

OAuth permet donc aux utilisateurs de donner à une applications l’accès à des informations personnelles sur un site fournisseur. Aujourd’hui OAuth est utilisé par Twitter, Gmail, Foursquare, Facebook & bientôt windows live (avec le protocol OAuth 2.0)

Pour SharePoint, OAuth est utilisé pour accéder au token, il n’est pas utilisé pour s’authentifier ! Donc vous ne verrez pas OAuth en tant que provider dans la Central Admin ou dans le people picker.

Un utilisateur aura alors la possibilité d’autoriser une application d’accéder à ces informations sans avoir à fournir son login / password.

 

Mwai .. pas clair ? alors voici en pratique à quoi cela ressemblerai :

  1. Un utilisateur s’authentifie sur SP15
  2. L’utilisateur authentifié utilise le marketplace, ou le catalogue d’application d’enterprise
    1. L’application est autorisée à s’installer par un utilisateur (pas nécessairement celui authentifié) pour accéder à une liste SharePoint.
    2. L’application renvoie un iFrame qui poste des informations sur le context courrant d’utilisation.
    3. Cette application fait un call back sur SharePoint et accède aux ressources SharePoint à la place de l’utilisateur.
    4. Au moment du call back, le token de l’utilisateur en cours et celui de l’application sont envoyées, SharePoint valide les deux token pour accéder au contenu.

 

 

Il y a un jeu de rôles utilisé par OAuth qui mappe SharePoint pour les éléments suivant :

–          Application externe sur le rôle du client

–          L’utilisateur SharePoint prend le rôle du propriétaire de la ressource

–          SharePoint prend le rôle du serveur de la ressource.

–          SharePoint prends les rôles des autorisations du serveur (On Premise)

–          Pour O365 ce sont les ACS.

Un autre scénario pour l’utilisation de l’OAuth est l’utilisation d’une application Server to Server (S2S) comme par exemple Exchange, Lync

 

Dans ce type de scénario, S2S dépends du mapping avec le compte utilisateur à travers l’identity resolver interface, par défaut nous utilisons UPA (UserProfileApp). Il est donc important d’avoir les attributs UPN, SMTP, ou encore SIP à jour dans le user profile store (Synchro UPA / AD). SharePoint construira un token pour l’utilisateur qui en a besoin lors de la réponse à une requête S2S.

Ex. : une requête exchange depuis SharePoint (S2S entrant, ou encore un job SharePoint qui demande des informations à Exchange (S2S sortant)

 

Comment utiliser une plateforme S2S

 

Activer des applications S2S donne la possibilité de s’intéresser à des fonctions intéressantes comme par exemple :

  • eDiscovery : Il est possible de sélectionner une combinaison de contenu SharePoint et de boite aux lettres Exchange pour y inclure de la rétention d’information. S2S autorise SharePoint et Exchange à indexer des données des mailbox.
  • TaskManagement : Vous pouvez créer des tâches Outlook et les faire apparaître dans SharePoint sur un TeamSite. Les tâches sont éditables dans SharePoint, et sont alors synchronisées avec Outlook.
  • TeamMailbox : elles existent déjà dans Exchange, et sont partagées dans SharePoint.
  • Multi tenant Workflow : ces flux sont initiés dans SharePoint et exécutés dans le service Multi Tenant Workflow qui autorisera celui-ci à accéder à des ressources SharePoint.

 

Enjoy & Have fun !