Le SSO du PP !

[larose75]

bon ben c parti comme en l'an 40 !

(L'objectif est de permettre à terme de pouvoir utiliser tous les outils du Pp en ne s'identifiant qu'une seule fois)

des noms circulent :
openid
webId
browserid
oauth

Après avoir animé l'ektek, le débat a été utilement repris par la communauté PPux, et doit avancer vite car doit 'être porté à l'ordre du jour de la prochaine réunion ektek... début Janvier !

Je tâcherai de vous tenir régulièrement informé, mais bien sur, et pour ceux qui veulent être au coeur de l'action, rejoignez PPux !
http://ux-dev.piratesfr.org/about.html

[nka11]

Pour moi, en tant que normatif convaincu, le seul validé par W3C c'est WebId, c'est donc le standard du web, donc celui qu'il faut utiliser...

m'enfin ça n'engage que moi...

[eldy]

Par rapport aux applis qui ont besoin d'habilitations propres (cas de presque toutes les applications qui requiert un login/pass), il me semble souhaitable d'harmoniser d'abord les comptes, et je dirais même plus avoir une création de compte automatique.
Car on ne pourra jamais faire de lien entre un id d'un compte dans une appli et un provider de sécurité si le compte utilisateur n'existe pas dans l'appli. L'appli d'ailleurs refusera de fonctionner. Il faut donc commencer par la démarche de propagation des comptes avant de s'occuper de la problématique de suppression de la demande du mot de passe via un SSO.

Sinon pour la remarque d'unifier les roles (rmarques faites par mail dans la ML technique), je rejoins Nicolas, cela releve souvent de l'utopie car le découpage et la granularité de permission n'est jamais la meme entre appli. Avoir un modèle commun relève du casse tête. Mais pour certains cas simple, qui sait.

[larose75]

Qu'appelles tu "la démarche de propagation des comptes" ? stp...

[nka11]

L'harmonisation des comptes entre les outils et les circuits de création/suppression de users.

Pour ma part, vu la taille de l'équipe et les délais, je suis pour une approche plus "lazy" de la création des comptes :

Quand un utilisateur réclame un accès pour la première fois, son compte est crée dans l'Autorité Centrale (AC) et on lui donne son id (certificat webId ou autre forme d'auth).
tant que le user authentifié n'a pas utilisé tel outil, pas besoin d'y créer son compte, par contre, la première fois qu'il y va, récupération de ses infos au central pour lui créer un compte dans l'outil.

Naturellement, il faut prévoir pour chaque outil les autres cas d'utilisation (quand ce n'est pas un nouveau compte, et après la mise en place de l'AC) :

L'utilisateur a déjà un compte dans l'AC et souhaite y affilier son compte existant dans l"outil

L'utilisateur n'a pas de compte dans l'AC et souhaite obtenir un identifiant => creation d'une nouvelle identité dans l'AC puis creation en cascade dans l'outil.

L'utilisateur a un compte dans l'AC mais ne souhaite pas y affilier son compte existant => creation d'une nouvelle identité

L'utilisateur n'a pas de compte dans l'AC et et souhaite pas avoir une identié centralisée => création d'un compte dans l'outil seulement.

Avantage : On met d'abord en place l'AC (ce qui débloquera des projets) et on peut intégrer au fur et à mesure les outils et faisant les bonnes communications.
Inconvénients: ce n'est pas une synchro de liste, du coup faut gérer un circuit de départ, bien qu'un simple mapping dans chaque outil pourra redescendre au minimum le statut (adhérent ou non).
La question, c'est avec quoi on alimente l'AC au départ ?

la liste des adhérents (naturellement)

et par quel outil on commence l'intégration ?

liqdem ?
POUR: en plus faut le traiter automatiquement dans le circuit d'arrivée adhérent, donc on a un minimum de use cases à intégrer (juste le sso), et on assure la distribution des webid.
CONTRE: ça va être un tannée si liqdem prend une nouvelle barriere ergonomique ou un nouveau process à maitriser, il est déjà assez mal vu

sinon:

Forum ou autre, à débattre

Sinon, voici une liste non exhaustive des outils :

- un site spip national avec les comptes de ses rédacteurs (que des pirates)
- un forum (comptes pirates et non pirates)
- des sites de section locale plus ou moins homogène (que des pirates)
- un serveur de ml ouvert (comptes pirates et non pirates)
- et mumble (à part)
- plus des canaux irc (à priori non concernés sauf si on héberge un serveur ou qu'on fait tourner un pur bot pour un chan pp à identité vérifiées - hum... paradoxal)

et le redmine (que des pirates ?)

+ et les outils des trésoriers et autres métier back (secrétariat/gestion) dont je ne connais pas les détails (aurais-je entendu google apps), mais mettons les à part.

j'en oublie peut-être...
--
edit: cas d'utilisation supplémentaire

[nka11]

J'ajoute aussi qu'il pourrait être intéressant pour l'utilisateur de créer ou lier des comptes (dans certains outils) à des identités venant des réseaux sociaux ou autre plate-forme (facebook, google, twitter), voire de permettre des interactions (je pense notamment aux outils éditoriaux).

[Ferny]

BUMP !

salut les gars !
y a du neuf la dessus ?

[larose75]

Coucou

que du vieux
manque de ressources


on a a l'ektek une bande de joyeux lurons admin5 très compétents mais pour l'instant on veut avancer étape par étape
donc
1) architecture serveur - c fait
2) objectif court terme - fait
3) migration des services sur l'objectif - en cours
4) procédure de sauvegarde du Si du PP - en cours (et oui nous n'avons toujours pas de procédure de sauvegarde à ce jour)
5) plein d'autres trucs après dont le SSO qui nous tient particulièrement à coeur
et pendant ce temps les urgences courantes...

A+

[YannDutch]

Pu**** Larose!! T'étais passé où!!!? Ça fait un bail!! Je m'inquiétais!!

auto-modération

[larose75]

j'étais en wakanz et un poil malade, mais ca va mieux !
back to the business !