13.4. Utilisation de SSO (Single Sign On) pour les Applications Web

Aperçu

Les fonctionnalités SSO (Single Sign On) sont fournies par les sous-systèmes web et Infinispan. Utiliser cette procédure pour configurer SSO dans les applications web.

Prérequis

  • Vous devez avoir un domaine de sécurité configuré qui gère les authentifications et autorisations.
  • Le sous-système infinispan doit être présent. Il se trouve dans le profil complet-ha pour un domaine géré, ou en utilisant la configuration standalone-full-ha.xml dans un serveur autonome.
  • Le web cache-conteneur et le cache-conteneur SSO doivent chacun être présents. Les exemples de fichiers de configurations contiennent déjà le cache-conteneur web, et certaines des configurations contiennent déjà le cache-conteneur SSO également. Utilisez les commandes suivantes pour vérifier et activer le cache conteneur SSO. Notez que ces commandes modifient le profil full d'un domaine géré. Vous pouvez modifier les commandes pour utiliser un profil différent, ou supprimer la portion /profile=full de la commande, pour un serveur autonome.

    Exemple 13.1. Vérifier le cache-conteneur web

    Les profils et les configurations mentionnées ci-dessus incluent le cache-conteneur web par défaut. Utilisez la commande suivante pour vérifier sa présence. Si vous utilisez un profil différent, remplacez par son nom à la place de ha. 
    /profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=false,proxies=false,include-runtime=false,include-defaults=true)
    Si le résultat affiche un success, le sous-système sera présent. Sinon, vous devrez l'ajouter.

    Exemple 13.2. Ajouter le cache-conteneur web

    Utiliser les trois commandes suivantes pour activer le cache-conteneur web à votre configuration. Modifier le nom du profil selon le cas, ainsi que les autres paramètres. Ici, les paramètres sont ceux utilisés dans une configuration par défaut. 
    /profile=ha/subsystem=infinispan/cache-container=web:add(aliases=["standard-session-cache"],default-cache="repl",module="org.jboss.as.clustering.web.infinispan")
    /profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)
    /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)

    Exemple 13.3. Vérifier le cache-conteneur SSO

    Éxécuter la commande de Management CLI suivante : 
    /profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
    Chercher une sortie qui ressemble à ceci : "sso" => {
    Si vous ne la trouvez pas, le cache-conteneur ne sera pas présent dans votre configuration.

    Exemple 13.4. Ajouter le cache-conteneur SSO

    /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
  • Le sous-système web doit être configuré pour utiliser SSO. La commande suivante active SSO sur le serveur virtuel appelé default-host et le domaine de cookies domaine.com. Le nom de cache est sso, et une nouvelle authentification est désactivée. 
    /profile=ha/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
  • Chaque application qui partage les informations SSO doit être configurée pour utiliser le même <security-domain> dans son descripteur de déploiement de jboss-web.xml et le même Realm dans son fichier de configuration web.xml.
Différences entre les valves clusteriées et les valves non-clusterisées

SSO clusterisée permet le partage d'authentification entre des hôtes distincts, tandis que ce n'est pas le cas pour SSO non-clusterisée. Les valves SSO en cluster et non clusterisées sont configurées de la même manière, mais SSO clusterisée comprend les paramètres cacheConfig, processExpiresInterval et maxEmptyLife, qui contrôlent la réplication en groupement des données persistantes.

Exemple 13.5. Exemple de configuration SSO clusterisée

Comme les configurations SSO clusterisées ou non sont si semblables, on ne montre que la configuration clusterisée. Cet exemple utilise un domaine de sécurité nommé tomcat. 
<jboss-web>
	<security-domain>tomcat</security-domain>
	<valve>
		<class-name>org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn</class-name>
		<param>
			<param-name>maxEmptyLife</param-name>
			<param-value>900</param-value>
		</param>
	</valve>
</jboss-web>

Tableau 13.1. Options de configuration SSO

Option Description
cookieDomain
Domaine hôte utilisé pour les cookies SSO. La valeur par défaut est /. Pour permettre à app1.xyz.com et à app2.xyz.com de partager les cookies SSO, vous devrez définir le cookieDomain à xyz.com.
maxEmptyLife
SSO clusterisée uniquement. Le nombre maximum de secondes qu'une valve SSO sans sessions actives sera utilisable par une demande, avant d'expirer. Une valeur positive permet une manipulation appropriée d'arrêt d'un nœud si c'est le seul avec des sessions actives attachées à la valve. Si maxEmptyLife est défini sur 0, la vanne se terminera en même temps que les copies de la session locale, mais des copies de sauvegarde des sessions, des applications en cluster, seront disponibles à d'autres nœuds du cluster. PSi on permet à la vanne à vivre au-delà de la durée de ses sessions gérées, cela donne du temps à l'utilisateur d'effectuer une autre demande qui puisse basculer sur un nœud différent, où il active la copie de sauvegarde de la session. La valeur par défaut, est de 1800 secondes (30 minutes).
processExpiresInterval
SSO clusterisé uniquement. Le nombre minimum de secondes entre les efforts de la valve pour trouver et invalider des instances SSO qui ont expiré le délai d'attente de MaxEmptyLife. La valeur par défaut est de 60 (1 minute).
requiresReauthentication
Si true, chaque requête utilise des informations d'authentification en cache pour authentifier à nouveau le domaine de sécurité. Si false (la valeur par défaut), une cookie SSO valide sera suffisante pour que la valve puisse authentifier chaque nouvelle requête.
Rendre une session non valide

Une application peut rendre invalide une session en invoquant la méthode javax.servlet.http.HttpSession.invalidate().

Report a bug