Public concerné : Opérateur de production

Mise en place des briques de persistentce (configuration, token, identités).
Mise en place d’un cluster de serveurs TOSIAM
Automatisation des taches d’installation.

Prérequis

Installer un java JDK 11, 17 ou 21 (La variable d’environnement JAVA_HOME doit être définie.) pour tout serveur TOSDJ ou TOSIAM
Installer un serveur Apache TOMCAT 9.0.X (Nous noterons <TOMCAT> le répertoire d’installation.) pour le serveur TOSIAM.
Télécharger l’archive TosiAM-2.24.0 .zip et extraire de l’archive les fichiers :
- SSOAdminTools-2.24.0 .zip
- SSOConfiguratorTools-2.24.0 .zip
- TosiAM-2.24.0 .war
Télécharger l’archive tosdj-2.24.0 .zip

Introduction

Une instance d’un serveur TOSIAM interagit avec 3 types de base, comme le montre le schéma ci-dessous. Schéma 1 Dans le cas d’un serveur de Développement, ces 3 bases peuvent n’en former qu’une et fonctionner dans le même processus que TOSIAM (On parle alors de base embedded). Noter que ces 3 bases sont requêtées via une interface LDAP.

Dans la suite du document, nous allons faire un focus sur ces bases, qui présentent des contraintes différentes. Dans une deuxième partie, nous traiterons des instances TOSIAM en tant que cluster.

L’objectif que nous nous fixons dans ce document est de définir une architecture de référence, présentant des contraintes de Haute Disponibilité et pouvant évoluer pour obtenir un système scalable horizontalement. Cette architecture est schématisée ci-dessous. Chaque composant est libellé par un hostname, que nous utiliserons dans les exemples de scripts de configuration.

Installation d’un serveur TOSDJ.

TOSDJ est une base de données mémoire s’appuyant sur un moteur de type clé-valeur, et exposant ses données via une API LDAP. Tosdj est particulièrement adaptée aux différents besoins du produit TOSIAM.

TOSDJ est livré sous la forme d’une archive tosdj-<VERSION>.zip Il s’installe par extraction dans un répertoire vide, que nous nommerons <TOSDJ> dans la suite du document. Les données d’instance associées à TOSDJ doivent dans la mesure du possible se trouver dans un répertoire hors de l’arborescence du répertoire <TOSDJ>. Nous nommerons ce répertoire <INSTANCE>. La liaison entre le binaire TOSDJ (dans <TOSDJ>) et sa base de données (dans <INSTANCE>) est matérialisée par le fichier <TOSDJ>/instance.loc, fichier texte contenant une ligne, le chemin absolu vers <INSTANCE> Dans la suite du document, nou supposons que le répertoire <TOSDJ>/bin/ est inclu dans la variable d’environnement $PATH.

En production, l’installation de TOSDJ utilise la commande setup en ligne de commande. Un fichier silencieux est donc fourni, en voici un exemple:

silentfile.txt

hostname= config1.tosit.org
ldapPort =1389
generateSelfSignedCertificate=false
usePkcs12keyStore=<path_to>/server.p12
keyStorePassword=password
certNickname=server-cert
ldapsPort=1636
jmxPort =1689
adminConnectorPort=4444
rootUserDN =cn=Directory Manager
rootUserPassword=password
baseDN=dc=tosit,dc=org
doNotStart=true

Le serveur écoute sur les ports LDAP 1389 et LDAPS 1636

Le certificat serveur se trouve dans un bundle au format pkcs12, ce qui est aujourd’hui préconisé.

Le port admin (4444) permet d’effectuer des commandes d’administration sur un serveur démarré (via la commande dsconfig par exemple), en utilisant le user admin (cn=Directory Manager)

L’entrée racine de la base est: dc=tosit,dc=org

La commande d’installation ci-dessous va créer l’arborescence de l’instance de base de donnée dans le répertoire <INSTANCE>

setup --cli --propertiesFilePath "<path_to>/silentfile.txt" --acceptLicense --no-prompt

Noter qu’à l’issue du setup, le serveur n’est pas démarré (doNotStart=true)

Création des fichiers LDIF.

<ADMIN>.ldif

Nous allons définir le user tosiam qui sera utilisé par tosiam pour interagir avec la base tosdj. Ce n’est pas strictement nécessaire, il existe déjà le user cn=Directory Manager, mais il est préférable d’utiliser ce dernier uniquement pour les gestes d’administration. TOSIAM utilise un user avec des droits plus limités.

dn: @SM_CONFIG_ROOT_SUFFIX@
objectclass: domain
dc: @domain@
aci: (targetattr="*")(version 3.0;acl "Allow CRUDQ operations";
 allow (search, read, write, add, delete)
 (userdn = "ldap:///uid=tosiam,ou=system,@SM_CONFIG_ROOT_SUFFIX@");)
aci: (targetcontrol="2.16.840.1.113730.3.4.3")(version 3.0;acl "Allow
 persistent search"; allow (search, read)(userdn = "ldap:///uid=tosiam
 ,ou=system,@SM_CONFIG_ROOT_SUFFIX@");)
aci: (targetcontrol="1.2.840.113556.1.4.473")(version 3.0;acl "Allow
 server-side sorting"; allow (read)(userdn = "ldap:///
 uid=tosiam,ou=system,@SM_CONFIG_ROOT_SUFFIX@");)

dn: ou=system,@SM_CONFIG_ROOT_SUFFIX@
objectclass: organizationalUnit
ou: system

dn: uid=tosiam,ou=system,@SM_CONFIG_ROOT_SUFFIX@
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: tosiam
sn: tosiam
uid: tosiam
userPassword: secret12
ds-privilege-name: subentry-write
ds-privilege-name: update-schema
ds-privilege-name: password-reset
ds-privilege-name: unindexed-search
ds-rlim-lookthrough-limit: 0
ds-rlim-size-limit: 5000

Vous devez remplacer les tokens @SM_CONFIG_ROOT_SUFFIX@ et @domain@ par la valeur spécifique à votre environnement (ici domain=tosit) Noter le mot de passe du user tosiam, mis par défaut à secret12, mais que vous devez adapter à votre environnement. On obtient au final un fichier <ADMIN>.ldif

<CONFIG>.ldif

Nous allons procéder au chargement des schémas nécessaires au bon fonctionnement d’une base de configuration. Cette étape n’est pas strictement nécessaire, en ce sens que lors de la première configuration d’un serveur TOSIAM (via le configurator, décrit plus loin), TOSIAM chargera ces définitions si elles n’existent pas. Les fichiers LDIF des schémas sont présents dans l’archive de TOSIAM (TosiAM-<version>.zip!/tosiam/TosiAM-<version>.war). Nous supposons que vous avez dézippé l’archive WAR dans le répertoire <TOSIAM>. Les fichiers LDIF qui nous intéressent se trouvent dans le répertoire <TOSIAM>/WEB-INF/template/ldif

Voici la liste des fichiers pour la base de configuration.

<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_config_schema.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_user_schema.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_userinit.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_user_index.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_dashboard.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_deviceprint.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj_kba.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_uma_audit.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_uma_resource_sets.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_uma_labels_schema.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_uma_resource_set_labels.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_uma_pending_requests.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj_oathdevices.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_pushdevices.ldif
<TOSIAM>/WEB-INF/template/ldif/sfha/cts-add-schema.ldif
<TOSIAM>/WEB-INF/template/ldif/sfha/cts-indices.ldif
<TOSIAM>/WEB-INF/template/ldif/sfha/cts-container.ldif
<TOSIAM>/WEB-INF/template/ldif/fido2/fido2_schema.ldif
<TOSIAM>/WEB-INF/template/ldif/fido2/authenticator-base.ldif

Vous devez prendre le contenu de tous ces fichiers et les concaténer en un seul fichier que nous appellerons <CONFIG>.ldif

Ce fichier contient des tokens à remplacer suivant votre environnement:

@DB_NAME@ (à remplacer par le nom de la base ou backend choisi, souvent on met userRoot)

@userStoreRootSuffix@ (à remplacer par la valeur du baseDn du fichier silentfile.txt plus haut)

@SM_CONFIG_ROOT_SUFFIX@ (à remplacer par la valeur du baseDn du fichier silentfile.txt plus haut)

<CTS>.ldif

Nous allons procéder au chargement des schémas nécessaires au bon fonctionnement d’une base CTS. Les fichiers LDIF des schémas sont présents dans l’archive de TOSIAM (TosiAM-<version>.zip!/tosiam/TosiAM-<version>.war). Nous supposons que vous avez dézippé l’archive WAR dans le répertoire . Les fichiers LDIF qui nous intéressent se trouvent dans le répertoire /WEB-INF/template/ldif

Voici la liste des fichiers pour la base CTS.

<TOSIAM>/WEB-INF/template/ldif/sfha/cts-add-schema.ldif
<TOSIAM>/WEB-INF/template/ldif/sfha/cts-indices.ldif
<TOSIAM>/WEB-INF/template/ldif/sfha/cts-container.ldif

Vous devez prendre le contenu de tous ces fichiers et les concaténer en un seul fichier que nous appellerons <CTS>.ldif

Ce fichier contient des tokens à remplacer suivant votre environnement:

@DB_NAME@ (à remplacer par le nom de la base ou backend choisi, souvent on met userRoot)

@SM_CONFIG_ROOT_SUFFIX@ (à remplacer par la valeur du baseDn du fichier silentfile.txt plus haut)

<USER>.ldif

Nous allons procéder au chargement des schémas nécessaires au bon fonctionnement d’une base d’identité correspondant aux besoins de TOSIAM.

Les fichiers LDIF des schémas sont présents dans l’archive de TOSIAM (TosiAM-<version>.zip!/tosiam/TosiAM-<version>.war). Nous supposons que vous avez dézippé l’archive WAR dans le répertoire <TOSIAM>. Les fichiers LDIF qui nous intéressent se trouvent dans le répertoire <TOSIAM>/WEB-INF/template/ldif

Voici la liste des fichiers pour la base de configuration.

<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_config_schema.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_user_schema.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_userinit.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_user_index.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_dashboard.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_deviceprint.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj_kba.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj_oathdevices.ldif
<TOSIAM>/WEB-INF/template/ldif/opendj/opendj_pushdevices.ldif
<TOSIAM>/WEB-INF/template/ldif/fido2/fido2_schema.ldif
<TOSIAM>/WEB-INF/template/ldif/fido2/authenticator-base.ldif

Vous devez prendre le contenu de tous ces fichiers et les concaténer en un seul fichier que no us appellerons <USER>.ldif

Ce fichier contient des tokens à remplacer suivant votre environnement:

@DB_NAME@ (à remplacer par le nom de la base ou backend choisi, souvent on met userRoot)

@userStoreRootSuffix@ (à remplacer par la valeur du baseDn du fichier silentfile.txt plus haut)

Base de configuration.

On interagit avec la base de configuration via la console d’administration ou l’outil en ligne de commande ssoadm. Un exemple de donnée de configuration est la définition d’un client Oauth: Schéma 2

Les serveurs TOSIAM ont accès à leur configuration via la mise en cache mémoire de l’essentiel des données stockées dans cette base. Chaque serveur s’abonne aux éventuelles modifications de la base, et met en à jour son cache en conséquence. (Mécanisme LDAP Search). Dans la plupart des cas, la topologie de la base de configuration est indépendante du nombre de serveurs TOSIAM qui s’y connectent. Elle est constitué d’une base dite primaire, sur laquelle les serveurs TOSIAM accèdent aux données, et d’une base secondaire agissant comme replica des données de la base primaire. Schéma 3

Préparation de la base primaire

Nous supposerons que vous avez exécuté la commande setup sur 2 Vms ayant les hostnames config1.tosit.org et config2.tosit.org

Occupons nous d’abord du serveur config1.tosit.org

Démarrons le serveur:

start-ds

Munis des 2 fichiers <ADMIN>.ldif et <CONFIG>.ldif, nous allons charger ces fichiers dans le serveur démarré:

ldapmodify --defaultAdd --port "1389" --bindDN "cn=Directory Manager" --bindPassword password --filename <ADMIN>.ldif
ldapmodify --defaultAdd --port "1389" --bindDN "cn=Directory Manager" --bindPassword password --filename <CONFIG>.ldif

Si vous utilisez un client LDAP de type ApacheDirectoryStudio, voici le contenu de la base de configuration en terme d’entrées:(les scripts contiennent surtout des schémas, non visibles ici) Schéma 4

Configuration du replica

Démarrons le serveur sur config2.tosit.org:

start-ds

La base secondaire est pour le moment vide, comme le montre le screenshot ci-dessous Schéma 5

Activons la réplication entre le serveur config1.tosit.org et le serveur config2.tosit.org

dsreplication enable --adminPassword password --baseDN "dc=example,dc=com" \
--host1 "config1.tosit.org" --port1 4444 --bindDN1 "cn=Directory Manager" --bindPassword1 \
password --replicationPort1 8990 --host2 "config2.tosit.org" \
--port2 4444 --bindDN2 "cn=Directory Manager" --bindPassword2 password \
--replicationPort2 8990 --trustAll –no-prompt

La commande est symétrique. La réplication est bi-directionnelle (de config1 vers config2 et de config2 vers config1).

Le mot de passe adminPassword correspond au mot de passe du user “cn=Directory Manager” sur config1

L’activation de la réplication ne démarre pas le mécanisme de synchronisation, comme le montre la commande ci-dessous:

dsreplication status --adminPassword password --no-prompt --trustAll

La commande enable crée sur config1 et sur config2 un serveur de réplication attaché à l’instance locale. La réplication est réalisé par les 2 serveurs de réplication (RS ID=12552 et RS ID=12719) Remarquez la colonne Entries: config1 a 13 entrées et config2 a toujours 0 entrée!

Nous allons démarrer effectivement la réplication via la commande:

dsreplication initialize --adminPassword password --baseDN "dc=example,dc=com" \
--hostSource "config1.tosit.org" --portSource 4444 --hostDestination \
"config2.tosit.org" --portDestination 4444 –trustAll --no-prompt

Cette fois-ci, config1 et config2 sont bien synchronisés. La synchronisation est bi-directionnelle. Une insertion dans config1 entraine une insertion dans config2. Une insertion dans config2 entraine une insertion dans config1.

Base CTS.

Cette base assure la persistence des différents jetons (SAML, Oauth2, …) et des sessions utilisateurs. Cette base est utilisée en lecture/écriture, et peut grossir fortement suivant l’activité utilisateur et la durée de vie des jetons. Il s’agit de la base dite runtime associée à TOSIAM, qui doit disposer d’une topologie spécifique afin de pouvoir supporter un cluster de serveur TOSIAM en front. Afin de pouvoir répondre aux besoins de haute disponibilité et de scalabilité de la solution, les tokens doivent être répartis sur une ferme de serveur TOSDJ, via un mécanisme de sharding. Notez que le sharding n’est pas une fonctionnalité de TOSDJ, mais un mécanisme mis en place à l’intérieur d’un serveur TOSIAM (Nous verrons plus loin la partie configuration dans TOSIAM). La contrainte de haute disponibilité impose l’existence de réplica tout comme la base de configuration.

Dans le schéma ci-dessus, nous avons représenté une ferme de 4 serveurs TOSDJ. Chaque serveur encaisse 25 % de la charge issue du cluster TOSIAM. Chaque serveur agit aussi comme réplica. Au total, chaque serveur stocke 50 % de l’ensemble des tokens. Si N=2^p est le nombre de serveur de token et T le nombre de tokens injectés par le cluster TOSIAM en front, cette topologie implique que chaque serveur stocke T /p tokens.

Préparation de la base CTS.

Nous utiliserons 4 Vms, nommées cts1.tosit.org, cts2.tosit.org,ct3.tosit.org et cts4.tosit.org. On pourrait n’utiliser que 2 Vms. Dans ce cas, il faut veiller à ce que les réplicas ne soient pas sur une même VM. Pour chacun des serveurs, utiliser la commande setup pour créer une instance.

Faisons l’exercice sur cts1.tosit.org Démarrons le serveur:

start-ds

Munis des 2 fichiers <ADMIN>.ldif et <CTS>.ldif, nous allons charger ces fichiers dans le serveur démarré:

ldapmodify --defaultAdd --port "1389" --bindDN "cn=Directory Manager" --bindPassword password --filename <ADMIN>.ldif
ldapmodify --defaultAdd --port "1389" --bindDN "cn=Directory Manager" --bindPassword password --filename <CTS>.ldif

Si vous utilisez un client LDAP de type ApacheDirectoryStudio, voici le contenu de la base CTS en terme d’entrées: (les scripts contiennent surtout des schémas)

Faites de même pour cts2.tosit.org

Configuration des replicas

Démarrons le serveur sur cts3.tosit.org:

start-ds

cts1.tosit.org et cts3.tosit.org doivent être synchronisés. Voici les commandes à exécuter sur cts3.tosit.org par exemple:

dsreplication enable --adminPassword password --baseDN "dc=example,dc=com" \
--host1 "cts1.tosit.org" --port1 4444 --bindDN1 "cn=Directory Manager" --bindPassword1 \
password --replicationPort1 8990 --host2 "cts3.tosit.org" \
--port2 4444 --bindDN2 "cn=Directory Manager" --bindPassword2 password \
--replicationPort2 8990 --trustAll --no-prompt

dsreplication initialize --adminPassword password --baseDN "dc=example,dc=com" \
--hostSource "cts1.tosit.org" --portSource 4444 --hostDestination \
"cts3.tosit.org" --portDestination 4444 --trustAll --no-prompt

Nous laissons à titre d’exercice la configuration du binôme cts2.tosit.org et cts4.tosit.org

Base User

La base des identités est souvent gérée par un produit externe, comme Active Directory ou OpenLDAP. Tosdj est une excellente alternative. Voici comment configurer une base comprenant 2 replicas, sur user1.tosit.org et user2.tosit.org

Préparation de la base USER.

Pour chacun des serveurs, utiliser la commande setup pour créer une instance.

Faisons l’exercice sur user1.tosit.org Démarrons le serveur:

start-ds

Munis des 2 fichiers <ADMIN>.ldif et <USER>.ldif, nous allons charger ces fichiers dans le serveur démarré:

ldapmodify --defaultAdd --port "1389" --bindDN "cn=Directory Manager" --bindPassword password --filename <ADMIN>.ldif
ldapmodify --defaultAdd --port "1389" --bindDN "cn=Directory Manager" --bindPassword password --filename <USER>.ldif

Si vous utilisez un client LDAP de type ApacheDirectoryStudio, voici le contenu de la base USER en terme d’entrées: (les scripts contiennent surtout des schémas) user_base_empty

Nous allons créer 2 utilisateurs, via le fichier <DATA>.ldif suivant:

dn: uid=dduck,ou=people,dc=example,dc=com
ou: people
uid: dduck
cn: Donald DUCK
sn: DUCK
givenName: Donald
mail: aaliyah_smith@tosiam.io
userPassword: password
inetUserStatus: active
objectClass: inetOrgPerson
objectClass: inetuser
objectClass: sunAMAuthAccountLockout

dn: uid=mmouse,ou=people,dc=example,dc=com
ou: people
uid: mmouse
cn: Mickey MOUSE
sn: MOUSE
givenName: Mickey
mail: mmouse@tosiam.io
userPassword: password
inetUserStatus: active
objectClass: inetOrgPerson
objectClass: inetuser
objectClass: sunAMAuthAccountLockout

La commande est:

ldapmodify --defaultAdd --port "1389" --bindDN "cn=Directory Manager" --bindPassword password --filename <DATA>.ldif

Configuration du replica

Activons la réplication sur user2.tosit.org

start-ds
dsreplication enable --adminPassword password --baseDN "dc=example,dc=com" \
--host1 "user1.tosit.org" --port1 4444 --bindDN1 "cn=Directory Manager" --bindPassword1 \
password --replicationPort1 8990 --host2 "user2.tosit.org" \
--port2 4444 --bindDN2 "cn=Directory Manager" --bindPassword2 password \
--replicationPort2 8990 --trustAll --no-prompt

dsreplication initialize --adminPassword password --baseDN "dc=example,dc=com" \
--hostSource "user1.tosit.org" --portSource 4444 --hostDestination \
"user2.tosit.org" --portDestination 4444 --trustAll --no-prompt

Sur user1.tosit.org ou user2.tosit.org, les entrées dans la base sont les suivantes: user_2_ids

Installation d’un serveur TOSIAM.

Nous allons procéder à l’installation de TOSIAM sur les hosts tosiam1.tosit.org et tosiam2.tosit.org. Cette installation est donc à répeter sur chaque host.

Nous nommerons le répertoire d’installation de TOSIAM <CATALINA_HOME> (qui est en fait le répertoire de Tomcat). Le Root Path de l’application sera nommé ici @CONTEXT@, et devra être adapté à votre environnement.

Nous supposons que TOMCAT est arrêté.

Copier le fichier TosiAM-2.24.0 .war dans le répertoire <TOMCAT>/webapps, et renommer l’archive en @CONTEXT@.war Ouvrir une fenêtre console :

export CATALINA_HOME=<TOMCAT>
export CATALINA_OPTS="-Xmx2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m \
-Dcom.sun.identity.configuration.directory=<INSTANCE>"
CATALINA_OPTS="${CATALINA_OPTS} --add-exports java.base/sun.security.provider=ALL-UNNAMED \
--add-exports java.base/sun.security.x509=ALL-UNNAMED \
--add-exports java.base/sun.security.util=ALL-UNNAMED \
--add-exports java.base/sun.security.tools.keytool=ALL-UNNAMED \
--add-exports java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED"
$CATALINA_HOME/bin/catalina.sh start

Notes:

<INSTANCE> désigne le répertoire contenant les données d’instance de TOSIAM. avant première configuration, il doit être vide ou non existant.
Le paramètre com.sun.identity.configuration.directory permet d’indiquer au serveur tomcat le chemin du répertoire d’instance.

Installation de ssoadm et du configurator

Le configurator permet de scripter une première installation.

ssoadm est l’outil en ligne de commande pour configurer une instance TOSIAM. Il permet en particulier d’automatiser toutes les actions réalisées dans la console TOSIAM.

Créer un répertoire que nous noterons <TOOLS>, et dans ce répertoire:

créer un répertoire admin. Dézipper le contenu du fichier SSOAdminTools-2.24.0 .zip dans ce répertoire.
créer un répertoire config. Dézipper le contenu du fichier SSOConfiguratorTools-2.24.0 .zip dans ce répertoire.

Dans le répertoire admin, créer un fichier .pwd.txt contenant le mot de passe du compte amadmin, et lancer le script d’installation :

echo password > .pwd.txt && chmod 400 .pwd.txt
./setup --acceptLicense -p <INSTANCE>

Si tout s’est bien passé, vous devriez avoir quelque chose comme :

La version de ce tools.zip est : TOSIAM 2.24.0

La version de votre instance de serveur est : 13.5.2 Build 73bbeab287 (2023-November-22 11:37)

Première configuration.

Cette procédure est à effectuer sur chaque host. Nous prendrons l’exemple de tosiam1.tosit.org

Dans le répertoire config, créer le fichier de configuration suivant, config.properties :

#SECTION 1
SERVER_URL=http://tosiam1.tosit.org:8080
DEPLOYMENT_URI=@CONTEXT@
BASE_DIR=<INSTANCE>
locale=en_US
PLATFORM_LOCALE=en_US
AM_ENC_KEY=@ENC_KEY@
ADMIN_PWD=@ADMIN_PWD@
AMLDAPUSERPASSWD=password
COOKIE_DOMAIN=@COOKIE_DOMAIN@
ACCEPT_LICENSES=true

#SECTION 2
DATA_STORE=dirServer
DIRECTORY_SSL=SSL
DIRECTORY_SERVER=config1.tosit.org
DIRECTORY_PORT=1636
ROOT_SUFFIX=@ROOT_SUFFIX@
DS_DIRMGRDN=uid=tosiam,ou=system,@ROOT_SUFFIX@
DS_DIRMGRPASSWD=@TOSIAM_DB_PASSWORD@

#SECTION 3
USERSTORE_TYPE=LDAPv3ForOpenDS
USERSTORE_SSL=SSL
USERSTORE_HOST=config1.tosit.org
USERSTORE_PORT=1636
USERSTORE_SUFFIX=@ROOT_SUFFIX@
USERSTORE_MGRDN=uid=tosiam,ou=system,@ROOT_SUFFIX@
USERSTORE_PASSWD=@TOSIAM_DB_PASSWORD@

LB_SITE_NAME=site1
LB_PRIMARY_URL=http://lb1.tosit.org:8888/@CONTEXT@
LB_SESSION_HA_SFO=true

Notes:

@CONTEXT@ est le Root Path évoqué plus haut.
@ENC_KEY@ est une clé de chiffrement pour différents mots de passe stockés dans la base de configuration.
@ADMIN_PWD@ est le mot de passe du compte administrateur amadmin.
Dans la section 2, on renseigne les données de connexion à la base de configuration
Dans la section 3, on renseigne les données de connexion à la base d’ID par défaut, qui se trouve être aussi la base de configuration.
@COOKIE_DOMAIN@ indique le domaine sur lequel les cookies d’affinité de serveur (amlbcookie) et de session (iPlanetDirectoryPro) s’appliquent.
@ROOT_SUFFIX@ spécifie le DN Root de la base (par exemple: dc=example,dc=com)
@TOSIAM_DB_PASSWORD@ est le mot de passe du compte qu’utilise les serveurs TOSIAM pour accéder aux bases.
lb1.tosit.org:8888 désigne le point d’accès au mécanisme de répartition de charge sur le cluster TOSIAM.

Une fois les tokens remplacés par leur valeur, lancer le configurator, à partir du répertoire config

java -jar tosiam-configurator-tool-2.24.0
.jar -f config.properties

Configuration TOSIAM vers User

Nous allons connecter la base des IDs (user1 et user2) au serveur TOSIAM. Pour cela, nous créons un realm, ref.

Placons nous dans le répertoire admin

ssoadm create-realm --realm ref -u amadmin -f .pwd.txt

Un realm est une abstraction permettant de considérer TOSIAM comme un système multi-tenant. Plusieurs projets indépendants peuvent partager la même infrastructure de déploiment.

Créez le fichier users.properties suivant:

sun-idrepo-ldapv3-config-ldap-server=user1.tosit.org:1636|01,user2.tosit.org:1636|03,user1.tosit.org:1636,user2.tosit.org:1636
sun-idrepo-ldapv3-config-authid=uid=tosiam,ou=system,@ROOT_SUFFIX@
sun-idrepo-ldapv3-config-authpw=@TOSIAM_DB_PASSWORD@
sun-idrepo-ldapv3-config-organization_name=@ROOT_SUFFIX@
sun-idrepo-ldapv3-config-people-container-value=people
sun-idrepo-ldapv3-config-psearchbase=
sun-idrepo-ldapv3-config-connection-mode=LDAPS
tosiam-idrepo-ldapv3-sufficient-enabled=true

Notes:

@ROOT_SUFFIX@ spécifie le DN Root de la base des users(par exemple: dc=example,dc=com)
@TOSIAM_DB_PASSWORD@ est le mot de passe du compte qu’utilise les serveurs TOSIAM pour accéder aux bases.

Notez la structure de l’élément sun-idrepo-ldapv3-config-ldap-server. Les serveurs TOSIAM possèdent un identifiant unique:

tosiam1: serverid=01
tosiam2: serverid=03.

Les serveurs user1 et user2 vont fonctionner en mode Actif/Actif.

user1 est associé à tosiam1. Si user1 est indisponible, tosiam1 bascule vers user2.
user2 est associé à tosiam2. Si user2 est indisponible, tosiam2 bascule vers user1.

Nous modifions maintenant la configuration de TOSIAM pour relier les bases user1/user2 au realm ref:

ssoadm create-datastore --name users --realm ref --datatype LDAPv3ForOpenDS --datafile users.properties -u amadmin -f .pwd.txt
ssoadm delete-datastores --names OpenDJ --realm ref -u amadmin -f .pwd.txt

Notez que nous avons supprimé le lien au datastore OpenDJ. Il s’agit du datastore configuré par défaut lorsqu’on crée un nouveau realm. Ce datastore pointe vers la base de configuration (config1/config2). Ceci n’est pas utile ici.

Configuration TOSIAM vers CTS

Contrairement à la base User, la base CTS est commune à tous les realm. Il s’agit donc d’une configuration globale. Créer le fichier cts.properties suivant dans le répertoire admin:

org.forgerock.services.cts.store.directory.name=cts1.tosit.org:1636|cts3.tosit.org:1636,cts3.tosit.org:1636|cts1.tosit.org:1636,cts2.tosit.org:1636|cts4.tosit.org:1636,cts4.tosit.org:1636|cts2.tosit.org:1636
org.forgerock.services.cts.store.heartbeat=10
org.forgerock.services.cts.store.location=external
org.forgerock.services.cts.store.loginid=uid=tosiam,ou=system,@ROOT_SUFFIX@
org.forgerock.services.cts.store.max.connections=10
org.forgerock.services.cts.store.password=@TOSIAM_DB_PASSWORD@
org.forgerock.services.cts.store.root.suffix=ou=famrecords,ou=openam-session,ou=tokens,@ROOT_SUFFIX@
org.forgerock.services.cts.store.ssl.enabled=true
org.forgerock.services.cts.store.affinity.enabled=true

Notes:

@ROOT_SUFFIX@ spécifie le DN Root de la base des users(par exemple: dc=example,dc=com)
@TOSIAM_DB_PASSWORD@ est le mot de passe du compte qu’utilise les serveurs TOSIAM pour accéder aux bases.

La propriété org.forgerock.services.cts.store.affinity.enabled permet d’activer le mode sharding. Chaque instance CTS (il y en a 4) va participer au stockage des tokens de TOSIAM.

La liste des instances est indiquée à TOSIAM dans la propriété org.forgerock.services.cts.store.directory.name Un algorithme implémenté dans TOSIAM gère la répartition des tokens au sein de la ferme CTS. Notez que pour chaque membre de la ferme, il faut indiquer à TOSIAM le replica. De cette façon, si une instance CTS tombe, TOSIAM connait le réplica hebergeant les tokens du CTS défaillant.

Nous modifions maintenant la configuration de TOSIAM pour le relier à la ferme CTS.

ssoadm update-server-cfg -s default --datafile cts.properties -u amadmin -f .pwd.txt

Prise en compte du replica config2.

Le serveur config2 est un réplica de la base de configuration config1. Mais TOSIAM n’a pas la connaissance de la présence d’un réplica. Si config1 est indisponible, et que vous redémarrer une instance tosiam1 ou tosiam2, le serveur TOSIAM ne trouvera pas sa base de configuration, car il ne sait pas qu’il doit contacter le replica.

En fait TOSIAM s’appuie sur le fichier <INSTANCE>/boostrap pour localiser sa ou ses bases de configuration. Au départ, avant prise en compte du replica, ce fichier ressemble à ceci:

ldaps://config1.tosit.org:1636/http%3A%2F%2Ftosiam1.tosit.org%3A8080%2Ftosiam?user=cn%3Ddsameuser%2Cou%3DDSAME+Users%2Cdc%3Dtosit%2Cdc%3Dorg&pwd=AgMDAAAbWKk57EnKVIsresOtv7iCLCieZsJhzMkWLpTYsMVg%2BfOwuRZx7eHjahqj%2BFJBAm%2Bhjw%3D%3D&dsbasedn=dc%3Dtosit%2Cdc%3Dorg&dsmgr=uid%3Dtosiam%2Cou%3Dsystem%2Cdc%3Dtosit%2Cdc%3Dorg&dspwd=AgMDAAAbWA4623eb7NENkxHg3bchzt6nWSLdBagtdaTnaXQ%2FR4F3UbgTuBkP%2BpIZp12f4W1K2w%3D%3D&ver=1.0

Les serveurs TOSIAM peuvent donc se connecter à config1, mais pas à config2.

Voici la procédure à exécuter sur chaque serveur TOSIAM (tosiam1 et tosiam2 ici)

Exécuter le script suivant:

ssoadm get-svrcfg-xml -u amadmin -f /tosiam/instance/.pwd.txt -s http://"${HOSTNAME}":8080/"${CONTEXT}" -o /tmp/toto.xml

Créer dans le répertoire admin le fichier python svrcfgxml.py

import sys
import xml.etree.ElementTree as ET


def main():
    # Define a realm

    xml_path = sys.argv[1]
    host2 = sys.argv[2]
    # ouvrir le fichier XML
    tree = ET.parse(xml_path)

    # accéder à la racine du fichier
    root = tree.getroot()

    # trouver l'élément ServerGroup avec l'attribut name="sms"
    server_group = root.find(".//ServerGroup[@name='sms']")
    children = list(server_group)
    last_server = server_group.findall("Server")[-1]
    index_of_last_server = children.index(last_server)
    server_name = last_server.get("name")
    i = int(server_name.lstrip('Server'))
    index = 0
    for host in sys.argv[2:]:
        index = index+1
        j = i+index
        server = ET.Element('Server')
        server.set('name', f'Server{j}')
        server.set('host', host)
        server.set('port', last_server.get('port'))
        server.set('type', last_server.get('type'))
        server_group.insert(index_of_last_server + index, server)
    tree.write(xml_path, encoding="UTF-8", xml_declaration=True)


if __name__ == "__main__":
    main()

Exécuter ensuite la commande:

python3 /tosiam/scripts/svrcfgxml.py /tmp/toto.xml config2.tosit.org

Le script modifie le fichier /tmp/toto.xml Exécuter ensuite:

ssoadm set-svrcfg-xml -u amadmin -f .pwd.txt -s http://"${HOSTNAME}":8080/"${CONTEXT}" -X /tmp/toto.xml

Voici le résultat de la commande pour tosiam1:

dans la console:
dans le fichier <INSTANCE>/boostrap:

ldaps://config1.tosit.org:1636/http%3A%2F%2Ftosiam1.tosit.org%3A8080%2Ftosiam?user=cn%3Ddsameuser%2Cou%3DDSAME+Users%2Cdc%3Dtosit%2Cdc%3Dorg&pwd=AgMDAAAbWM3l4AJXSnELyMQCmMwH3wJh5iRxta4ruuV4828TnE2oSnDigYxT2GBz22qK3n4DDQ%3D%3D&dsbasedn=dc%3Dtosit%2Cdc%3Dorg&dsmgr=uid%3Dtosiam%2Cou%3Dsystem%2Cdc%3Dtosit%2Cdc%3Dorg&dspwd=AgMDAAAbWJUwcnsvzYtPrD0N8eqXPNNHlY8RBFTvLvPeX4QJCyeheZWq8gW3Um1%2BBkMPWfnecw%3D%3D&ver=1.0
ldaps://config2.tosit.org:1636/http%3A%2F%2Ftosiam1.tosit.org%3A8080%2Ftosiam?user=cn%3Ddsameuser%2Cou%3DDSAME+Users%2Cdc%3Dtosit%2Cdc%3Dorg&pwd=AgMDAAAbWM3l4AJXSnELyMQCmMwH3wJh5iRxta4ruuV4828TnE2oSnDigYxT2GBz22qK3n4DDQ%3D%3D&dsbasedn=dc%3Dtosit%2Cdc%3Dorg&dsmgr=uid%3Dtosiam%2Cou%3Dsystem%2Cdc%3Dtosit%2Cdc%3Dorg&dspwd=AgMDAAAbWJUwcnsvzYtPrD0N8eqXPNNHlY8RBFTvLvPeX4QJCyeheZWq8gW3Um1%2BBkMPWfnecw%3D%3D&ver=1.0

Redémarrage des instances TOSIAM.

Afin de prendre en compte les modification au niveau du CTS et des bases de configuration, redémarrer les serveurs TOMCAT.