Le SSO Adélia permet l'authentification directe dans le middleware d'un utilisateur Windows connecté à un domaine, via une authentification Kerberos sur l'Active Directory.
Le SSO Adélia fournit les fonctionnalités suivantes :
- Connexion transparente d'un client Windows à un serveur Middleware Windows, AS/400 ou Java en utilisant les identifiants de l'utilisateur Windows (sans configuration de profil/mot de passe côté Middleware).
- Connexion transparente via un navigateur Web supportant le SSO (SPNEGO) à une application Adélia Cloud, avec délégation des identifiants si possible au Middleware Adélia.
- Avec le démon Windows, il est possible de démarrer les processus MWSERVER.EXE sous l'identifiant du profil client.
Le Middleware supporte également un mode mixte pour les connexions (certaines connexions pouvant se faire sans mot de passe, d'autres en fournissant explicitement des identifiants).
Le client et le serveur doivent être en version 14 PTF05 minimum, et le démon doit être configuré pour autoriser l'authentification unique (configuration du fichier MWSERVER.INI ou de la DTAARA MWAUTH).
Le fichier de configuration client doit référencer le pseudo-profil *SSO dans la configuration cliente des serveurs physiques pour initier une authentification unique (configuration du fichier MWCLIENT.INI).
Configuration d'Active Directory pour le démon Adélia
Le principe de fonctionnement est de créer au niveau du domaine un utilisateur dédié pour l'exécution des services Middleware sur le domaine Windows. Les services Middleware doivent être démarrés avec ce profil (dans l'exemple : mwdaemon@domain.com).
Il faut associer à cet utilisateur le ou les principaux Kerberos associés au démon Adélia. Par défaut, le middleware Adélia s'identifie avec le principal de service MWDAEMON/host.domain.com, où host.domain.com est le nom qualifié de la machine sur laquelle le service est exécuté.
Par exemple, les commandes suivantes permettent de créer l'utilisateur "mwdaemon", de lui associer le SPN, et de créer le fichier de clé pour le démon Java (krb5.keytab) :
|
Configuration d'un serveur AS/400
Le serveur AS/400 doit être configuré pour activer le Single Sign-on (configuration de Enterprise Identity Manager). La configuration du serveur AS/400 dépasse le périmètre de ce document.
Pour plus d'informations, consultez la documentation IBM. ↑ Haut de page
Configuration du démon Middleware AS/400
La DTAARA MWAUTH permet d'indiquer, si elle est présente, les paramètres d'authentification. Si elle n'est pas présente, le démon démarre en mode classique (authentification par utilisateur/mot de passe).
Configuration du démon Middleware Windows
Le démon Windows utilise par défaut le SPN MWDAEMON/host.domain.com, où host.domain.com est le nom qualifié de la machine sur laquelle le service est exécuté. Il est possible de spécifier le SPN à utiliser par la ligne de commandes et le paramètre "-principal SPN" du démon.
Le paramètre "-asuser" du démon permet d'activer le lancement des processus MWSERVER avec les droits de l'utilisateur client. L'utilisateur doit avoir le droit d'ouvrir une session sur le serveur.
Configuration du démon Middleware Java
Le démon Windows utilise par défaut le SPN MWDAEMON/host.domain.com, où host.domain.com est le nom qualifié de la machine sur laquelle le service est exécuté. Il est possible de spécifier le SPN à utiliser par la ligne de commandes et la propriété "com.hardis.adelia.security.kerberos.principal" (paramètre "-Dcom.hardis.adelia.security.kerberos.principal=SPN" de la commande Java lançant le démon.
Le démon Java utilise la keytab pour authentifier le serveur. Le fichier "krb5.keytab" doit être présent dans le répertoire privé de l'utilisateur démarrant le démon. Il est possible d'utiliser un autre fichier, mais cela nécessite de rajouter un fichier de configuration (jaas.conf).
Il est possible soit de récupérer le fichier généré sur le serveur AD par la commande KTPASS, soit de créer la clé par la commande java "ktab". Vous devrez spécifier le mot de passe de l'utilisateur associé au SPN.
Par exemple :
|
Sous Windows, si le serveur fait partie d'un domaine, il n'est pas nécessaire de fournir de fichier "krb5.ini" ou "jaas.conf". Le paramétrage par défaut de la JVM authentifie les utilisateurs sur le domaine Windows. ↑ Haut de page
Configuration d'une application Adélia Cloud
L'extension de sécurité Java EE supporte le module Kerberos de Pac4J pour implémenter l'authentification via SPNEGO. Le navigateur du poste client doit être configuré pour activer SPNEGO pour l'application.
Pour que le SSO soit complet (l'utilisateur connecté au système se connecte à l'application Adélia Cloud et l'application Adélia Cloud se connecte au Middleware sans présenter de mot de passe), le navigateur doit être configuré pour autoriser la délégation des identifiants Kerberos. Cela permet à l'application Web de récupérer un "granting ticket" Kerberos et de présenter de façon transparente des identifiants au serveur Middleware.
Configuration d'Internet Explorer et de Microsoft Edge
Vous devez rajouter le site dans la liste des sites de confiance de la zone de sécurité "Intranet Local". Pour cela, ouvrez le panneau de configuration "Options Internet", sélectionnez l'onglet "Sécurité" et la zone "Intranet local", puis cliquez sur "Sites".
Indiquez votre serveur, puis cliquez sur le bouton "Ajouter".
Vous devez également activer l'authentification Windows intégrée dans le panneau "Avancé", section "Sécurité".
Configuration du navigateur Chrome
Chrome permet de configurer SPNEGO via deux valeurs dans la clé de registre "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome" :
AuthServerWhitelist | Cette clé permet d'indiquer les serveurs sur lesquels l'authentification est activée. Il s'agit d'une liste de noms d'hôte séparés par des virgules, avec des caractères génériques. Par exemple : |
AuthNegotiateDelegateWhitelist | Cette clé indique les serveurs devant supporter la délégation des identifiants (SSO Middleware). Par exemple : *.domain.com |
Si ces clés ne sont pas configurées, Chrome peut également suivre les options de la configuration réseau d'internet explorer (sites intranet local).
>> https://www.chromium.org/developers/design-documents/http-authentication
N.B : Chrome suit les paramètres d'Internet Explorer si ceux-ci sont configurés. Toutefois, dans ce cas, la délégation ne semble pas fonctionner.
Configuration de Firefox
Firefox se configure via le panneau "about:config" :
network.negotiate-auth.trusted-uris | Cette clé permet d'indiquer les serveurs sur lesquels l'authentification est activée. Il s'agit d'une liste de suffixes de noms d'hôte séparés par des virgules, avec des caractères génériques. Par exemple : .domain.com |
network.negotiate-auth.delegation-uris | Cette clé indique les serveurs devant supporter la délégation des identifiants (SSO Middleware). Par exemple : .domain.com |
Configuration d'Active Directory pour le serveur d'application JEE
Vous devez créer un profil et un SPN pour le serveur HTTP.
Par convention un serveur HTTP s'identifie avec le principal de service HTTP/host.domain.com où host.domain.com est le nom qualifié de la machine sur laquelle le service est exécuté.
Par exemple, les commandes suivantes permettent de créer l'utilisateur "tomcat", de lui associer le SPN, et de créer le fichier de clé (keytab) pour le serveur Web (domaine DOMAIN.COM) :
DSADD user "cn=tomcat,cn=users,dc=DOMAIN,dc=COM" -pwd password -display KTPASS -MAPUSER tomcat -PRINC HTTP/host.domain.com@DOMAIN.COM -PASS password -mapop set -ptype KRB5_NT_PRINCIPAL -out krb5.keytab |
Attention, si vous souhaitez un SSO au niveau Middleware, le profil démarrant le service TOMCAT doit également autoriser la délégation des identifiants :
Configuration du SSO dans l'application Web
Pour activer le SSO, vous devez utiliser le module Kerberos de l'extension de sécurité Java EE.
Configuration du serveur d'applications JEE
Aucune configuration spécifique n'est nécessaire au niveau du serveur d'applications.
Lorsque l'application Adélia Cloud est déchargée ou rechargée, si les sessions web sont persistantes, les identifiants Kerberos ne sont pas sauvegardés. Dans le cas du SSO Adélia, cela implique que le SSO Middleware ne fonctionnera plus.
Contournement : forcer la création d'une nouvelle session JEE en ouvrant une nouvelle instance du navigateur.
Il est conseillé de désactiver la persistance des sessions au niveau du serveur Web car elle n'a pas de sens pour une application Adélia Cloud. Pour TOMCAT, cela se fait en ajoutant la directive <Manager pathname="" /> dans le contexte de l'application.