Règles d'accès des modules de SSO (aka AccessRules)

1. Introduction

Pour des raisons fonctionnelles, il n'est pas toujours souhaitable de proposer le SSO à l'ensemble des utilisateurs de la plateforme.
Par ailleurs, pour des raisons techniques liées au fonctionnement de certains mécanismes de SSO, le SSO ne peut pas toujours s'appliquer à l'ensemble des utilisateurs (e.g.: l'authentification intégrée Windows disponible uniquement aux utilisateurs appartenant au domaine Windows et sur un poste du domaine).

Ainsi, on distingue généralement 2 populations :

• Les utilisateurs qui peuvent bénéficier du SSO, ou à qui ont souhaite le proposer
• Les utilisateurs qui doivent être exclus de la mécanique de SSO ou qui ne peuvent techniquement pas en bénéficier

La plupart des modules de SSO Jalios proposent une option pour ne pas authentifier automatiquement les utilisateurs via le SSO.
Si cette option est retenue, l'utilisation du SSO n'est jamais automatique, l'utilisateur arrive sur le site JCMS et la mire de login lui est présenté :

• soit il sait qu'il peut utiliser le SSO, il peut alors cliquer sur le bouton de connexion proposé par le SSO (eg "Connexion avec mon compte Windows", "Connexion avec CAS", ...)
  L'authentification est alors effectuée automatiquement sans nécessité de saisir d'identifiant sur JCMS.
• soit l'utilisateur saisit ses identifiants (login / mot de passe) manuellement dans le formulaire de connexion.

Cette approche n'est pas satisfaisante pour l'utilisateur.

Afin de fournir une expérience utilisateur de qualité grâce à une authentification totalement automatique, la mise en place d'une règle permet de différencier les 2 typologies de clients via un critère quelconque. Critère qui puisse être détecté par le serveur dans la requête du client Web.
Ceci permet de déclencher le SSO uniquement pour les clients qui le supportent.
C'est ce que propose les AccessRule dans tous les modules de SSO Jalios.

2. Les règles

Toutes informations que l'on peut faire transiter entre le poste client et le serveur web peut être utilisée pour discriminer les 2 populations.

Lorsqu'une expression régulière peut être spécifiée, les formats autorisés sont ceux supportés par l'API Java java.util.regex.Pattern (docs.oracle.com) 

Voici quelques exemples de configurations possibles.

2.1 Firewall ou Proxy - HttpHeaderAccessRule

Si tous les utilisateurs cibles du SSO passe par un forward proxy ou par un firewall, alors il peut être envisager de les identifier grâce à cela.
Soit en enrichissant les requêtes des clients via le proxy HTTP (par exemple un entête HTTP), soit en identifiant l'IP du client comme l'IP du proxy.
cf https://community.jalios.com/plugins/JcmsSSOPlugin/docs/javadoc/access-rules/com/jalios/jcms/authentication/rules/HttpHeaderAccessRule.html

2.2 Subnet ou VLAN - IpAccessRule

Les postes des utilisateurs cibles du SSO sont identifiables via leur IP ou via un sous réseau spécifique ?
cf https://community.jalios.com/plugins/JcmsSSOPlugin/docs/javadoc/access-rules/com/jalios/jcms/authentication/rules/IpAccessRule.html

2.3 DNS spécifique - HostnameAccessRule

Il est possible d'orienter les 2 populations de clients sur 2 domaines différent (eg extra.company.com vs intra.company.com).
Cette solution n'est pas optimum car elle nécessite de cloisonner les utilisateurs.
Elle est fortement découragée.
cf https://community.jalios.com/plugins/JcmsSSOPlugin/docs/javadoc/access-rules/com/jalios/jcms/authentication/rules/HostnameAccessRule.html

2.4 Chemin d'accès spécifique - UriAccessRule

Il est possible d'exclure l'authentification pour des URI spécifiques sur lesquelles on souhaiterait permettre d'autres méthodes d'authentification (par exemple des chemin de supervision).
Contrairement à toutes les autres règles, cette régle exclus de l'authentification les clients pour lesquel la règle s'applique. 
cf https://community.jalios.com/plugins/JcmsSSOPlugin/docs/javadoc/access-rules/com/jalios/jcms/authentication/rules/UriAccessRule.html

L'expression régulière spécifiée dans une UriAccessRule est utilisé sur la valeur RequestURI retournée par la spec JavaEE, cela n'inclut donc PAS la querystring/ les paramètres. cf https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getRequestURI()

2.5 Paramètre spécifiques - ParameterAccessRule

Il est possible de déclencher ou non l'authentification en fonction de la présence d'un ou plusieurs paramètres spécifiques. 

Le ParameterAccessRule est disponible uniquement dans les modules diffusés après novembre 2019. ( Module d'Authentification Windows - Waffle 3.1 et  Module d'authentification SAML 2.3 notamment). Consultez la javadoc distribuée dans votre module.

2.6 Combinaison de critères - MetaAccessRule

Il est possible de combiner plusieurs critères par simple déclaration. (eg depuis une ip et ayant le user agent xyz)
cf https://community.jalios.com/plugins/JcmsSSOPlugin/docs/javadoc/access-rules/com/jalios/jcms/authentication/rules/MetaAccessRule.html

La syntaxe supportée pour la déclaration des combinaisons est celle du moteur JEXL :
https://commons.apache.org/proper/commons-jexl/reference/syntax.html

Attention : pour être utilisées dans uneMetaAccessRule, vos règles doivent utiliser uniquement des caractères alphanumériques dans leur nom. En particulière l'utilisation du caractère "-" n'est pas valide car il serait intéprété comme le symbole mathématique "moins".

2.7 Autres...

Consultez la javadoc : https://community.jalios.com/plugins/JcmsSSOPlugin/docs/javadoc/access-rules/index.html

2.8 Développement spécifique

Il est possible de développer des règles spécifiques.
Consultez la javadoc : https://community.jalios.com/plugins/JcmsSSOPlugin/docs/javadoc/access-rules/index.html

3. Configuration

Les modules peuvent implémenter les règles d'accès de 2 façons différentes :

• soit dans une ServletFilter JavaEE, la configuration s'effectue alors dans le fichier web.xml
• soit dans un AuthenticationHandler JCMS, la configurations s'effectue alors par propriétés JCMS.

Dans les 2 cas le principe est toujours le même

• on défini une classe java (qui implémente l'interface AccessRule) qui fournira la règle d'accès
• on configure cette classe d'accès avec les paramètres qu'elle supporte

Consultez :

• la documentation du module de SSO que vous être en train de mettre en oeuvre pour connaitre quelle configuration mettre en oeuvre :
  • web.xml, sur quelle classe ?
  • propriétés JCMS, avec quel préfixe de propriété.
• la javadoc de chacune des classes d'AccessRule pour connaitre les configuration attendues

3.1 ServletFilter et web.xml

La configuration de la règle d'accès s'effectue dans la déclaration de la ServletFilter responsable de l'authentification.

  <filter>
   <filter-name>MyHttpFilter</filter-name>
   [...]
   <init-param>
       <param-name>access-rule.class</param-name>
       <param-value>com.jalios.jcms.authentication.rules.UserAgentAccessRule</param-value>
   </init-param>
   <init-param>
       <param-name>user-agent-access-rule.regex</param-name>
       <param-value>.*MyCompagny Custom UserAgent.*</param-value>
   </init-param>
  </filter>

⚠ Comme toutes valeurs spécifiées dans un fichier .xml : utilisez impérativement des entités XML pour les caractères spéciaux en XML :
--> What characters do I need to escape in XML documents? (stackoverflow.com)

3.2 AuthenticationHandler et propriétés JCMS

La configuration de la règle d'accès s'effectue en utilisant un préfixe défini par le module, il sera utilisé par l'AuthenticationHandler du module.

jcmsplugin.myplugin.access-rule.class: com.jalios.jcms.authentication.rules.UserAgentAccessRule
jcmsplugin.myplugin.user-agent-access-rule.regex:  .*MyCompagny Custom UserAgent.*

⚠ Comme toutes valeurs spécifiées dans un fichier.prop/.properties : échappez impérativement les caractères spéciaux avec le caractère "\" :
--> Properties.load (docs.oracle.com)

4. Cas d'usages

4.1 Authentification intégrée Windows

Pour un site intranet dont la majorité des utilisateurs sont des utilisateurs Windows, on souhaite proposer une authentification automatique basée sur le protocole SPNEGO/Kerberos grâce au Module Waffle

Pour l'authentification intégrée Windows, on distingue 2 populations :

• Les clients pouvant bénéficier d'une authentification Windows automatique, sans saisi manuelle d'informations de connexion.
  Il s'agit des postes rattachés aux domaines Windows, dans lequel une session avec un utilisateur du domaine a été ouverte, et dont le navigateur supporte l'authentification SPNEGO (Kerberos/NTLM).
• Les clients pour lesquels l’authentification Windows automatique n'est pas possible, et qui nécessiteront donc la saisie manuelle d'informations de connexion.
  Il s'agit notamment, mais pas de façon exhaustive :
  • des postes non rattachés au domaine ; postes externes, terminaux mobiles, ...
  • des navigateurs ne supportant pas l'authentification SPNEGO (Kerberos/NTLM) ; Safari

En raisons du mode de fonctionnement du protocole SPNEGO (Kerberos/NTLM), si l'authentification Windows est demandée à un client qui ne le supporte pas (seconde population ci-dessus), alors le navigateur affichera une demande d'authentification ne pouvant aboutir qui se conclura par une erreur 401.

Pour garantir une bonne expérience utilisateur, il faut privilégier la mise en place d'une règle discriminante sous forme de liste blanche (whitelist), par opposition à une approche par liste noire (blacklist) :

• L'approche par whitelist consiste à déclencher le SSO pour les navigateurs/clients dont on sait que ça fonctionnera,
• L'approche par blacklist consisterait à ne pas déclencher le SSO pour les navigateurs/clients dont on sait qu'ils ne fonctionnent pas

En effet avec l'approche whitelist, le pire qui puisse arriver c'est qu'un utilisateur pour qui l'authentification automatique aurait pu fonctionner soit obliger de saisir son login mot de passe. Tandis qu'avec l'approche blacklist, certains utilisateurs ne pourront pas du tout se connecter.

L'approche que nous proposons en standard consiste à déployer sur les postes Windows une GPO qui complétera le User-Agent d'Internet Explorer, et qui permettra ainsi d'identifier sans le moindre doute les clients supportant l'authentification Windows.
Cette solution est immédiate à mettre en œuvre et est déjà en place en interne chez Jalios et chez plusieurs de nos clients.
Elle n'a pas d'impact connu sur les applicatifs annexes car le User-Agent est simplement complété et les informations de version ne sont pas pas modifiées.
C'est une approche proposée par Microsoft :
http://technet.microsoft.com/en-us/library/cc770379
Avertissement : Cette approche est valable uniquement pour Internet Explorer et ne s'applique pas sur Microsoft Edge. 

Voici par exemple une configuration de web.xml pour appliquer l'authentification Waffe uniquement si le User-Agent contient le nom de la société :

     <filter>
      <filter-name>WaffleHttpFilter</filter-name>
      <filter-class>com.jalios.jcmsplugin.waffle.WaffleHttpFilter</filter-class>
      [...]
      <init-param>
          <param-name>access-rule.class</param-name>
          <param-value>com.jalios.jcms.authentication.rules.UserAgentAccessRule</param-value>
      </init-param>
      <init-param>
          <param-name>user-agent-access-rule.regex</param-name>
          <param-value>.*MyCompagny.*</param-value>
      </init-param>
     </filter>

4.2 Extranet CAS

Sur un site de type extranet, on souhaite proposer aux utilisateur une authentification via un serveur CAS qui n'est accessible que lorsque les utilisateurs sont sur les réseaux interne. On utilise le Module CAS.

Le critère retenu est le filtrage des utilisateurs en utilisant leur IP de provenance.

Voici par exemple une configuration de web.xml pour appliquer l'authentification CAS uniquement aux utilisateur sur le réseau local :

  <filter>
   <filter-name>CasFilter</filter-name>
   <filter-class>com.jalios.jcmsplugin.cas.CasFilter</filter-class>
   [...]
   <init-param>
       <param-name>access-rule.class</param-name>
       <param-value>com.jalios.jcms.authentication.rules.IpAccessRule</param-value>
   </init-param>
   <init-param>
       <param-name>ip-access-rule.regex</param-name>
       <param-value>^192\.168\.0\..*$</param-value>
   </init-param>
  </filter>