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 :

Faites défiler le tableau

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

Dans la console#

Le menu Sessions liste les sessions SSO actives du royaume sélectionné, avec le temps restant avant expiration et le temps d’inactivité de chacune. L’action Invalider la session déconnecte immédiatement l’utilisateur.

Menu Sessions de la console : trois sessions actives avec temps restant, temps d'inactivité et action d'invalidation — Les sessions actives : temps restant et temps d’inactivité (1), invalidation d’une session (2). Les identifiants de session sont floutés.

API REST de gestion des sessions#

http

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 : un serveur de ressources peut les valider par leur signature et leurs claims, sans appeler TOSIAM. TOSIAM garde toutefois leurs métadonnées dans le CTS et une liste de révocation (voir Tokens).

Structure d’un access token JWT#

json

{
  "sub": "alice",
  "iss": "https://tosiam.example.com/tosiam/oauth2",
  "aud": ["my-client"],
  "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 :

http

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 :

http

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.