Etendre Windows SSO aux entreprises

L’architecture ENTSSO, qu’illustre la figure 1 est construite autour d’un module qui associe le compte Windows d’un utilisateur à un ou plusieurs comptes non-Windows et à leurs références correspondantes. Ces références sont nécessaires pour que SSO se manifeste quand les utilisateurs accèdent à des applications ou platesformes mainframe ou non-Windows (appelées applications affiliées).
Les associations de références ENTSSO sont stockées en toute sécurité dans une base de données Microsoft SQL Server. Pour les configurer, on dispose de ssoconfig.exe et ssomanage. exe, un ensemble d’utilitaires d’administration par ligne de commande. Côté serveur, on installe les outils d’administration ENTSSO en même temps que le service ENTSSO. Côté client, on utilise ssoclient.msi ou ssoclientinstall.exe pour installer les outils en même temps que le logiciel client ENTSSO. On peut aussi administrer à distance les associations de références et autres paramètres de configuration ENTSSO. Comme ENTSSO n’a pas une GUI d’administration, il faut effectuer toutes les tâches d’administration et de configuration ENTSSO à partir de la ligne de commande, comme le montre la figure 2.

On peut déclencher les consultations des associations de références en utilisant les adaptateurs d’applications incorporés dans BizTalk (pour des consultations initiées par Windows) ou les providers de données incorporés dans HIS (pour des consultations initiées par Windows ou par l’hôte). Le premier scénario est lié à une séquence SSO initié par Windows.
Le second peut être lié à une séquence SSO initiée par Windows ou par l’hôte. SSO initié par Windows signifie que les utilisateurs qui se connectent à un environnement Windows peuvent utiliser SSO pour accéder aux ressources non-Windows. SSO initié par l’hôte signifie que les utilisateurs qui se connectent à un environnement non-Windows (comme une application mainframe) peuvent utiliser SSO pour accéder aux ressources Windows. SSO initié par l’hôte est une fonction unique de HIS. ENTSSO supporte quatre mécanismes d’association de comptes:

• Une association individuelle Windows définit une relation de un à un entre des comptes Windows et non-Windows. Cette association peut être gérée par un utilisateur ou un administrateur.
• Une association de groupe Windows définit une relation de un à plusieurs entre des comptes Windows et non- Windows. Tous les utilisateurs Windows utilisent les mêmes comptes non-Windows pour accéder au système d’arrière plan. Seuls les administrateurs peuvent gérer cette association.
• Une association individuelle hôte est une association spécifique à HIS qui n’existe que pour le SSO initié par l’hôte et qui définit une relation de un à un entre des comptes non-Windows et Windows. Cette association peut être gérée par un utilisateur ou un administrateur.
• Une association de groupe hôte est une association spécifique HIS qui n’existe que pour le SSO initié par l’hôte et qui définit une relation de un à plusieurs entre des comptes non-Windows et Windows. Seuls des administrateurs peuvent gérer cette association.

Pour stocker en sécurité les références héritées dans la base de données SQL Server, ENTSSO utilise une clé de cryptage symétrique de 128 bits, appelée secret maître, pour crypter et décrypter les mots de passe. Le secret maître est stocké sur un serveur de secrets maîtres dédié.
C’est en fait un serveur ENTSSO spécial que plusieurs serveurs ENTSSO peuvent se partager.

Le programme d’installation ENT SSO crée une base de données SSO (SSODB) dans la base de données SQL Server. La SSODB contient 11 tables propres à ENTSSO, y compris la table SSOX_IndividualMapping, qui stocke le nom de domaine Windows, le nom de compte Windows, le nom d’application externe et le nom de compte externe ; et la table SSOX_External Credentials, qui stocke le nom d’application externe, le nom de compte externe et les références externes cryptées.

On utilise la clé maîtresse pour crypter ces références.
Une installation ENTSSO classique est constituée de plusieurs serveurs ENTSSO (un pour chaque serveur d’application qui héberge un adaptateur BizTalk ou un provider de données HIS), un serveur de secrets maîtres ENTSSO et une machine SQL Server qui héberge la base de données ENTSSO. Chaque fois qu’un serveur ENTSSO décrypte ou crypte des données SSO provenant de la base de données ENTSSO, le serveur extrait le secret maître du serveur de secrets maîtres via un RPC (remote procedure call) sécurisé. Pour instaurer la tolérance aux pannes, on peut regrouper dans un cluster la machine SQL Server et le serveur de secrets maîtres ENTS SO.