Vous utilisez de multiples comptes au sein de votre entreprise avec par exemple, un pour vous connecter à votre Windows, l’autre pour vous connecter à SAP, un troisième pour vous connecter à une application Oracle ou que sais-je encore? Dans ce cas, le Signle Sign On est une fonctionnalité très utile pour vous et surtout pour vos utilisateurs.

Effectivement, à l’aide de cette fonctionnalité, vous pouvez vous loguer une fois (lorsque vous entrez sur votre Windows) et, si vous avez déjà fourni l’association login / mot de passe pour les autres applications, vous connecter automatiquement à ces autres applications ou système d’informations. Rassurez-vous, le stockage de ces informations est fait de manière cryptée à l’aide d’une clé de cryptage. Nous y reviendrons plus loin dans cet article.

Dans ces quelques lignes, nous allons voir comment l’activer au sein de SharePoint.

Single-Sign-On dans la console d’administration

Rendez-vous sur la page de gestion des Opérations. Le lien concernant SSO se trouve dans la configuration de la sécurité.

*

Après avoir cliqué sur ce lien, vous devriez obtenir la page suivante:

Les liens disponibles diffèrent selon les droits de l’utilisateur connecté.

Il se peut également que vous receviez le message suivant: Failed to connect to Microsoft Single Sign-on Service. To configure, please ensure the service is running comme on le retrouve sur la capture suivante:

Dans ce cas, cela sous-entend que le service SSO n’est pas en cours d’exécution. Il faut dès lors l’activer. Si vous n’avez pas ce message, vous êtes évidemment libre de bypasser cette étape mais il est cependant conseillé de vérifier le paramétrage du service.

Activer le service SSO

Rendez-vous dans la fenêtre d’administration des services (services.msc) et cherchez le service Microsoft Single Sign-On. Très certainement celui-ci est-il stoppé.

Si vous activez le SSO, il est fort probable que vous l’utilisiez dans le futur de manière régulière. De ce fait, il est préférable de mettre le service en démarrage automatique.

Par ailleurs, dans l’onglet Log On, indiquez le compte qui exécutera ce service. Celui-ci doit faire partie des administrateurs de votre SharePoint afin de pouvoir créer la base de données qui contiendra le mapping Windows User Account / Application User Account.

Modifier les paramètres de SSO

Un clic sur le premier lien permet de configurer le Single Sign-On.

Single Sign-On-Administrator: peut créer, modifier ou supprimer des définitions d’applications.

Enterprise Application Definition Administrator: peut gérer les credentials d’une définition d’application.

Comme nous l’avions signalé précédemment, il est nécessaire de créer une base de données qui contiendra les différents comptes utilisateurs. C’est dans cet écran que nous pouvons (et même devons) créer la dite base de données. Enfin, il est possible de modifier les paramètres par défaut concernant la durée de vie du ticket SSO et des audits au sein de la base de données.

Rapidement, nous pouvons voir qu’une nouvelle base de données à été créée dans SQL Server:

Cette base ne contient que quelques tables mais c’est bien suffisant pour répondre aux objectifs de SSO. Il vous est loisible de vous balader au sein de cette base afin de bien comprendre comment fonctionne cette base. On notera rapidement que les informations concernant les comptes utilisateurs ne sont pas lisibles tel quel. Cela a dû à un concept déjà cité: la clé d’encryption. 

Gérer la clé d’encryption

Une clé d’encryption est conceptuellement très simple à maitriser. Il s’agit d’une chaîne de caractères qui est utilisée pour crypter / décrypter les données dans la base de données.

Ainsi, sur le lien Manage Encryption Key, il est possible de générer une nouvelle clé d’encryption. La création d’une nouvelle clé est conseillée de manière périodique ou encore lors d’un soupçon de données altérées. 

Bien que ce ne soit qu’une option, il est fortement recommandé de réencrypter les données stockées dans la base de données lors de la création d’une nouvelle clé sans quoi les utilisateurs devront réencoder leurs credentials.

Enfin, une fois que celle-ci a été générée, il est conseillé de sauvegarder cette clé. On notera tout de même que l’on nous ne propose que de faire des backups sur le drive A…

Définir des applications d’entreprise

Il ne reste dès lors plus qu’à créer des définitions d’applications d’entreprise (entendez par là SAP, Oracle, …) pour lesquelles vous souhaitez stocker des credentials.

Ainsi, définir une application est une étape aisée puisqu’il suffit d’indiquer le nom de l’application (nom que vous souhaitez) et les propriétés qui doivent être persistées.

Ensuite, vous pouvez ajouter, modifier ou supprimer des comptes pour une certaine application.

Notez que pour les comptes qui n’auront pas encore été spécifiées, il est possible directement à l’utilisateur d’encoder son login et son mot de passe au travers de la page http://{server}/_layouts/ssologon.aspx.

Sans entrer dans les détails, il vous est possible d’utiliser un autre provider SSO que celui fournit au travers de cette interface. Il vous est ainsi loisible d’utiliser un autre provider SSO ce qui est très utile si vous utilisez déjà un service SSO.

Enfin, bien que ce code ne soit pas exhaustif, voici une piste de code si vous souhaitez manipuler des informations SSO:

ISsoProvider provider = SsoProviderFactory.GetSsoProvider();

SsoCredentials crentials = provider.GetCredentials(“Mon_Application”);

Ces deux simples lignes de code vous permettrons de récupérer les informations login / mot de passe enregistrées pour l’utilisateur courant pour l’application définie en tant que Mon_Application.

Plus d’infos sur ces méthodes:

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.portal.singlesignon.ssoproviderfactory.getssoprovider.aspx et http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.portal.singlesignon.issoprovider.getcredentials.aspx