We apologize for untranslated text, you can use the Google Translation button to get an automatic translation of the web page in the language of your choice.

Comment gérer vous la connexion des membres extérieurs à votre JCMS ?

Benoit Chapel · on 5/15/14 at 8:28 AM

Si vous utilisez un SSO en frontal de JCMS et si vous êtes confrontés au besoin de connexion de membres extérieurs, comment faites vous ?

  1. Est-ce que vous avez une partie privé SSOifiée et une partie publique pour la connexion des extérieurs.
  2. Est-ce que vous ajoutez les comptes extérieurs pour le SSO.
  3. Est-ce que vous avez un site publique qui contient uniquement la portlet de login et qui délégue l'authentification au SSO.
  4. Est-ce que vous court-circuitez le SSO pour l'url de la page de login.

Quelle est la meilleure pratique selon vous ?

#1

Bonjour,

J'ai quelques questions supplémentaires :

  • pouvez-nous définir la notion "membre extérieur" ?
  • quelle est votre infrastructure (Linux, Windows, type de SSO, ...) ?
  • quelles sont les contraintes de sécurité imposées par votre RSSI ?
  • et puis, quel type de site vous souhaitez exposer à ces "membres extérieurs" ?

Merci.

Xuan Tuong LE · on 5/15/14 at 9:16 AM
#2

Infrastructure : Linux pour JCMS

SSO : ClearTrust

Membre extérieur : Tous membres qui n'est pas dans notre Système d'information (pas dans le SSO ClearTrust car pas dans le LDAP). En général, les membres extérieurs ne disposent pas d'une adresse email ac-clermont.fr.

La notion "Invité" de JCMS pourrai correspondre si on souhaite ouvrir uniquement des espaces collaboratifs.

Les contraintes de sécurité imposées par notre RSSI sont probablement les plus contraignantes. Une réunion est planifiée pour faire le point mais je souhaite préalablement connaître les différentes options possibles.

Le type de site exposé est Espaces collaboratifs dans un premier temps.

Benoit Chapel · on 5/15/14 at 9:37 AM
4 pts
Olivier Jaquemet · on 5/15/14 at 9:12 AM

Bonjour,

Tous les modules de SSO récent fournis par Jalios pour JCMS, intègrent la possibilité de définir des règles d'accès (via l'API AccessRules) pour déclencher le SSO uniquement pour certaines populations d'utilisateurs bien identifiées.
C'est le cas du module d'authentification Windows Kerberos, du module Jcms SSO, module CAS, ainsi que d'autres modules (internes ou en beta privé)..

Ainsi, il est aisé de dire :

  1. pour la population 1 respectant telle régle on déclenche le SSO (e.g.: accès via ip interne, présence d'un header HTTP spécifique type user agent)
  2. pour le reste des utilisateurs on ne déclenche pas le SSO et on propose l'authentification "manuelle" par login / mot de passe

Par exemple, pour l'intranet Jalios : 

  1. si le user agent indique une appartenance au domaine Windows de la société (User-Agent modifié via déploiement GPO) et qu'il s'agit d'un navigateur IE, alors l'authentification Kerberos est demandée au navigateur
    --> l'utilisateur est authentifié automatiquement
  2. dans tous les autres cas (poste non rattaché au domaine, autre navigateur non supporté, etc etc) l'authentification manuelle doit être effectuée.

C'est l'architecture que nous recommandons généralement de façon systématique 

  • elle permet d'automatiser les authentifications pour les populations qui peuvent en bénéficier, l'expérience utilisateur est donc améliorer
  • mais elle n'empeche pas les autres utilisateurs d'effectuer une connexion manuelle

 

Certain anciens modules d'authentification comme le module Cleart Trust ne bénéficient pas de cette capacité.

#1

Merci de cette réponse complète

Benoit Chapel · on 5/15/14 at 9:43 AM
1 pt