Authentification unique (SSO) sous Windows

4D Server vous permet d'implémenter des solutions d'authentification unique (Single Sign On ou SSO) dans vos applications client-serveur sous Windows.

Grâce au SSO, vous pouvez mettre en place des solutions permettant aux utilisateurs sous Windows d'accéder directement aux applications 4D Server, sans avoir à saisir leurs identifiants, lorsqu'ils sont déjà connectés au domaine Windows de leur entreprise (via Active Directory). En coulisses, l'application 4D Server délègue l'authentification à Active Directory et récupère l'identifiant de session Windows, que vous pouvez utiliser pour identifier l'utilisateur 4D dans votre base à l'aide de votre méthode standard de connexion.

Note : Consultez le document 4D Security guide pour une vue d'ensemble des fonctions de sécurité de 4D.

L'authentification unique est disponible :

• avec les applications 4D Server sous Windows (les applications 4D monopostes ne prennent pas en charge le SSO)
• lorsque la couche réseau ServerNet est activée. Pour plus d'informations, reportez-vous au paragraphe Nouvelle couche réseau ServerNet (compatibilité).

Par défaut, les fonctions SSO ne sont pas activées dans 4D Server. Pour pouvoir en bénéficier, vous devez cocher l'option Authentification de l'utilisateur auprès du serveur de domaine dans la page Client-Serveur/Options réseau de la boîte de dialogue des Propriétés de la base de 4D Server :

Lorsque vous cochez cette option, 4D se connecte de manière transparente à l'Active Directory du serveur de domaine de Windows et récupère les tokens d'authentification disponibles. 

Cette option permet d'effectuer une authentification standard via le protocole NTLM. 4D prend en charge les protocoles NTLM et Kerberos. Le protocole utilisé est déterminé automatiquement par 4D en fonction de la configuration courante (cf. Configuration requise pour le SSO). Si vous souhaitez utiliser le protocole Kerberos, vous devez en outre remplir le champ Nom principal de service (SPN, voir ci-dessous). 

Si vous souhaitez utiliser le protocole d'authentification Kerberos, vous devez également remplir le champ Nom Principal de Service (SPN) dans la page Client-Serveur/Options réseau de la boîte de dialogue des Propriétés de la base :

Cette option déclare le SPN tel que définit dans la configuration de l'Active Directory. Un nom principal de service est un identifiant unique d'une instance de service. Des SPN sont utilisés par l'authentification Kerberos pour associer une instance de service à un compte d'ouverture de session. Cela permet à une application cliente de demander que le service authentifie un compte même si le client n'a pas accès au nom du compte. Pour plus d'informations, veuillez vous reporter à la page SPN sur le site msdn.

L'identifiant SPN doit respecter le format suivant :

• "ServiceName/FQDN_user" si le SPN est un attribut de machine
• "ServiceName/FQDN_computer" si le SPN est un attribut d'utilisateur

dans lequel :

• ServiceName est le nom du service auquel le client souhaite demander l'authentification.
• Le Fully Qualified Domain Name (FQDN) est le nom du domaine qui définit son emplacement exact dans l'arbre hiérarchique de l'Active Directory pour les machines et les utilisateurs.

Dans les bases de données 4D, le SPN peut être définit à deux emplacements :

• dans les Propriétés de la base (ou les Propriétés structure), pour une utilisation par 4D Server,
• ou dans les Propriétés utilisateurs (fichier settings.4DSettings stocké dans le dossier des Préférences de la base) pour gérer le déploiement d'applications.

Une fois que la fonctionnalité SSO est activée (voir ci-dessus), vous pouvez vous appuyer sur l'authentification de l'utilisateur de la session Windows pour ouvrir une session utilisateur sur 4D Server.

Il est important de comprendre que la fonctionnalité SSO vous founit uniquement un nom d'utilisateur authentifié (login), que vous devez ensuite passer à votre méthode de connexion 4D standard. Lorsqu'une application 4D distante tente de se connecter au serveur, vous devez appeler la commande 4D Authentification client courant, qui retournera le nom d'utilisateur tel que défini dans l'Active Directory. Vous pouvez alors passer ce nom à votre propre système d'identification (utilisant le système intégré d'utilisateurs et groupes, les commandes LDAP ou tout mécanisme personnalisé) afin d'ouvrir dans votre application 4D une session utilisateur avec les droits correspondants. 

Ces principes sont décrits dans le schéma suivant :

La commande Authentification client courant doit être exécutée dans la méthode base Sur ouverture connexion serveur, qui est appelée à chaque fois qu'un 4D distant tente d'ouvrir une nouvelle connexion dans à la base 4D Server. Si l'authentification échoue, vous devez retourner une valeur non nulle dans $0 afin de rejeter la connexion.

La commande Authentification client courant admet la syntaxe suivante :

où :

• login est l'identifiant (nom d'utilisateur) utilisé par le client pour se connecter à l'Active Directory (texte). Cette valeur vous sera nécessaire pour identifier l'utilisateur dans votre base.
  Si l'utilisateur n'a pas pu être identifié, aucune erreur n'est générée, seule une chaîne vide est retournée.
• domaine et protocole sont des paramètres texte optionnels. Ils sont remplis par la commande et peuvent vous permettre d'accepter ou de rejeter les connexions en fonction de certains critères :
  
  • domaine retourne le nom de domaine de l'Active Directory
  • protocole retourne le nom du protocole utilisé par Windows pour authentifier l'utilisateur.

Pour plus d'informations, veuillez vous reporter à la description de la commande Authentification client courant.

L'authentification unique est prise en charge par 4D Server dans différents contextes. Lorsque les conditions requises sont respectées (cf. ci-dessous), le protocole utilisé pour l'authentification (NTLM ou Kerberos) ainsi que les informations retournées par la commande Authentification client courant dépendent de la configuration du système. Le protocole utilisé pour l'authentification est retourné dans le paramètre protocole de la commande Authentification client courant.

Le tableau suivant liste les conditions nécessaires pour l'authentification NTLM ou Kerberos :

(*) La configuration spécifique suivante est prise en charge : l'utilisateur 4D distant est un compte local sur une machine qui appartient au même AD que 4D Server. Dans ce cas, le paramètre domaine contient le nom de la machine de 4D Server. A noter que cette prise en charge dépend des paramétrages utilisateur : si elle n'est pas possible, des chaînes vides sont retournées par Authentification client courant.

(**) Si toutes les conditions requises pour l'authentification Kerberos sont respectées mais que la commande Authentification client courant retourne "NTLM" dans protocole, cela signifie généralement que vous vous trouvez dans une des situations suivantes :

• la syntaxe SPN n'est pas valide, c'est-à-dire qu'elle ne respecte pas toutes les contraintes imposées par Microsoft,
  
• ou bien, le SPN a des doublons dans l'AD. Ce cas requiert l'intervention de l'administrateur de l'AD.

Note : Une syntaxe valide ne signifie pas que la déclaration SPN elle-même est correcte ; en particulier, si le SPN n'existe pas dans l'AD, Authentification client courant retourne des chaînes vides.