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.
Table of Contents
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: true2. 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,rolesDé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-Adminspour 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=loginVous serez redirigé vers l’URL de callback avec un code :
https://app.example.org/oauth/oidc/callback?code=OC-1-xxxxxxxxxxxxxxxxCopiez 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
rolesetgroupsdansdiscovery.scopespour 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→groupseteduPersonPrimaryAffiliation→roles. - Déclarer les scopes
groupsetrolesdans la configuration CAS. - Tester manuellement le flux OIDC pour valider la configuration avant la mise en production.
