OK alors tel que tu le décris, dans un contexte OAuth2 (ou OIDC ca marche aussi), ca m'a l'air de ressembler à ca:
L'appli A est un service web qui utilise des access_token pour authentifier les accès pour envoyer ses données via une requête HTTP REST.
Comment l'appli A récupère ses données et comment elle les stocke est hors scope du problème.
Il existe plusieurs applis A différentes qu'on va appeler A1, A2, A3, etc. Le nombre de A varie dans le temps.
L'appli C est un client OAuth2, celle-ci va chercher un access_token au nom d'un utilisateur connecté pour aller faire des requêtes sur l'appli A
L'appli C doit être préalablement inscrite sur le serveur OAuth2 pour être autorisée à aller chercher des access tokens, mais c'est moins grave parce que le nombre de C m'a l'air moins variable que le nombre de A.
Glewlwyd utilise des JWT comme access_token, ce qui permet à A de valider la validité des access tokens tout seul, en validant la signature dudit JWT.
Si tu veux que l'utilisateur donne explicitement son consentement à C l'autorisation d'accéder aux applis A, il faut assigner à chaque A un scope différent, ce qui permettra dans Glewlwyd d'avoir des access_token pour un ensemble de scopes correspondant à ceux autorisés par l'utilisateur pour le client.
Tu peux créer dans le serveur OAuth2 un grand nombre de scopes pour permettre aux nouveaux A qui arrivent dans la fédération de se voir assigner un scope que pour lui.
Faut comprendre que dans ce que je viens de décrire, les A ne s'authentifient pas ni n'authentifient personne. Ils se contentent de fournir des données à un client C qui a un access_token valide, c'est à dire avec une signature et un scope valides.
Aussi, le serveur OAuth2 est seul donc un joyeux SPOF (single point of failure). Tu peux contourner ca en prévoyant plusieurs serveurs OAuth2 qui partageront la même configuration ce qui leur permettra de fournir des access tokens compatibles, mais il faudra permettre à C de connaitre l'ensemble de serveurs OAuth2 disponibles.
Mathieu a mentionné UMA, ca peut aussi répondre à ton problème mais je ne connais pas.
[^] # Re: SSO et autorisation en mode fédéré : possible ?
Posté par Babelouest (site web personnel) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 2.
OK alors tel que tu le décris, dans un contexte OAuth2 (ou OIDC ca marche aussi), ca m'a l'air de ressembler à ca:
L'appli A est un service web qui utilise des
access_tokenpour authentifier les accès pour envoyer ses données via une requête HTTP REST.Comment l'appli A récupère ses données et comment elle les stocke est hors scope du problème.
Il existe plusieurs applis A différentes qu'on va appeler A1, A2, A3, etc. Le nombre de A varie dans le temps.
L'appli C est un client OAuth2, celle-ci va chercher un access_token au nom d'un utilisateur connecté pour aller faire des requêtes sur l'appli A
L'appli C doit être préalablement inscrite sur le serveur OAuth2 pour être autorisée à aller chercher des access tokens, mais c'est moins grave parce que le nombre de C m'a l'air moins variable que le nombre de A.
Glewlwyd utilise des JWT comme
access_token, ce qui permet à A de valider la validité des access tokens tout seul, en validant la signature dudit JWT.Si tu veux que l'utilisateur donne explicitement son consentement à C l'autorisation d'accéder aux applis A, il faut assigner à chaque A un scope différent, ce qui permettra dans Glewlwyd d'avoir des
access_tokenpour un ensemble de scopes correspondant à ceux autorisés par l'utilisateur pour le client.Tu peux créer dans le serveur OAuth2 un grand nombre de scopes pour permettre aux nouveaux A qui arrivent dans la fédération de se voir assigner un scope que pour lui.
Faut comprendre que dans ce que je viens de décrire, les A ne s'authentifient pas ni n'authentifient personne. Ils se contentent de fournir des données à un client C qui a un
access_tokenvalide, c'est à dire avec une signature et un scope valides.Aussi, le serveur OAuth2 est seul donc un joyeux SPOF (single point of failure). Tu peux contourner ca en prévoyant plusieurs serveurs OAuth2 qui partageront la même configuration ce qui leur permettra de fournir des access tokens compatibles, mais il faudra permettre à C de connaitre l'ensemble de serveurs OAuth2 disponibles.
Mathieu a mentionné UMA, ca peut aussi répondre à ton problème mais je ne connais pas.