CAS
Configuration de CAS pour permettre l'authentification depuis une application AppScho
AppScho est en mesure d'utiliser votre CAS afin d'authentifier l'utilisateur, ainsi que récupérer certaines informations basiques sur son profil.
Les indications de configuration vont rester ici très abstraites car entièrement dépendantes des versions de CAS en question ainsi que les méthodes de déploiements utilises. Nous redirigerons, lorsque nécessaire, vers la documentation officielle d'Apereo.
Deux protocoles différents peuvent être utilisés afin de s'interfacer avec CAS.
Protocole REST
Le protocole REST proposé par CAS permet, à partir d'un nom d'utilisateur, un mot de passe et un service CAS, de récupérer deux éléments authentifiants pour l'utilisateur : un Ticket Granting Ticket (TGT) et un Service Ticket (ST).
Le renouvellement d'une session nécessite le renvoi du nom d'utilisateur et du mot de passe, nécessitant le stockage - sur le terminal de l'utilisateur - de ceux-ci.
Le TGT sert également à obtenir, lorsque l'utilisateur y a accès, des ST pour d'autres services qu'AppScho, permettant un transfert d'authentification transparent entre l'application mobile et des services Web présentés dans des webviews (détails à confirmer en fonction de l'implémentation).
Lien vers la Documentation CAS pour le Protocole REST: cliquez-ici
Les informations à fournir à AppScho sont :
L'adresse de votre instance CAS
Un nom de service CAS à utiliser
Protocole OpenID Connect
Ce protocole utilise le standard de l'industrie OpenID Connect afin d'autoriser l'utilisateur. Ici, l'authentification est présentée dans une webview, signifiant que les identifants ne sont jamais traités par AppScho directement.
Egalement, à l'issue d'une authentification réussie, un access token ainsi qu'un refresh token sont générés et fournis à l'application. Ce refresh token permet le renouvellement de la session utilisateur sans avoir à stocker ou réutiliser les identifiants.
Cette méthode fournit également un TGT qui permet de réaliser des transferts d'authentification.
Lien vers la Documentation CAS pour le Protocole OpenID Connect : cliquez-ici
AppScho doit vous fournir :
Service ID, de la forme
https://<id>.callback.oauth.appscho.com
Les informations à fournir à AppScho sont les suivantes :
Endpoint /authorize : https://cas.<nom_de_domaine>.fr/cas/oidc/authorize par exemple
Cet endpoint doit être accessible depuis n’importe quelle adresse IP car c’est l'étudiant qui y accède.
Client ID
Client secret
les éventuels Scopes et Claims à mettre en place côté AppScho
Un exemple de configuration d'un service CAS OpenID Connect peut ressembler, par exemple, à ceci (configuration à adapter à votre situation) :
{
"id": 1000,
"name": "AppScho",
"@class": "org.apereo.cas.services.OidcRegisteredService", "supportedGrantTypes": [
"java.util.HashSet",
[
"authorization_code",
"refresh_token"
]
],
"clientId": "appscho",
"clientSecret": "MjIwYjY1YzhhMzJjN2U3YmY3NTcwNDI3NzMxNWZjYzVhNDVlZTMyY=",
"serviceId": "^https://<id>.callback.oauth.appscho.com$",
"scopes": [
"java.util.HashSet",
[
"profile",
"email",
"offline_access"
]
]
}
Il est indispensable que CAS soit configuré pour à la fois émettre un refresh token et d'émettre un nouveau
refresh token régulièrement (pour éviter que les étudiants soient déconnectés à l'expiration de celui-ci).
Vous pouvez vous référer à la documentation de CAS pour votre version, mais cette page peut etre un bon point de départ, notamment les directives generateRefreshToken
et renewRefreshToken
.