Bonjour,
Je dois intégrer un spip avec le serveur SSO CAS.
Il existe un plugin pour la partie frontoffice de SPIP.
Mais là, je dois aussi l'utiliser pour la partie privée de SPIP.
Quelqu'un aurait-il des renseignements à me donner ou quelqu'un a déjà
fait ce genre de chose ?
je suis preneur de toutes informations et de toute aide 
merci d'avance
Cordialement,
2008/2/8, Nouveaux Territoires <listes@nouveauxterritoires.fr>:
Bonjour,
Je dois intégrer un spip avec le serveur SSO CAS.
Il existe un plugin pour la partie frontoffice de SPIP.
Mais là, je dois aussi l’utiliser pour la partie privée de SPIP.
Quelqu’un aurait-il des renseignements à me donner ou quelqu’un a déjà
fait ce genre de chose ?je suis preneur de toutes informations et de toute aide
On y réfléchit aussi, la méthode du plugin n’est pas du tout adapté car elle consiste bloquer les pages en amont sans pour autant faire de vrai lien avec les user SPIP.
Pour ton besoin il faut propager l’identification en intervenant dans le processus d’authentification voir dans ecrire/inc les différentes méthode d’authentification.
La partie droit se rapproche après de ce qui est fait pour LDAP (pas de contrôle du pass mais juste récup du profil).
Pour la propagation une méthode classique par renvoi vers cas authentification et échange de jeton devrait marcher.
Pas plus d’info à fournir pour l’instant, on commence et on a surtout regardé côté SPIP et moins creuser l’aspect CAS.
a+
Arnaud
Bonjour,
Je dois intégrer un spip avec le serveur SSO CAS.
Il existe un plugin pour la partie frontoffice de SPIP.
Mais là, je dois aussi l'utiliser pour la partie privée de SPIP.
L'authentification pour accès à "ecrire/" est aussi gérée dans le plugin "casldapauthspip".
Nous l'avons utilisé avec succès... après quelques ajustements, notamment pour supporter un annuaire ActiveDirectory plutôt que OpenLDAP.
Ce plugin étant malheureusement géré ailleurs que sur la zone, il a peu de visibilité, et il est difficile d'y contribuer.
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
Je dois intégrer un spip avec le serveur SSO CAS.
On y réfléchit aussi, la méthode du plugin n'est pas du tout adapté car elle consiste bloquer les pages en amont sans pour autant faire de vrai lien avec les user SPIP.
Qu'entends-tu par là ???
Avec le plugin "casldapauthspip", comme c'est le cas par défaut avec une connexion LDAP, les utilisateurs SPIP sont créés à la volée. Il y a bien un lien.
Pour ton besoin il faut propager l'identification en intervenant dans le processus d'authentification voir dans ecrire/inc les différentes méthode d'authentification.
C'est ce que fait le plugin.
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
Le 11/02/08, Nicolas Hoizey <nicolas@hoizey.com> a écrit :
Je dois intégrer un spip avec le serveur SSO CAS.
On y réfléchit aussi, la méthode du plugin n’est pas du tout adapté car
elle consiste bloquer les pages en amont sans pour autant faire de vrai
lien avec les user SPIP.Qu’entends-tu par là ???
Par là j’entends rien :-))))
Je vais essayer de détailler
Le plugin CAS semble se comporter comme une sorte de proxy en partie publique qui laisse passer ou pas les pages selon qu’on se soit identifié dans CAS.
Ce que fait le <INCLUDE(checkauth.php)> (pis ça me gène tjs de coller saufagement un include dans un squelette m^me si au final c’est pareil.)
Si je veux relier mes visiteur CAS aux visiteurs spip ça le fait pas non ?
Je viens de relire la classe casldap ça n’a pas l’air d’avoir changé.
Pour mon besoin je m’identifie via cas mais ce n’est pas lui qui protège mes page c’est accès restreint.
Avec le plugin « casldapauthspip », comme c’est le cas par défaut avec une
connexion LDAP, les utilisateurs SPIP sont créés à la volée. Il y a bien
un lien.
En fait c’est plutôt ce mécanisme que je veux reproduire pour login public.
Plus un autre point qui est la dépendance au LDAP que je dois couper mais là c’est annexe ; un appel entre le serveur spip et le serveur CAS peut le résoudre en remplacement du contrôle direct dans le LDAP qui me gêne un brin car me rend dépendant de la techno de stockage du SSO.
En résumé mon processus devrait être :
après il y a la mécanique de logout inverse.
A+
Arnaud
Le plugin CAS semble se comporter comme une sorte de proxy en partie publique qui laisse passer ou pas les pages selon qu'on se soit identifié dans CAS.
Effectivement, avec une session PHP.
Ce que fait le <INCLUDE(checkauth.php)> (pis ça me gène tjs de coller saufagement un include dans un squelette m^me si au final c'est pareil.)
Oui. Je suis d'accord qu'il est dommage de devoir modifier les squelettes.
Si je veux relier mes visiteur CAS aux visiteurs spip ça le fait pas non ?
Je viens de relire la classe casldap ça n'a pas l'air d'avoir changé.
Oui, non, effectivement, j'ai répondu trop vite.
Pour mon besoin je m'identifie via cas mais ce n'est pas lui qui protège mes page c'est accès restreint.
Mélange intéressant... 
En résumé mon processus devrait être :
- vérifier si une session SPIP existe
- si oui ça roule (ça permet de gérer une authentification locale en plus de CAS)
- si non vérifier authentification CAS
- si authentifié récupérer les infos et les propager à une sessions SPIP (pour la réutiliser dans accès restreint)
- sinon demander authentification CAS, une fois identifié retour des infos d'identification et propagation à la session SPIP
En effet, ce mécanisme me semble plus sein que celui du plugin casldapauthspip.
Mais comment fais-tu "récupérer les infos" ? Tu prévois une notion de "backend" configurable, avec accès possible à une BDD, un LDAP, un Web Service, ou autre ?
En tout cas, je suis intéressé, je testerais si c'est sur la zone, et j'essairais d'apporter mon expérience SSO/CAS.
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
Le 11/02/08, Nicolas Hoizey <nicolas@hoizey.com> a écrit :
Pour mon besoin je m’identifie via cas mais ce n’est pas lui qui protège
mes page c’est accès restreint.Mélange intéressant…
j’aime pas réécrire un truc qui fait déjà ce que je souhaite :-b
En résumé mon processus devrait être :
- vérifier si une session SPIP existe
- si oui ça roule (ça permet de gérer une authentification locale en
plus de CAS)- si non vérifier authentification CAS
- si authentifié récupérer les infos et les propager à une sessions SPIP
(pour la réutiliser dans accès restreint)- sinon demander authentification CAS, une fois identifié retour des
infos d’identification et propagation à la session SPIPEn effet, ce mécanisme me semble plus sein que celui du plugin
casldapauthspip.
heu cachez ce sein que je ne saurai voir => plus sain
Mais comment fais-tu « récupérer les infos » ? Tu prévois une notion de
« backend » configurable, avec accès possible à une BDD, un LDAP, un Web
Service, ou autre ?
pour l’instant on passe par une simple requete http : on envoie le jeton en paramètre et en retour on obtient les infos de profil.
Dans notre cas on sécurise en autorisant le flux que de serveur à serveur autorisé.
En tout cas, je suis intéressé, je testerais si c’est sur la zone, et
j’essairais d’apporter mon expérience SSO/CAS.
C’est pas en ligne parce que le mécanisme actuel fait du sso maison avec une autre appli web mais on utilise déjà un mécanisme similaire.
Notre cible est de le porter sur CAS, comment CAS peut-il propager un id de session/jeton …
Actuellement nous passons par des redirection d’url et passage de paramètres dans l’url.
On sécurise un peu le tout en croisant les jetons de chaque coté (j’en passe un au SSO qui me le renvoie avec le sien, spip contrôle le profil en envoyant le jeton.
a+
Arnaud
2008/2/11 Arnaud Ventre <ventrea@gmail.com>:
C'est pas en ligne parce que le mécanisme actuel fait du sso maison avec une
autre appli web mais on utilise déjà un mécanisme similaire.Notre cible est de le porter sur CAS, comment CAS peut-il propager un id de
session/jeton ...
Actuellement nous passons par des redirection d'url et passage de paramètres
dans l'url.
On sécurise un peu le tout en croisant les jetons de chaque coté (j'en passe
un au SSO qui me le renvoie avec le sien, spip contrôle le profil en
envoyant le jeton.
Il y a la librairie phpCAS qui fait cela très bien. Une piste pour ne
pas réinventer la roue, peut-être.
http://www.ja-sig.org/wiki/display/CASC/phpCAS
C'est cette librairie qui est utilisée par le plugin SPIP, de mémoire.
.Gilles
a+
------------------------------
Arnaud
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Mélange intéressant...
j'aime pas réécrire un truc qui fait déjà ce que je souhaite :-b
Clair.
En effet, ce mécanisme me semble plus sein que celui du plugin
casldapauthspip.heu cachez ce sein que je ne saurai voir => plus sain
Oups...
Mais comment fais-tu "récupérer les infos" ? Tu prévois une notion de
"backend" configurable, avec accès possible à une BDD, un LDAP, un Web
Service, ou autre ?pour l'instant on passe par une simple requete http : on envoie le jeton en paramètre et en retour on obtient les infos de profil.
Avec un schema XML définissant la structure de ce profil, pour que ce soit générique et transposable à d'autres serveurs de profils ?
Dans notre cas on sécurise en autorisant le flux que de serveur à serveur autorisé.
Avec des certificats ?
En tout cas, je suis intéressé, je testerais si c'est sur la zone, et
j'essairais d'apporter mon expérience SSO/CAS.C'est pas en ligne parce que le mécanisme actuel fait du sso maison avec une autre appli web mais on utilise déjà un mécanisme similaire.
OK
Notre cible est de le porter sur CAS, comment CAS peut-il propager un id de session/jeton ...
C'est son unique rôle, et il le fait bien !
Actuellement nous passons par des redirection d'url et passage de paramètres dans l'url.
C'est en gros ça, avec des cookies en plus.
On sécurise un peu le tout en croisant les jetons de chaque coté (j'en passe un au SSO qui me le renvoie avec le sien, spip contrôle le profil en envoyant le jeton.
Bin c'est à priori ce que fait CAS aussi, ça tombe bien...
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
Il y a la librairie phpCAS qui fait cela très bien. Une piste pour ne
pas réinventer la roue, peut-être.
Confluence
C'est cette librairie qui est utilisée par le plugin SPIP, de mémoire.
Exact.
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
Le 12/02/08, Nicolas Hoizey <nicolas@hoizey.com> a écrit :
pour l’instant on passe par une simple requete http : on envoie le jeton
en paramètre et en retour on obtient les infos de profil.
Avec un schema XML définissant la structure de ce profil, pour que ce soit générique et transposable à d’autres serveurs de profils ?
ça pourrait on a déjà ça sur un webservice de gestion d’identité on pourrait partager le même schéma de gestion d’identité qui est assez générique (un gestion d’dentité plus une structure multioccurence permettant de diffuser des infos de profils diverses
Dans notre cas on sécurise en autorisant le flux que de serveur à
serveur autorisé.Avec des certificats ?
Non pour l’instant bourrin car dans des zones internes maitrisée, pour une externalisation du service c’est un point à creuser, pquoipas certificat ça me semble adapté.
En tout cas, je suis intéressé, je testerais si c’est sur la zone, et
j’essairais d’apporter mon expérience SSO/CAS.C’est pas en ligne parce que le mécanisme actuel fait du sso maison avec
une autre appli web mais on utilise déjà un mécanisme similaire.OK
Notre cible est de le porter sur CAS, comment CAS peut-il propager un id
de session/jeton …C’est son unique rôle, et il le fait bien !
Je lirai la doc , … après mes vacances
Actuellement nous passons par des redirection d’url et passage de
paramètres dans l’url.C’est en gros ça, avec des cookies en plus.
On sécurise un peu le tout en croisant les jetons de chaque coté (j’en
passe un au SSO qui me le renvoie avec le sien, spip contrôle le profil
en envoyant le jeton.Bin c’est à priori ce que fait CAS aussi, ça tombe bien…
Pour le coup on a réinventé la roue mais pas le temps alors de monter un websso et des méthode d’authentifications variés qui demandaient des connecteurs spécifiques, sachant très bien que cette partie était jetable.
Par contre elle nous a permis de voir les points d’entrés dans SPIP et définir le process de propagation à SPIP évoqué plus haut dans le post
L’objectif est aussi de voir si tous les points d’entrée ou de surcharge sont là pour pouvoir plugguer de l’authentification externe.
Pour l’instant ça passe pas trop mal, manque peut être un pipeline pour chainer proprement plusieurs méthode (actuellement il faut surcharger le spip_auth ou cousin pour ajouter une méthode de mémoire)
Sur ce bonsoir,
Plus d’infos d’ici fin mars environ, à suivre.
a+
Arnaud
Le 12/02/08, Gilles Vincent <gilles.vincent@gmail.com> a écrit :
2008/2/11 Arnaud Ventre <ventrea@gmail.com>:
…
On sécurise un peu le tout en croisant les jetons de chaque coté (j’en passe
un au SSO qui me le renvoie avec le sien, spip contrôle le profil en
envoyant le jeton.Il y a la librairie phpCAS qui fait cela très bien. Une piste pour ne
pas réinventer la roue, peut-être.
http://www.ja-sig.org/wiki/display/CASC/phpCAS
C’est cette librairie qui est utilisée par le plugin SPIP, de mémoire.
Tout à fait d’accord sur CAS
Dans le cas que j’évoque les méthode d’identification sont proprios et il fallait développer des connecteurs pour CAS ce qui entre autre nous coutait plus de temps que mettre en place cette mécanique. Pour simplifier le contexte projet faisait que la mécanique à mettre en place était forcément jetables.
A+
Arnaud
On sécurise un peu le tout en croisant les jetons de chaque coté (j'en
passe un au SSO qui me le renvoie avec le sien, spip contrôle le profil
en envoyant le jeton.Bin c'est à priori ce que fait CAS aussi, ça tombe bien...
Pour le coup on a réinventé la roue mais pas le temps alors de monter un websso et des méthode d'authentifications variés qui demandaient des connecteurs spécifiques, sachant très bien que cette partie était jetable.
OK
Par contre elle nous a permis de voir les points d'entrés dans SPIP et définir le process de propagation à SPIP évoqué plus haut dans le post
L'objectif est aussi de voir si tous les points d'entrée ou de surcharge sont là pour pouvoir plugguer de l'authentification externe.Pour l'instant ça passe pas trop mal, manque peut être un pipeline pour chainer proprement plusieurs méthode (actuellement il faut surcharger le spip_auth ou cousin pour ajouter une méthode de mémoire)
Oui, c'est le plus pénible. On en avait discuté il y a quelques semaines, avec l'idée éventuelle de sortir le support de LDAP de SPIP, et de rendre plus générique la surcharge de la méthode d'authentification pour pouvoir créer autant de plugins que l'on souhaite.
Il faudrait pour cela se concerter aussi avec le plugin OpenID.
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
