Composants et couches

Une installation TOSIAM se décompose fonctionnellement en deux couches : la couche IAM (les instances TOSIAM elles-mêmes, qui portent la logique d’authentification, d’autorisation et de fédération) et la couche de données, elle-même divisée en trois bases distinctes.

Vue d’ensemble

                          ┌───────────────────────┐
                          │     Load Balancer      │
                          └───────────┬────────────┘
                                      │
            ┌──────────────┬─────────┴────────┬──────────────┐
            │              │                  │              │
       ┌────┴────┐    ┌────┴────┐        ┌────┴────┐    ┌────┴────┐
       │ TOSIAM  │    │ TOSIAM  │        │ TOSIAM  │    │ TOSIAM  │
       │ node 1  │    │ node 2  │  ...   │ node 3  │    │ node N  │
       └────┬────┘    └────┬────┘        └────┬────┘    └────┬────┘
            └──────────────┴─────────┬─────────┴──────────────┘
                                      │
              ┌───────────────────────┼───────────────────────┐
              │                       │                       │
       ┌──────┴──────┐        ┌───────┴───────┐       ┌───────┴───────┐
       │ Config Store│        │  Core Token   │       │  User Store   │
       │   (TosDJ)   │        │  Store (CTS)  │       │ (TosDJ / LDAP │
       │             │        │               │       │  / AD / JDBC) │
       └─────────────┘        └───────────────┘       └───────────────┘

Chaque instance TOSIAM est sans état applicatif propre : tout ce qui doit survivre à un redémarrage ou être partagé entre nœuds (configuration, sessions, tokens, identités) est délégué à la couche de données. C’est cette propriété qui permet de faire grossir la ferme de serveurs sans contrainte d’affinité forte.

Les trois bases

Base	Contenu	Profil d’accès	Volumétrie typique
Config Store	Realms, services, chaînes/graphes d’authentification, agents, politiques	Très majoritairement lecture, mis en cache par nœud	Faible (quelques Mo à quelques dizaines de Mo)
Core Token Store (CTS)	Sessions, tokens OAuth2/OIDC stateful, assertions SAML2, tokens UMA	Écriture intensive (création/validation/renouvellement à chaque requête)	Élevée et proportionnelle au nombre d’utilisateurs actifs
User Store	Identités : utilisateurs, groupes, rôles, attributs, credentials	Majoritairement lecture, écritures ponctuelles (changement de mot de passe, provisioning)	Proportionnelle à la base d’utilisateurs

Config Store

Le Config Store porte toute la configuration décrite dans les pages Realms et Authentification : définitions de services, instances de modules, chaînes et graphes, agents, politiques d’autorisation. Chaque instance TOSIAM charge cette configuration au démarrage et la garde en cache mémoire ; les modifications sont propagées aux autres nœuds via une recherche persistante LDAP (le même mécanisme que celui utilisé pour les datastores d’identité, voir Modèle d’identité), ce qui évite un polling actif.

Son faible volume de données et son faible taux d’écriture en font la base la plus simple à répliquer intégralement sur tous les sites.

Core Token Store (CTS)

Le CTS est décrit en détail dans Sessions & Tokens. C’est la base la plus sollicitée en écriture : chaque authentification crée une entrée, chaque requête authentifiée peut réinitialiser un compteur d’inactivité, chaque émission ou introspection de token stateful lit ou écrit une entrée coreTokenId. C’est structurellement le premier composant à saturer lorsque le trafic augmente, et c’est pour cette raison qu’il fait l’objet d’un traitement particulier (réplication et sharding) détaillé dans la page Scalabilité & haute disponibilité.

User Store

Le User Store héberge les identités au sens de Modèle d’identité. Il peut être interne (TosDJ, l’implémentation LDAP fournie avec TOSIAM) ou externe (Active Directory, annuaire LDAP tiers, backend JDBC), et sa configuration est par realm : rien n’empêche un realm /employees de pointer vers un Active Directory d’entreprise pendant qu’un realm /clients utilise un TosDJ dédié.

Connexions depuis un nœud TOSIAM

Chaque instance TOSIAM maintient trois pools de connexions indépendants, un par base, chacun avec sa propre liste de serveurs (primaire + secours) :

# Config Store
com.tosiam.stores.config.ldapurls=ldap://cfg1.internal:1389,ldap://cfg2.internal:1389

# Core Token Store
com.tosiam.stores.cts.ldapurls=ldap://cts1.internal:1389,ldap://cts2.internal:1389

# User Store (par realm)
com.tosiam.stores.user.ldapurls=ldap://users1.internal:1389,ldap://users2.internal:1389

Cette indépendance est ce qui permet de faire évoluer chaque base séparément : on peut répliquer le Config Store et le User Store sans toucher au CTS, et inversement shardé le CTS sans impacter les deux autres.