Configurer Apereo CAS pour exposer les groupes et rôles AD via OpenID Connect (OIDC)

Apereo CAS est une solution de Single Sign-On (SSO) largement utilisée dans les infrastructures d’entreprise et universitaires. Avec la montée en puissance d’OpenID Connect, de plus en plus d’applications nécessitent des informations supplémentaires sur l’utilisateur, telles que ses groupes d’appartenance (groups) ou son rôle (roles).

Dans cet article, nous allons voir comment configurer Apereo CAS (6.6+) pour exposer les attributs LDAP memberOf et eduPersonPrimaryAffiliation en tant que claims OIDC et comment tester manuellement la configuration pas à pas.

Pourquoi exposer les groupes et rôles via OIDC ?

Les applications modernes n’ont pas seulement besoin de savoir qui est l’utilisateur, mais aussi ce qu’il peut faire. Les attributs comme :

  • memberOf (groupes AD),
  • eduPersonPrimaryAffiliation (rôle ou affiliation : étudiant, staff, enseignant, etc.)

permettent de contrôler les autorisations côté application.
Exemple : afficher un tableau de bord administrateur uniquement pour les membres du groupe CN=Admins.

Configuration côté CAS

1. Récupération des attributs LDAP

Dans la section LDAP de CAS, ajoutez les attributs nécessaires et alias pour OIDC :

cas:
  authn:
    ldap:
      - order: 0
        name: Active Directory
        type: AUTHENTICATED
        ldap-url: ldaps://ldap.example.org:636
        base-dn: DC=example,DC=org
        subtree-search: true
        search-filter: (&(objectClass=person)(|(sAMAccountName={user})(mail={user})))
        principal-attribute-id: sAMAccountName
        principal-attribute-list: >
          sn,givenName,
          memberOf:groups,
          eduPersonPrimaryAffiliation:roles,
          mail:email,
          cn:name,
          sAMAccountName:uid
        allow-multiple-principal-attribute-values: true

2. Mappage des claims OIDC

Déclarez les mappings entre attributs LDAP et claims OIDC :

cas:
  oidc:
    core:
      issuer: https://cas.example.org/oidc
      claims-map:
        groups: memberOf
        roles: eduPersonPrimaryAffiliation
      user-defined-scopes:
        groups: groups
        roles: roles
    id-token:
      include-id-token-claims: true
    discovery:
      scopes: openid,profile,email,groups,roles
      claims: sub,name,preferred_username,email,groups,roles

Définition du service OIDC

Enfin, nous créons un service OIDC pour notre client (ici un tableau de bord nommé “Dashy”), avec un filtre d’accès basé sur un groupe AD :

{
  "@class": "org.apereo.cas.services.OidcRegisteredService",
  "clientId": "dashy-client",
  "serviceId": "^https://portail-dnsi\\.(test|prod)\\.exemple\\.local(/oauth/oidc/callback)?(\\?.*)?$",
  "evaluationOrder": 1,
  "name": "DASHY OIDC Service",
  "id": 10000011,
  "bypassApprovalPrompt": true,
  "accessStrategy": {
    "@class": "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy",
    "enabled": true,
    "ssoEnabled": true,
    "requireAllAttributes": false,
    "requiredAttributes": {
      "@class": "java.util.HashMap",
      "memberOf": ["java.util.HashSet", ["CN=IT-Admins,OU=GROUPES,DC=exemple,DC=local"]]
    },
    "caseInsensitive": false
  },
  "userProfileViewType": "FLAT",
  "supportedGrantTypes": ["java.util.HashSet", ["authorization_code"]],
  "supportedResponseTypes": ["java.util.HashSet", ["code"]],
  "scopes": ["java.util.HashSet", ["openid","profile","email","groups","roles"]],
  "includeClaimsInIdToken": true
}

Explications :

  • serviceId : expression régulière qui restreint les URLs pouvant utiliser ce client OIDC.
  • requiredAttributes : impose que l’utilisateur appartienne au groupe AD CN=IT-Admins pour accéder au service.
  • scopes : définit les scopes autorisés pour ce client.
  • includeClaimsInIdToken : indique que les claims doivent être inclus directement dans le token ID pour un traitement simplifié côté client.

Tester manuellement la configuration OIDC

Une fois la configuration terminée, il est crucial de tester le flux Authorization Code OIDC pour s’assurer que les claims sont bien renvoyés.

Étape 1 : Obtenir un code d’autorisation

Lancez un navigateur ou utilisez curl pour appeler l’endpoint oidcAuthorize :

https://cas.example.org/oidc/oidcAuthorize?
  client_id=my-client&
  response_type=code&
  redirect_uri=https%3A%2F%2Fapp.example.org%2Foauth%2Foidc%2Fcallback&
  scope=openid profile email groups roles&
  prompt=login

Vous serez redirigé vers l’URL de callback avec un code :

https://app.example.org/oauth/oidc/callback?code=OC-1-xxxxxxxxxxxxxxxx

Copiez ce code.

Étape 2 : Échanger le code contre un Access Token

Utilisez curl pour appeler l’endpoint oidcAccessToken :

curl -s -k -u 'my-client:my-secret' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=authorization_code&code=OC-1-xxxxxxxxxxxxxxxx&redirect_uri=https://app.example.org/oauth/oidc/callback' \
  'https://cas.example.org/oidc/oidcAccessToken' | tee /tmp/tokens.json | jq .

Vous obtiendrez un résultat similaire :

{
  "access_token": "AT-1-abc123xyz",
  "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVC...",
  "token_type": "Bearer",
  "expires_in": 28800,
  "scope": "groups email openid profile roles"
}

Étape 3 : Récupérer le profil utilisateur et vérifier les claims

Avec l’access_token, appelez l’endpoint oidcProfile :

curl -H "Authorization: Bearer AT-1-abc123xyz" \
  https://cas.example.org/oidc/profile | jq .

Vous devez voir un résultat incluant les groupes et rôles :

{
  "sub": "jdoe",
  "email": "[email protected]",
  "name": "John DOE",
  "groups": [
    "CN=Admins,OU=Groups,DC=example,DC=org",
    "CN=Developers,OU=Groups,DC=example,DC=org"
  ],
  "roles": "staff"
}

Bonnes pratiques

  • Vérifiez vos attributs LDAP avant de les mapper : un attribut inexistant renverra un warning dans les logs CAS.
  • Ajoutez roles et groups dans discovery.scopes pour que les clients puissent les demander dynamiquement.
  • Décoder l’ID Token avec jwt.io pour vérifier que les claims y figurent si vous utilisez include-id-token-claims: true.

Conclusion

Configurer Apereo CAS pour exposer les groupes et rôles via OIDC permet d’améliorer la sécurité et la gestion des autorisations de votre SI. Grâce à la configuration présentée ici et au test manuel pas à pas, vous êtes sûr de fournir aux applications clientes les informations dont elles ont besoin, sans exposer inutilement d’autres attributs LDAP.

🔧 À retenir :

  • Mapper memberOf → groups et eduPersonPrimaryAffiliation → roles.
  • Déclarer les scopes groups et roles dans la configuration CAS.
  • Tester manuellement le flux OIDC pour valider la configuration avant la mise en production.

Publications similaires