You are not logged in.
Au cours d'échanges avec vous, j'ai appris que la nouvelle version (3.5 ?) devrait permette d'herberger des sites avec des authentifications multiples.
Je pense qu'il s'agit d'héberger des sites avec un type d'authentification par site. Par exemple :
site1 : CAS (avec LDAP)
site2: fédération d'identité (shibboleth)
site3: bas locale
....
Est-ce le modèle envisagé ?
Je ne pense pas qu'il soit possible de mixer les methodes d'authentification sur un même site.
J'ai besoin à terme d'un site avec authentification Shibboleth. Pour le moment, j'utilise CAS en V3.3. Puis-je commencer ce site (en CAS) sur ma version actuelle et utiliser par la suite l'authentification Shibboleth, quand j'aurai migrer ma plateforme dans ma nouvelle version ?
Merci pour vos réponses.
Offline
Bonjour,
une future version (mais pas la 3.5) permettra de combiner différentes authentification en effet.
Mais en ce qui concerne les sites il est déjà possible de le faire via un peu de configuration et d'installation, mais par contre la base d'utilisateurs associée doit être communes.
Les exemples que vous citez sont donc possible pour peu que vous choisissiez comme base d'utilisateur la base LDAP+SQL (et que shibboleth fonctionne avec votre ldap - ce qui doit être le cas).
Par contre pour avoir des authentifications différentes sur 2 sites, il faut installer 2 fois l'application site, puisque l'authentficiation s'applique à l'application site et pas au site hébergé.
Pour ce qui est de mixer les authentifications, il existe une extension CAS+Basic, que redirige vers CAS en mode gateway puis affiche un basic. Si vous le mixez avec un LDAP+SQL vous obtiendrez le fonctionnement suivant :
* si l'utilisateur ldap est déjà authentifié sur CAS, il est automatiquement loggué et ses infos sont prises dans le LDAP
* si l'utilisateur ldap n'est pas authentifié sur CAS, la popup s'affiche et il peut saisir son login/mdp LDAP
* un utilisateur sql n'est pas authentifié sur CAS, la popup s'affiche et il peut saisir son login/mdp SQL
Je pense que ça répond à votre besoin.
Il tout à fait possible de changer de méthode d'authentification après coup, il suffit que le login reste le même.
Pour finir, concernant l'authentification Shibboleth, nous n'avons pas le composant directement sur étagère, il vous faudra faire un peu de java mais on pourra vous fournir un code d'exemple à adapter.
Raphael Franchet
Expert Ametys
Offline
Merci pour ces réponses.
Dans le cas qui me préoccupe actuellement, je précise que c'est le back-office qui est concerné . J'ai utilisé site au sens général et non front-office.
En attendant une authentification Shibboleth, je peux très bien me contenter d'une authentification (sur le cms) en CAS (pour quelques contributeurs locaux) + basic (quelques contributeurs externes).
Je vais tester cette solution.
Offline
J'ai activé l'extension CAS+Basic sur mon serveur de dev. Le fonctionnement est bien celui que vous m'avez indiqué.
J'ai par contre des réticences pour mettre cette fonctionnalité en production, car cela va perturber les contributeurs (CAS) s'il n'ont pas encore été authentifié.
Je ne vois pas de solution pour forcer l'authentification CAS (en interne, car notre back-office n'est pas accessible, sauf exception de l'extérieur) et en Basic pour les autres (dans ce cas, on pourrait utiliser https) ....
Avez-vous des idées ?
Merci
Offline
Le seul moyen serait de faire une page "portail" non authentifiée avec un lien manuel vers CAS, ou un lien vers l'url d'authentification du site sinon... mais du coup l'utilisateur déjà authentifié sur CAS doit quand même cliquer qqpart.
Dans l'absolu, on peut imaginer remplacer le CAS+Basic par un CAS+Form et dans le formulaire mettre une icône CAS pour rediriger en dur vers le CAS... mais cela nécessiterait un peu de codage ; et je ne sais pas si ça serait facile ou pas
Raphael Franchet
Expert Ametys
Offline
J'ai trouvé une solution.
On utilise toujours le même non de host pour notre cms (cmsv3)
Je force l'authentification CAS puour ce host dans la config apache.
Je fournis un autre nom de host pour accéder à la chaine complète (local,ldap,CAS) par exemple cms3
Je peux fournir la config apache et tomcat au besoin.
P. Delage
Offline
Si j'ai bien compris, selon les contributeurs vous donnez une url différente ?
par exemple qui redirige vers CAS en mode non gateway puis vers le cms
et qui envoie directement sur le cms
et la conf du cms est CASgateway+Basic ?
Pas mal
Raphael Franchet
Expert Ametys
Offline
Je complète ce sujet.
Maintenant que le cas du backoffice est résolu, j'ai une demande identique, mais sur le front office.
Le but est de permettre un accès authentifié (via la base locale) à des utilisateurs externes (hors CAS) à une zone limité.
J'ai donc configuré un FO test avec le même type de config.
Cela ne fonctionne pas. L'UI admin du FO ne me demande pas de config BD .... Ainsi, je n'ai pas accès aux utilisateurs locaux de ma BD.
Par contre, le fonctionnement de l'authentification est le bon (BASIC/LDAP puis CAS)
Je pense que ce n'est pas la bonne méthode. Il existe le plugin usersManagerFO qui, il me semble fournit les users aux FO.
Mais cela permet-il cette authentification ?
Merci
Offline
La conf par défaut du front ne nécessite pas d'accès à la base de données, donc la feature est désactivée.
Malheureusement, elle en se réactive pas toute seule quand elle est nécessaire
Il faut donc ouvrir le fichier runtime.xml du front et mettre en commentaire la ligne
<feature>core/runtime.datasource.core</feature>
Raphael Franchet
Expert Ametys
Offline
La limitation de l'accès aux pages du front-office fonctionne parfaitement.
Dans le cas d'un extranet, ouvert à l'extérieur de notre campus, à destination d'utilisateurs CAS et base locale Ametys, on me demande s'il est possible de limiter globalement l'accès à tout le plan du site.
Pour le moment, on contourne le problème en limitant l'accès à toutes les pages (rubriques principales).
Mais, la gestion va se révéler lourde, car il faut renouveler l'opération à chaque fois qu'on ajoute un nouvel utilisateur.
De plus, en cas de création d'une nouvelle page (rubrique principale), il ne faut pas oublier de limiter son accès ....
Merci
Offline
La fonctionnalité de limiter l'accès à tout le plan du site a été rajoutée en 3.5 (sortie prévue d'ici quelques semaines)
Pour ce qui est des utilisateurs, pourquoi ne pas utiliser des groupes pour éviter de le faire utilisateur par utilisateur ?
Offline
Bonjour Cédric,
Merci pour l'info pour la version 3.5
J'avais bien pensé à l'utilisation des groupes. J'utilise l'extension group.usersDrivenLdap sur le bo et le fo.
Je viens de tester sur ma plateforme de test l'extension group.usersDrivenLdapandjdbc
J'ai ainsi intégrer un utilisateur (base local hors CAS) dans un groupe local sur le bo.
Par contre, je n'ai pas cette extension sur le fo !!
Merci
Patrick
Offline
Sur le FO il n'y a rien à configurer car les groupes sont gérés par le backoffice.
Le FO sert à deux choses :
1) être un proxy-cache
2) authentifier les utilisateurs
Mais ensuite il transmet l'id de l'utilisateur au backoffice. C'est le BO ensuite qui le met dans un groupe ou pas
Raphael Franchet
Expert Ametys
Offline
OK. je voulais tester mais je ne trouve pas cette extension sur ma plateforme de prod en V3.3.1 ....
Je ne l'ai pas encore passée en 3.4 ...
Merci
Last edited by pdelage (30/04/2013 14:47:10)
Offline
Il est possible en effet qu'elle n'existe pas en 3.3
Raphael Franchet
Expert Ametys
Offline