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ément authentifiant 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).

Les informations à fournir à AppScho sont :

  • l'adresse votre instance de 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.

Ici, les informations à fournir à AppScho sont les suivantes :

  • Client ID

  • Client secret

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.

Last updated