Sessions & Tokens

TOSIAM gère deux types de sessions : les sessions stateful (stockées dans le Core Token Store) et les tokens stateless (JWT autonomes). La compréhension de ces mécanismes est essentielle pour dimensionner et sécuriser un déploiement.

Sessions stateful

Après une authentification réussie, TOSIAM crée une session et retourne un tokenId (cookie iPlanetDirectoryPro par défaut). Ce token est une référence opaque vers la session stockée côté serveur dans le Core Token Store (CTS).

Cycle de vie

Authentification → tokenId → [idle timeout / max session time] → invalide

Deux minuteries contrôlent la durée de vie :

Paramètre	Description
Idle Timeout	Durée d’inactivité maximale avant expiration automatique
Max Session Time	Durée absolue maximale, quelle que soit l’activité

Un appel à validate ou toute requête portant le tokenId remet à zéro le compteur d’inactivité.

Stockage CTS

Le Core Token Store persiste les sessions dans l’annuaire LDAP de configuration (ou un annuaire CTS dédié). Les entrées CTS portent les attributs :

coreTokenId — identifiant unique du token
coreTokenUserId — DN de l’utilisateur propriétaire
coreTokenType — type (SESSION, OAUTH, UMA…)
coreTokenExpirationDate — date d’expiration

API REST de gestion des sessions

POST /realms/{realm}/sessions/{tokenId}/validate     → vérifier la validité
POST /realms/{realm}/sessions/{tokenId}/isActive     → booléen actif/inactif
POST /realms/{realm}/sessions/{tokenId}/getTimeLeft  → secondes restantes
POST /realms/{realm}/sessions/{tokenId}/logout       → invalider la session
POST /realms/{realm}/sessions/logout                 → déconnexion par tokenId (body)

Tokens OAuth2 stateless (JWT)

TOSIAM supporte les access tokens JWT (stateless). Contrairement aux sessions, ces tokens sont auto-porteurs : leur validation ne nécessite pas d’appel au CTS, uniquement la vérification de la signature et des claims.

Structure d’un access token JWT

{
  "sub": "alice",
  "iss": "https://tosiam.example.com/oauth2/realms/root",
  "aud": ["my-app"],
  "exp": 1735689600,
  "iat": 1735686000,
  "scope": "openid email profile",
  "client_id": "my-client",
  "realm": "/",
  "tokenName": "access_token"
}

Les tokens stateless sont signés avec les clés JWKS du realm, disponibles à :

GET /oauth2/{realm}/connect/jwk_uri

Tokens stateful OAuth2

Les tokens OAuth2 peuvent aussi être stateful (stockés en CTS). Dans ce cas, l’introspection consulte le CTS :

POST /oauth2/{realm}/introspect
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

token=eyJhbGci...

SSO Persistant

TOSIAM implémente un mécanisme de SSO persistant (“Remember me”) propre, distinct du cookie de session standard. Un token est stocké en LDAP et référencé par un cookie persistent_auth dont la durée de vie est configurable (par défaut 1 an = 31 536 000 secondes).

Les modules associés :

CheckPersistentAuth — vérifie la validité du token persistant au début d’un flux
SetPersistentAuth / SetPersistentSsoNode — crée le token après une authentification réussie
PostAuthPersistentAuth — plugin post-authentification qui pose le cookie

CSRF

TOSIAM impose une protection CSRF sur toutes les requêtes mutantes. Le cookie XSRF-TOKEN est obtenu via :

GET /csrf-token    → 204 No Content, pose le cookie (sans authentification requise)

Toutes les requêtes POST/PUT/DELETE doivent renvoyer ce token dans l’en-tête X-CSRF-Token.