Derniers messages
Dernier message par Rollniak - Hier à 10:24:53
Cliquez pour afficher le message
Bonjour tout le monde 
@Shepeng me fait penser que l'on doit bien définir nos besoins pour choisir par la suite le bon outil.
Est-ce que le périmètre s'applique uniquement au services web ou aussi au machines (container LXC, machines virtuelles, Hyperviseurs) ?
Il est question de multi-domaine, donc ça exclut FreeIPA que je connais le mieux pour l'avoir utilisé (Non administré) en entreprise.
Concernant les profiles, j'imagine que les informations suivantes sont importantes :
Pour le mail, je pense que ça dépends, la seul utilité que je voie c'est pour des applications qui ne supporte que l'authentification avec un é-mails ou si un serveur é-mail utilise LDAP pour l'authentification et obtenir la liste des é-mails valides.
Pour les groupes on pourrais réfléchir au accès en suivant le principe de de moindre privilège. Les admins on certains accès, les devs on des accès plus restreint suivant leurs besoins est ainsi de suite.
Je pense que 0auth peut être vue plus tard une fois que la configuration LDAP est terminé.
@Shepeng me fait penser que l'on doit bien définir nos besoins pour choisir par la suite le bon outil.
Est-ce que le périmètre s'applique uniquement au services web ou aussi au machines (container LXC, machines virtuelles, Hyperviseurs) ?
Il est question de multi-domaine, donc ça exclut FreeIPA que je connais le mieux pour l'avoir utilisé (Non administré) en entreprise.
Concernant les profiles, j'imagine que les informations suivantes sont importantes :
- Nom Affiché
- mot de passe
- identifiant
- uid (Je crois que la valeurs de départ doit être haute pour pas empiéter sur des comptes existant dans le cas ou le LDAP est utilisé pour s'authentifier sur des machines)
- L'avatar est un plus optionnel
- Les préférences dépendes du support des applications utilisé par nos services, ça peut être vue au cas par cas.
Pour le mail, je pense que ça dépends, la seul utilité que je voie c'est pour des applications qui ne supporte que l'authentification avec un é-mails ou si un serveur é-mail utilise LDAP pour l'authentification et obtenir la liste des é-mails valides.
Pour les groupes on pourrais réfléchir au accès en suivant le principe de de moindre privilège. Les admins on certains accès, les devs on des accès plus restreint suivant leurs besoins est ainsi de suite.
Je pense que 0auth peut être vue plus tard une fois que la configuration LDAP est terminé.
Dernier message par shepeng - Hier à 09:24:52
Cliquez pour afficher le message
Mes premières idées en vrac.
Est-ce que LLDAP permet de faire plusieurs arborescences, d'avoir plusieurs racines ?
Si oui, ton problème de sous groupes est réglé. Si non, et si tu veux vraiment séparer les entités, il faut passer à autre chose, pour avoir une racine par entité.
Ce qui donne les fonctionnalités à LDAP, ce sont les schémas que l'on ajoute. Il faut à mon avis déjà penser à l'implémentation 0Auth ou autre mécanisme de connexion internet et voir quels schémas sobnt nécessaires.
Si tu veux intégrer les avatars, il faudra également trouver un schéma le contenant. Le schéma posix contient une éventuelle photo, mais ce n'est pas vraiment le même chose.
Est-ce que LLDAP permet de faire plusieurs arborescences, d'avoir plusieurs racines ?
Si oui, ton problème de sous groupes est réglé. Si non, et si tu veux vraiment séparer les entités, il faut passer à autre chose, pour avoir une racine par entité.
Ce qui donne les fonctionnalités à LDAP, ce sont les schémas que l'on ajoute. Il faut à mon avis déjà penser à l'implémentation 0Auth ou autre mécanisme de connexion internet et voir quels schémas sobnt nécessaires.
Si tu veux intégrer les avatars, il faudra également trouver un schéma le contenant. Le schéma posix contient une éventuelle photo, mais ce n'est pas vraiment le même chose.
Dernier message par Zatalyz - Hier à 08:52:47
Cliquez pour afficher le message
Pendant que j'y suis (et que je suis plus réveillée), je me questionne un peu sur le logiciel que j'utilise, LLDAP, qui est hyper basique, peut-être trop. En gros il n'y a que les utilisatrices, et les groupes, sans possibilité de faire des sous-groupes. Et je me dis que quand j'aurais 10 asso/organisations ça va être lourd de ne pas pouvoir juste cibler les groupes d'une asso. Mais ce n'est peut-être pas si grave, suffit que je préfixe par le nom de l'asso. L'autre solution est de passer à OpenLDAP, qui est assez effrayant mais plus complet.
Votre avis ?
Votre avis ?
Dernier message par Zatalyz - 02 Décembre 2024 à 22:50:56
Cliquez pour afficher le message
J'ai oublié de poser clairement ma demande...
Donc :
- donnez votre avis sur ce que vous voulez voir dans "profil" (et si ça doit être vu juste par vous et les personnes avec assez de droits, ou si tous les membres connectés peuvent le voir)
- listez-moi les divers groupes qui vous semblent utiles.
- et pour les groupes, listez aussi si au delà du nom et de la description, vous voyez d'autres infos utiles à afficher.
Donc :
- donnez votre avis sur ce que vous voulez voir dans "profil" (et si ça doit être vu juste par vous et les personnes avec assez de droits, ou si tous les membres connectés peuvent le voir)
- listez-moi les divers groupes qui vous semblent utiles.
- et pour les groupes, listez aussi si au delà du nom et de la description, vous voyez d'autres infos utiles à afficher.
Dernier message par Zatalyz - 02 Décembre 2024 à 22:46:44
Cliquez pour afficher le message
Salut 
Je suis en train de me replonger dans l'authentification unifiée. Et je me questionne un peu sur l'organisation à donner à ça. Je vais essayer d'expliquer, mais 1) c'est pas un sujet trivial et 2) vu que personne n'est expert, vous êtes toutes aptes à me donner votre avis.
Cette affaire d'authentification unifiée passe par deux étapes : primo, avoir un seul identifiant/mot de passe pour l'ensemble de nos services. Histoire que quand on change son mot de passe, on n'aie pas besoin de le faire 10 fois de suite (sur le wiki, le forum, le cloud, etc...). Secundo, que quand on se connecte, on le soit partout (sans devoir se connecter une fois sur le wiki, une autre sur le forum, une autre sur... enfin vous avez l'idée).
Là j'en suis à l'étape alpha 1. C'est à dire que je met en place de quoi avoir un seul identifiant partout, mais on n'en est même pas encore à ce que vous puissiez créer un compte et changer le mot de passe
Pour la petite histoire de Mage, j'utilise LDAP. Et LDAP c'est un peu comme le croisement entre les entités du subespace et l'enfer de Bosch. Mais j'ai mes raisons, promis. Osef de la technologie, ce qui compte c'est : comment je structure mes données. Et LDAP a une réponse digne du Necronomicon là-dessus: "c'est comme tu veux, ou presque". Je peux me charger du "presque", mais "comme je veux", c'est hyper difficile.
Breeeef. LDAP ne sert pas qu'à Khaganat, mais aussi à Numenaute et aux diverses assos et groupes hébergés par Numenaute. Et c'est l'asso Rapaton qui héberge Numenaute. Mais du coup j'imagine que tout va être sous le nom "numenaute" (dont Rapaton). Là déjà on a commencé à penser en géométrie non-euclidienne
En gros : quand on se connectera à Khaganat, cela demanderais de le faire sur auth.numenaute.org. J'imagine qu'à l'étape 2 je pourrais peut-être le cacher un peu, mais sans certitude, et pour celles d'entre vous qui regardent les noms de domaines appelés, ça voudra dire qu'à un moment "numenaute" sera appelé façon CDN sur Khaganat.
Je ne vois pas trop comment faire autrement, je ne vais pas maintenir un annuaire par asso...
Ensuite au niveau de l'arbre, ça va être presque sans douleur. Il y aura le groupe des utilisatrices, qui aura touuuut le monde. Et des groupes variés, j'y reviens plus tard.
Concernant les utilisatrices, en dehors des groupes dont elles font partie, quelles informations voulez-vous avoir de base dans le profil ? Je pense mettre ce qui suit, et je le soumet à vos avis.
Obligatoire :
- Pseudo (nom affiché)
- mail
- mot de passe, logique...
- identifiant (qui peut être différent du nom affiché, parce que c'est plus rapide de se connecter avec "zatalyz" qu'avec "Prêtresse de la Propagande".
- uid, ça c'est pour la machine, elle se débrouille toute seule.
Pas obligatoire mais peut être utile ?
- Avatar
- Nom et prénom (pour celles qui sont membres des assos)
- sans doute que je pourrais permettre là de sélectionner ses préférences en terme de langue et de thème (sombre/clair) mais je doute que les cms supportent vraiment ça.
En vrai je ne sais même pas si stocker les noms et prénoms est une bonne idée ; chaque asso peut se débrouiller pour faire le lien entre pseudo et nom civil (chacun son rgpd !). Et sinon il y a peut-être d'autres champs que vous aimeriez avoir dans un profil générique, qui pourra (au choix) être visible par la suite aux autres, suivant leurs droits (genre : vos sites web ?).
La partie qui suit me questionne aussi pas mal, ce sont les groupes, et là on est plus propre à Khaganat (chaque structure va devoir le faire...). Je précise : les groupes qui vont donner accès à des droits différents. Par exemple sur Khaganat il me semble logique d'avoir les groupes suivants : collège, membre sauf comment on appelle les membres de Khaganat mais pas de l'asso ? et comment on différencie de ceux de l'asso ? Et après il y a des groupes déjà sur le forum, les dokuwiki, la forge etc... haaaaargh. Aidez moi à faire cette liste
Je ne sais pas du tout si tous nos cms vont prendre ces groupes en compte pour les accès aux droits de lecture/écriture, mais je crois qu'il faut partir dans l'optique que "ouais". Et je sens que je vais bien rigoler quand je vais interfacer les trucs.
Je suis en train de me replonger dans l'authentification unifiée. Et je me questionne un peu sur l'organisation à donner à ça. Je vais essayer d'expliquer, mais 1) c'est pas un sujet trivial et 2) vu que personne n'est expert, vous êtes toutes aptes à me donner votre avis.
Cette affaire d'authentification unifiée passe par deux étapes : primo, avoir un seul identifiant/mot de passe pour l'ensemble de nos services. Histoire que quand on change son mot de passe, on n'aie pas besoin de le faire 10 fois de suite (sur le wiki, le forum, le cloud, etc...). Secundo, que quand on se connecte, on le soit partout (sans devoir se connecter une fois sur le wiki, une autre sur le forum, une autre sur... enfin vous avez l'idée).
Là j'en suis à l'étape alpha 1. C'est à dire que je met en place de quoi avoir un seul identifiant partout, mais on n'en est même pas encore à ce que vous puissiez créer un compte et changer le mot de passe
Pour la petite histoire de Mage, j'utilise LDAP. Et LDAP c'est un peu comme le croisement entre les entités du subespace et l'enfer de Bosch. Mais j'ai mes raisons, promis. Osef de la technologie, ce qui compte c'est : comment je structure mes données. Et LDAP a une réponse digne du Necronomicon là-dessus: "c'est comme tu veux, ou presque". Je peux me charger du "presque", mais "comme je veux", c'est hyper difficile.
Breeeef. LDAP ne sert pas qu'à Khaganat, mais aussi à Numenaute et aux diverses assos et groupes hébergés par Numenaute. Et c'est l'asso Rapaton qui héberge Numenaute. Mais du coup j'imagine que tout va être sous le nom "numenaute" (dont Rapaton). Là déjà on a commencé à penser en géométrie non-euclidienne
En gros : quand on se connectera à Khaganat, cela demanderais de le faire sur auth.numenaute.org. J'imagine qu'à l'étape 2 je pourrais peut-être le cacher un peu, mais sans certitude, et pour celles d'entre vous qui regardent les noms de domaines appelés, ça voudra dire qu'à un moment "numenaute" sera appelé façon CDN sur Khaganat.
Je ne vois pas trop comment faire autrement, je ne vais pas maintenir un annuaire par asso...
Ensuite au niveau de l'arbre, ça va être presque sans douleur. Il y aura le groupe des utilisatrices, qui aura touuuut le monde. Et des groupes variés, j'y reviens plus tard.
Concernant les utilisatrices, en dehors des groupes dont elles font partie, quelles informations voulez-vous avoir de base dans le profil ? Je pense mettre ce qui suit, et je le soumet à vos avis.
Obligatoire :
- Pseudo (nom affiché)
- mot de passe, logique...
- identifiant (qui peut être différent du nom affiché, parce que c'est plus rapide de se connecter avec "zatalyz" qu'avec "Prêtresse de la Propagande".
- uid, ça c'est pour la machine, elle se débrouille toute seule.
Pas obligatoire mais peut être utile ?
- Avatar
- Nom et prénom (pour celles qui sont membres des assos)
- sans doute que je pourrais permettre là de sélectionner ses préférences en terme de langue et de thème (sombre/clair) mais je doute que les cms supportent vraiment ça.
En vrai je ne sais même pas si stocker les noms et prénoms est une bonne idée ; chaque asso peut se débrouiller pour faire le lien entre pseudo et nom civil (chacun son rgpd !). Et sinon il y a peut-être d'autres champs que vous aimeriez avoir dans un profil générique, qui pourra (au choix) être visible par la suite aux autres, suivant leurs droits (genre : vos sites web ?).
La partie qui suit me questionne aussi pas mal, ce sont les groupes, et là on est plus propre à Khaganat (chaque structure va devoir le faire...). Je précise : les groupes qui vont donner accès à des droits différents. Par exemple sur Khaganat il me semble logique d'avoir les groupes suivants : collège, membre sauf comment on appelle les membres de Khaganat mais pas de l'asso ? et comment on différencie de ceux de l'asso ? Et après il y a des groupes déjà sur le forum, les dokuwiki, la forge etc... haaaaargh. Aidez moi à faire cette liste
Je ne sais pas du tout si tous nos cms vont prendre ces groupes en compte pour les accès aux droits de lecture/écriture, mais je crois qu'il faut partir dans l'optique que "ouais". Et je sens que je vais bien rigoler quand je vais interfacer les trucs.
Dernier message par deed - 24 Septembre 2023 à 15:48:18
Cliquez pour afficher le message
j'ai des super noms:
- deedInTheBest3D
- deedIsTheWorld3D
- spofu3D, lirria3D, tepsne3D
- theWorldfromDeed3D
- dreamWorld3D
- rêve3D
- deedInTheBest3D
- deedIsTheWorld3D
- spofu3D, lirria3D, tepsne3D
- theWorldfromDeed3D
- dreamWorld3D
- rêve3D
Dernier message par Zatalyz - 24 Septembre 2023 à 15:23:53
Cliquez pour afficher le message
3d en lojban ? de mémoire "cidy" ? Ça claque en plus le client "Cidy". Bon après ptet pas assez parlant ? "Cidy - Client 3D Khanat" ?
Dernier message par YannK - 24 Septembre 2023 à 14:56:49
Cliquez pour afficher le message
Bon, on va s'y (re)mettre, qu'en dites-vous ? Mais il faut trouver un nom pour le dépôt avant tout, et je commence à sécher après en avoir recréé plusieurs à la suite. Je vais archiver Khanat client et je me disais qu'on devrait lui donner un nom comprenant « 3D » pour spécifier que ce sera celui du client 3D. Ça ferait « Client 3D Khanat ». Mais je trouve ça un peu... plat.
Ça vous irait ? Vous avez d'autres idées/suggestions ?
Ça vous irait ? Vous avez d'autres idées/suggestions ?
Dernier message par Zatalyz - 02 Août 2023 à 10:05:35
Cliquez pour afficher le message
Bonjour,
Petite proposition d'ajout pour notre client de base : la possibilité de se "téléporter" sur les divers points de la map, afin de rapidement contrôler tel et tel point (par exemple, les trucs liés à l'eau).
Ce que je propose, une fenêtre avec les options suivantes :
- pouvoir afficher ses coordonnées sur la carte
- pouvoir poser un POI qui sera enregistré en local (pour quand on fait des tests soi-même) ET qu'on peut pousser sur le serveur (pour inviter les autres à regarder le même test)
- liste des POI partagés et locaux ; cliquer sur l'un permet de s'y téléporter (après une fenêtre de confirmation).
- se téléporter sur des coordonnées (pour dire à quelqu'un "va à X-Y-Z" tant qu'on n'a pas de serveur).
L'idée est posée "comme ça", ça méritera sans doute que je développe avec une proposition sur l'interface... Mais c'est noté !
Par la suite, ce sera intéressant de laisser la fonctionnalité mais uniquement accessible en ayant certains droits. Sur le serveur, se téléporter sera réservé aux devs, certains modérateurs...
Petite proposition d'ajout pour notre client de base : la possibilité de se "téléporter" sur les divers points de la map, afin de rapidement contrôler tel et tel point (par exemple, les trucs liés à l'eau).
Ce que je propose, une fenêtre avec les options suivantes :
- pouvoir afficher ses coordonnées sur la carte
- pouvoir poser un POI qui sera enregistré en local (pour quand on fait des tests soi-même) ET qu'on peut pousser sur le serveur (pour inviter les autres à regarder le même test)
- liste des POI partagés et locaux ; cliquer sur l'un permet de s'y téléporter (après une fenêtre de confirmation).
- se téléporter sur des coordonnées (pour dire à quelqu'un "va à X-Y-Z" tant qu'on n'a pas de serveur).
L'idée est posée "comme ça", ça méritera sans doute que je développe avec une proposition sur l'interface... Mais c'est noté !
Par la suite, ce sera intéressant de laisser la fonctionnalité mais uniquement accessible en ayant certains droits. Sur le serveur, se téléporter sera réservé aux devs, certains modérateurs...
Dernier message par aleajactaest - 26 Juillet 2023 à 23:07:05
Cliquez pour afficher le message
Comparaison entre un accès sur un service unique et un accès sur plusieurs services
Accès Service Unique:
* Avantage:
- Simplification sur la gestion de la sécurité
* Inconvenient:
- Tout passe par le service frontal
- En cas de crash du frontal, on peut tout
- Illusion de sécurité (dans les faits si on case le frontal, on a accès à tout)
- Ajout de la latence (effet entonoire, le débit max est régit par le service frontal)
Accès Multi-Service:
* Avantage:
- Plus de redondance
- Repartition de la charge
* Inconvenient:
- Complexifie de la gestion de la sécurité
A prévoir:
- une mise à jour de Firewall en dynamique pour autoriser l'IP des joueurs sur le service attribué.
- Service auhtentification : seul service ouvert si non authentifié
- Service dédié pour savoir quels sont les services disponible pour le joueur (permettre de basculer rapidement et de ne pas intérroger le service authentification qui est ouvert à tous)
PS.:
Fichier PlantUML pour ceux qu'ils veulent reprendre et améliorer.
view-network.txt
Accès Service Unique:
* Avantage:
- Simplification sur la gestion de la sécurité
* Inconvenient:
- Tout passe par le service frontal
- En cas de crash du frontal, on peut tout
- Illusion de sécurité (dans les faits si on case le frontal, on a accès à tout)
- Ajout de la latence (effet entonoire, le débit max est régit par le service frontal)
Accès Multi-Service:
* Avantage:
- Plus de redondance
- Repartition de la charge
* Inconvenient:
- Complexifie de la gestion de la sécurité
A prévoir:
- une mise à jour de Firewall en dynamique pour autoriser l'IP des joueurs sur le service attribué.
- Service auhtentification : seul service ouvert si non authentifié
- Service dédié pour savoir quels sont les services disponible pour le joueur (permettre de basculer rapidement et de ne pas intérroger le service authentification qui est ouvert à tous)
PS.:
Fichier PlantUML pour ceux qu'ils veulent reprendre et améliorer.
view-network.txt
