Comptes utilisateur

La gestion des comptes utilisateurs dans MyDMAM est totalement intégré. Il est possible de déclarer des serveurs Windows Active Directory pour permettre de lui déléguer la gestion des logins/mot de passe et groupes, et ce sur plusieurs domaines en plus des comptes locaux.

Le stockage des comptes et de leurs droits (groupes, rôles et privilèges), qu’ils soit locaux ou via Active Directory se fait dans Cassandra. Dans le cadre comptes locaux, les mots de passe y sont stockés après y avoir été salés (bcrypt) et chiffrés (AES).

Toutes les instances du serveur web de MyDMAM connectés sur la même base Cassandra (et le même keyspace) auront accès aux mêmes comptes. De puis, si vous connectez toutes vos instances sur le même moteur de cache (memcached) vous pouvez faire de la haute disponibilité.

Au premier lancement du moteur de gestion de compte, qui se fait au moment ou le serveur web démarre, il y a plusieurs vérification, comme la présence d’un compte admin, et de ses droits. Le moteur le créé si besoin. Un mot de passe lui sera alors généré à la volée et se trouvera dans un fichier texte créé automatiquement à la racine de MyDMAM (il est conseillé de supprimer ce fichier après avoir récupéré le mot de passe, un message d’alerte dans le log le rappel).

Pour info, bien que moteur de backend de compte utilise LDAP, seul Active Directory est pris en charge, pour le moment. NTLM et SSO ne sont pas implémentés.

La configuration des backends se fait dans le fichier conf/app.d/play.yml. La gestion des comptes se fait dans l’interface web.

La création d’un nouveau compte local se fait dans l’interface web. Il n’y a pas de process de synchronisation entre les backend et les comptes de MyDMAM. Si un utilisateur du domaine est reconnu, MyDMAM lui crée un compte avec les groupes qui lui sont associés dans le backend (LDAP/AD). Si ces groupes ont des droits, il en héritera. Dans tous les cas, il aura des droits du groupe “New users”. Cela permet à l’administrateur de prédéfinir des droits par défaut “de base”. Ou rien. Dans ce cas l’utilisateur pourra que quitter sa session.

La structure prévoit :

  • Autant de groupes que l’on veux par utilisateurs. Pas de distinction entre les groupes LDAP/AD et les groupes locaux.
  • Autant de rôles que l’on veux par groupes.
  • Le même rôle peut être attribué à plusieurs groupes.
  • Les privilèges sont liés aux contrôleurs web du serveur. L’administrateur peut visualiser les actions de ces contrôleurs par privilege.
  • On attribue des privilèges aux rôles.
  • L’utilisateur est limité dans ses actions par rapport à tous ses privileges. A chacune de ses requêtes le serveur vérifie qu’il est en mesure de le faire. Si il fabrique des requêtes “spéciale” qui ne lui sont pas permise, il se fera jeter.

Le serveur, à chaque lancement, vérifie que l’admin à bien tout les privilèges.

Les Privilèges sont vérifiés au niveau des contrôleurs @With(Secure.class) et @Check("le_privilège"), dans les vues et injecté dans des variables JS pour que les fonctions ajax suivent ces droits.

L’option de configuration force_select_domain dans play de la configuration de MyDMAM permet de demander à un utilisateur de choisir son backend pour se connecter. Cela simplifie l’appel à de multiples backends et accélère l’authentification, et évite trop de messages de log d’erreurs.