Manuel d'administration > Installation > Nouvelle installation > Configuration du SSO

Configuration du SSO

Le document ci-dessous contient des instructions détaillées sur la manière de configurer l'authentification unique (Single Sign-on = SSO) pour le système Automation Engine. L'authentification unique permet de se connecter sans avoir à saisir les informations de connexion.

C'est le protocole d'authentification Kerberos (centre de distribution de clé) qui est utilisé pour l'authentification unique. Si l'authentification unique est correctement configurée, il est possible de se connecter (interface utilisateur, Enterprise Control Center) au système Automation Engine, sans avoir à saisir les détails de connexion (utilisateur, département et mot de passe). L'utilisateur du système d'exploitation à partir duquel l'interface utilisateur a été lancée sera utilisé pour l'authentification.

Ces instructions d'installation s'appliquent à Windows et UNIX.

Conditions générales

JWP :
Il doit y avoir au moins un processus JWP (processus de travail basé Java) actif.
Différences de temps
La différence entre le temps ordinateur client (interface utilisateur, API Java API) et celui de l'ordinateur serveur (JWP) ne doit pas être trop importante. Une différence de 5 à 10 minutes est autorisée, selon la configuration. Si cette différence est trop importante, le message d'erreur "Différence de temps trop importante" apparaît à la connexion.
Accès à KDC
L'interface utilisateur et JWP doivent pouvoir accéder à KDC (ex. : Active Directory dans Windows). Par exemple, l'accès de l'interface utilisateur au CP n'est pas suffisant.
JVM pris en charge
Actuellement, seul Oracle Java est pris en charge pour l'authentification unique. Si un composant (JWP, interface utilisateur, API Java) est exécuté en Java IBM, la connexion échouera.

Procédure d'installation pour l'interface utilisateur

	1)	Clé de registre pour l'accès TGT

Cette étape ne doit être réalisée que lorsque l'interface utilisateur est exécutée sous Windows.

Cette clé de registre est nécessaire pour que l'implémentation Kerberos Java puisse utiliser un TGT (Ticket Granting Ticket) existant. Le TGT est généré lors de la connexion au système d'exploitation.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"allowtgtsessionkey"=dword:00000001

	2)	Installation des fichiers de règles JCE (Java Cryptography Extension) à niveau illimité

JCE Unlimited Strength Jurisdiction Policy doit être installé sur la machine où :

L'UserInterface et/ou ECC est exécuté.
Automation Engine (JWP) est exécuté.

Téléchargez sous Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy

Le fichier Readme contient les instructions d'installation. En présence de plusieurs installations Java sur le même ordinateur, il est conseillé de configurer un fichier de règle pour toutes les installations.

	3)	Fichier de configuration Kerberos

Vous pouvez ignorer cette étape si l'interface utilisateur est exécutée sous Windows avec Java Version 1.7. Avec Java 1.7, les paramètres seront immédiatement identifiés dans Windows.

Dans tous les autres cas, il faut créer le fichier krb5.conf. L'emplacement du fichier de configuration est <java-home>/lib/security.

La séquence exacte de recherche est décrite sous http://download.java.net/jdk8/docs/technotes/guides/security/jgss/tutorials/KerberosReq.html à la section "Locating the krb5.conf Configuration File" (Emplacement du fichier de configuration krb5.conf). La documentation Kerberos explique comment configurer ce fichier.

Exemple :

[libdefaults]
default_realm = DOMAIN.SAMPLE
[domain_realm]
.domain.sample = DOMAIN.SAMPLE

[realms]
DOMAIN.SAMPLE = {
kdc = servername.domain.sample
admin_server = servername.domain.sample
}

	4)	Active KDC dans les réglages globaux du système AE

Dans le fichier UC_SYSTEM_SETTINGS, réglez KDC à Y pour activer l'authentification de Kerberos Distribution Center (KDC) pour un système complet.

Procédure d'installation pour le processus JWP

Génération du fichier keytab

L'administrateur KDC doit suivre la procédure ci-après (pour chaque hôte CP) :

	1)	Créer un utilisateur de service dans KDC

Créer un nouvel utilisateur de service dans KDC (ex. : dans Active Directory sous Windows) pour l'authentification. Le mot de passe de l'utilisateur ne doit pas expirer.

	2)	Création de SPN (Service Principal Name)

Des SPN (Service Principal Names) doivent ensuite être créés avec la description suivante :
<AE System Name>/<CP Host Name>[@<Realm>]
<AE System Name>/<Fully qualified Domain Name of the CP Host>[@<Realm>]

Automic conseil de créer des SPN pour chaque hôte CP (un SPN avec un nom d'hôte et un avec le nom de domaine entièrement renseigné).

Lors de la création de SPN, veillez à respecter la casse. Sinon le nom sera introuvable dans la base de données Kerberos.

Le domaine est facultatif. S'il n'est pas spécifié, c'est la valeur par défaut du fichier de configuration krb5.conf qui sera utilisée. Dans Windows, <Realm> correspond toujours au nom de domaine (suffixe DNS) en majuscules (ex. : DOMAIN.SAMPLE)

Voir aussi : Description détaillée des entités Kerberos.

Exemple :
AEServer01/winhost01.domain.sample@DOMAIN.SAMPLE

Les SPN doivent être attribués à l'utilisateur de service KDC préalablement créé.

Dans Active Directory de Microsoft, c'est la commande "setspn" qui est utilisée pour créer des SPN. Comme susmentionné, il est conseillé de créer une entrée pour le nom d'hôte et une pour le nom de domaine entier.
Exemple :

setspn -s AEServer01/winhost01.sample.host@SAMPLE.DOMAIN ServiceAccount01
setspn -s AEServer01/winhost01@DOMAIN.SAMPLE ServiceAccount01

	3)	Génération du fichier keytab

Cette étape consiste à générer un fichier keytab.

Dans Microsoft Active Directory, la commande "ktpass" qui est utilisée pour cela. Spécifier le SPN, l'utilisateur KDC, le mot de passe de l'utilisateur KDC et le nom du chemin / fichier du fichier keytab.

Exemple :

ktpass /princ AEServer01/winhost01.domain.sample@DOMAIN.SAMPLE /mapuser ServiceAccount01@DOMAIN.SAMPLE /pass UXTY5rdx+!1245.qw /mapop set /crypto all /out c:\temp\ae.keytab -ptype krb5_nt_principal

Le fichier keytab C:\temp\ae.keytab sera ensuite créé.

Détails de la syntaxe de commande "ktpass" : http://technet.microsoft.com/en-us/library/cc753771.aspx

si vous recevez un message d'erreur lors de la tentative de génération du fichier .keytab, utilisez l'alternative suivante avec l'exemple ci-dessus :

-ptype KRB5_NT_PRINCIPAL

C'est probablement une erreur de mappage du SPN avec une entité. KRB5_NT_PRINCIPAL est le type d'entité général (recommandé) selon Microsoft.

Plusieurs CP sur différents hôtes

Si les processus de communication du système Automation Engine sont exécutés sur des hôtes différents, la procédure de génération du fichier keytab (étapes 2 et 3) doit être répétée pour chaque nom d'hôte.

Cela génèrera des fichiers keytab supplémentaires. Cependant, le JWP n'ayant besoin que d'un seul fichier (exclusivement), les entrées devront être fusionnées en un seul fichier. Pour cela, utilisez l'application "ktab" avec le paramètre –m (merge/fusionner).

ktab -m <keytab-source file> <keytab-target file>

	4)	Spécification du fichier keytab

Vous devez maintenant saisir le nom du fichier keytab généré dans l'objet Variable UC_KDC_SETTINGS du client 0.

Spécifiez la valeur "KEYTAB" dans la colonne Clé de l'objet Variable et le fichier keytab, dans la colonne "Valeur 1".

Après la modification d'une variable, le JWP doit redémarrer.

En présence de plusieurs JWP sur différents hôtes, le fichier keytab doit se trouver dans le même répertoire pour tous les hôtes. En l'absence de ce fichier sur un ou plusieurs hôtes, la connexion ne fonctionnera pas toujours.

	5)	Configuration SSO pour les applications Web

Afin d'implémenter le SSO pour les applications Web (ex. : Enterprise Control Center ou Automic Release Automation), il faut un fichier keytab avec HTTP en tant que SPN.

Exemple :
HTTP/winhost01.domain.sample

Dans cet exemple, winhost01 est l'hôte sur lequel, par exemple, Enterprise Control Center (Tomcat) est installé.

Le nom SPN doit également être saisi dans la variable UC_KDC_SETTINGS via la clé "HTTP". En présence de plusieurs installations ECC / ARA pour un système Automation Engine, vous pouvez ajouter les autres noms, séparés par un point-virgule.

Exemple :
HTTP/winhost01.domain.sample;HTTP/winhost02.domain.sample

Utilisateurs pour l'authentification

Une fois la configuration terminée avec succès, il faut créer les utilisateurs correspondants dans les clients du système Automation Engine.

Le nom des utilisateurs doit correspondre à celui des utilisateurs du système d'exploitation pour lesquels l'accès via SSO est autorisé.

Le département n'a aucune importance, tant que le nom de l'utilisateur est unique pour chaque client. En présence de plusieurs utilisateurs ayant le même nom, mais un département différent, il faut attribuer chacun de ces départements à un domaine dans la variable UC_KDC_SETTINGS.

La connexion SSO échouera si aucun objet User dans le client sélectionné n'a le même nom que l'utilisateur du système d'exploitation (celui utilisé pour lancer l'interface utilisateur).

Exemple :

L'interface utilisateur est lancée dans Windows sous l'utilisateur "test\local".
AE system TEST, client : 100

Si aucun objet User avec le nom "TEST\*" (sans tenir compte du département) n'existe dans client 100, la connexion SSO ne sera pas possible.

Si plusieurs utilisateurs du client 100 ont le nom "TEST\*" (ex. : "TEST\DEV" et "TEST|LOCAL"), les départements (cf. ci-dessus) doivent être attribués aux domaines des utilisateurs du système d'exploitation. Si les départements ne sont pas attribués, la connexion échouera également.