Consommer services via CLI ou Desktop application
Consommation de services from native apps (e.g. CLI, Desktop application, ...)
Identifiant
- Pôle: THEIA
- Contact: Rémi Cresson
Participants
- 1 service quelconque: SVC
- 1 instance keycloak: SSO
- 1 client logiciel (par exemple une CLI ou une destkop application): CLI
- 1 utilisateur qui utilise le client: USR
Pré-requis
- L'utilisateur est authentifié et autorisé à accèder au service
Description
Ce use case présente l'accès à un service par une application non web. Il présente le device authorization flow. Ce flow pourrait être rencontré dans THEIA typiquement pour permettre à des applications desktop comme QGIS (logiciel de SIG) ou à des CLI (par exemple des codes qui tournent sur un cluster de calcul) pas nécessairement équipés de web browser, à consommer des services d'accès aux images (services nécessitant que user soit authentifié et autorisé).
Nous avons fait des tests concluant avec keycloak et des librairies python maison qui s'appuient sur requests
. C'est un peu le même principe qui est mis en oeuvre par ex. par les apple TV ou netflix. Typiquement: vous êtes à l'hôtel, vous voulez regarder votre série, mais vous n'allez pas entrer vos credentials sur la box de l'hotel mais sur votre smartphone (en flashant un qr code par ex.)
sequenceDiagram
participant USR
participant CLI
participant SSO
participant SVC
USR->>CLI: Clic on "connect to remote service"
CLI->>SSO: POST http://<device_endpoint>
SSO->>CLI: verification_uri + user_code OR verification_uri_complete, device_code, polling_interval
CLI->>USR: "Open this link to your browser to authenticate" (or QR code)
USR-->>SSO: Connects with a web browser
loop Polling
CLI->>SSO: POST http://<token_endpoint> (until HTTP 200, stops after polling_interval reached)
end
SSO-->>CLI: if OK: access_token + refresh_token + expires_in
CLI-->>USR: "Now you can use the service!"
USR->>CLI: Clic on "Process some remote data"
CLI->>SVC: HTTP GET/POST/DELETE/.../etc (with access_token in requests payload)
SVC->>SSO: POST http://<introspect_endpoint>
SSO->>SVC: HTTP 200
SVC-->>CLI: Some processed remote data
CLI->>USR: "Success. Here is the result"
Fins possibles?
Si l'user est authentifié et autorisé, il peut utiliser le service avec le client cli ou desktop. Son token parviendra au service, qui vérifiera auprès du SSO sa validité, et lira les attributs du user, pour en déduire si il est autorisé ou non.
Points vitaux vis-à-vis de l'authentification
L'utilisateur doit être muni d'un navigateur web qui peut être installé sur un device différent de celui sur lequel il cherche à utiliser le service via le client cli/desktop
Use-cases associés
- #2 (on doit pouvoir utiliser les services depuis un client web OU un client natif, c'est important)
Notes
Question
- Est-il possible de généraliser cette approche pour manager plusieurs sessions? Par exemple un utilisateur lance un traitement sur N noeuds (dans un cloud ou un cluster HPC) et il souhaite manager l'ensemble des sessions, par opposition à valider chaque session sur 1 nœud individuellement.
Références