Intégrer Dashy avec un serveur CAS et LDAP : gestion des rôles et des administrateurs via OIDC

Introduction

Associer Dashy, CAS et LDAP / Active Directory permet de bénéficier d’une authentification unique (SSO) tout en conservant un contrôle précis sur les rôles et les groupes utilisateurs.
Grâce à OpenID Connect (OIDC), il devient possible de déléguer entièrement la gestion des droits d’administration à votre annuaire d’entreprise.

Cet article explique comment :

  • exposer correctement les attributs LDAP dans CAS via OIDC,
  • configurer Dashy pour reconnaître automatiquement les administrateurs,
  • comprendre la logique exacte de adminRole et adminGroup.

⚙️ Architecture d’intégration

Utilisateur LDAP
      ↓
Authentification via CAS (OIDC)
      ↓
CAS expose les claims: roles + groups
      ↓
Dashy récupère le token OIDC
      ↓
Dashy applique adminRole / adminGroup

Configuration côté CAS (OIDC)

a) Exposition des attributs LDAP

Dans la configuration CAS, on mappe les attributs LDAP vers les claims OIDC utilisés par Dashy :

cas:
  authn:
    ldap:
      - name: Active Directory
        ldap-url: ldaps://ldap.example.com:636
        base-dn: DC=example,DC=com
        search-filter: (&(objectClass=person)(sAMAccountName={user}))
        principal-attribute-id: sAMAccountName
        principal-attribute-list: cn,mail,memberOf,eduPersonPrimaryAffiliation:roles
        allow-multiple-principal-attribute-values: true
  oidc:
    core:
      claims-map:
        groups: memberOf
        roles: eduPersonPrimaryAffiliation
    id-token:
      include-id-token-claims: true
    discovery:
      scopes: openid,profile,email,groups,roles

Cette configuration garantit que :

  • memberOf (groupes LDAP) est exposé comme claim groups,
  • eduPersonPrimaryAffiliation (rôle principal) est exposé comme claim roles.

b) Déclaration du client OIDC CAS

Chaque service OIDC doit être défini dans un fichier JSON :

{
  "@class": "org.apereo.cas.services.OidcRegisteredService",
  "clientId": "dashy-client",
  "serviceId": "^https://dashy.example.com(/oauth/oidc/callback)?(\\?.*)?$",
  "name": "Dashy OIDC Service",
  "id": 100001,
  "scopes": ["java.util.HashSet", ["openid", "profile", "email", "groups", "roles"]],
  "includeClaimsInIdToken": true,
  "attributeReleasePolicy": {
    "@class": "org.apereo.cas.services.ReturnMappedAttributeReleasePolicy",
    "allowedAttributes": {
      "@class": "java.util.LinkedHashMap",
      "groups": "memberOf",
      "roles": "eduPersonPrimaryAffiliation"
    }
  }
}

Le token renvoyé à Dashy contiendra par exemple :

{
  "sub": "jdupont",
  "email": "[email protected]",
  "roles": ["staff"],
  "groups": ["IT-Admin", "Intranet-Users"]
}

Configuration côté Dashy

Dashy prend en charge OIDC nativement.
Il suffit d’ajouter la configuration suivante dans conf.yml :

auth:
  oidc:
    clientId: dashy-client
    endpoint: https://cas.example.com/cas/oidc
    scope: "openid profile email groups roles"
    adminRole: "staff"
    adminGroup: "IT-Admin"

Comment Dashy détermine un administrateur

Le code interne de Dashy vérifie la présence de adminRole ou adminGroup dans les claims OIDC :

const isAdmin =
  (Array.isArray(groups) && groups.includes(this.adminGroup)) ||
  (Array.isArray(roles) && roles.includes(this.adminRole)) ||
  false;

Cela signifie que :

  • roles et groups doivent être transmis sous forme de tableaux JSON (["staff"], ["IT-Admin"], etc.) ;
  • la comparaison est sensible à la casse et doit correspondre exactement à la valeur du claim renvoyé par CAS ;
  • la logique est un OU logique : il suffit d’avoir l’un des deux pour devenir administrateur.

Vérification et débogage

Pour vérifier que les attributs sont correctement transmis :

a) Depuis la console du navigateur

  1. Ouvrir les outils de développement (F12 → onglet Console)
  2. Exécuter : JSON.parse(localStorage.getItem('keycloakInfo'))
    Dashy stocke ici les informations OIDC du dernier utilisateur connecté.

b) Exemple de résultat attendu

{
  "email": "[email protected]",
  "roles": ["staff"],
  "groups": ["IT-Admin", "Intranet-Users"]
}

Si les attributs ne sont pas sous forme de tableau ("roles": "staff" au lieu de "roles": ["staff"]), Dashy ne reconnaîtra pas correctement les droits administratifs.

✅ Résultat

Un utilisateur appartenant au groupe "IT-Admin" ou disposant du rôle "staff" devient automatiquement administrateur Dashy après authentification CAS.

🧩 Points clés à retenir

ÉlémentDescription
adminRoleCorrespond au claim roles du token OIDC
adminGroupCorrespond au claim groups du token OIDC
Type attenduTableau (["staff"], ["IT-Admin"])
Condition d’activationOU logique (adminRole ou adminGroup)
DébogageVia localStorage.keycloakInfo dans la console

💬 Conclusion

L’intégration de Dashy avec un serveur CAS / LDAP via OIDC permet une authentification centralisée et une gestion des droits cohérente avec votre annuaire.
La combinaison de adminRole et adminGroup offre un contrôle fin et flexible, tout en maintenant la simplicité de gestion des comptes.

🔎 Mots-clés SEO

Dashy, CAS, OIDC, LDAP, Active Directory, SSO, OpenID Connect, CAS OIDC, Dashy OIDC, authentification unique, adminRole, adminGroup, roles, groups, Dashy configuration, CAS integration, identity provider.

Publications similaires