TL;DR: Tu peux peu-être utiliser les response type client credential ou password dans OAuth2 pour répondre à ton besoin mais je ne suis pas sûr de l'avoir totalement compris.
On travaille sur l'échange de données énergétiques (et plus) en mode fédéré
Mais encore? Plus précisément qui échange avec qui?
Est-ce que ce sont des systèmes embarqués qui récoltent des données puis les poussent sur un service distant ou des services distribués?
Est-ce que ce sont des utilisateurs avec leur téléphone intelligent qui se connectent dans une app et qui rentrent des données à la main?
Autre chose?
nous avons réfléchi au RGPD
Quel est l'impact du RGPD dans ton cas?
ces protocoles nécessitent des paramètres amont
Plus précisément, ces protocoles nécessitent que les clients et les utilisateurs soient préalablement connus du serveur d'authentification. Mais je ne comprends pas ton besoin, donc je ne peux pas te dire si tu es dans le champ ou pas.
Nous voulons faire sen sorte que les échanges de données entre applications soient fluides, nous voulons tracer les autorisations
Dans un contexte à base d'API REST, je verrais quelque chose comme ca:
Chaque application est connue du serveur OAuth2 par un identifiant/mot de passe.
Il existe un ou plusieurs services REST qui ont pour tâche de te renvoyer un JWT signé contenant les données que tu lui as fournies. Seuls ces services REST connaissent les clés privées pour signer les messages, mais les clés publiques sont publiques justement, donc n'importe qui (n'importe quel noeud) peut vérifier la signature pour s'assurer que ledit message est bien valide, et résoudre une partie du problème des généraux byzantins: le message n'a pas été altéré pendant le transport.
Lorsqu'une application souhaite envoyer un message aux noeuds, elle se connecte au serveur OAuth2, lui réclame un access token en utilisant son identifiant/mot de passe.
Le message non signé est transmis au service REST de signature qui lui renvoie le message signé sous forme de JWT
Le message signé est enfin prêt à être distribué via XMPP ou tout autre moyen aux autres noeuds qui n'auront qu'à vérifier la signature tout seuls.
Bonus: les response type client credential ou password ne nécessitent pas d'url de retour.
[^] # 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.
TL;DR: Tu peux peu-être utiliser les response type
client credentialoupassworddans OAuth2 pour répondre à ton besoin mais je ne suis pas sûr de l'avoir totalement compris.Mais encore? Plus précisément qui échange avec qui?
Est-ce que ce sont des systèmes embarqués qui récoltent des données puis les poussent sur un service distant ou des services distribués?
Est-ce que ce sont des utilisateurs avec leur téléphone intelligent qui se connectent dans une app et qui rentrent des données à la main?
Autre chose?
Quel est l'impact du RGPD dans ton cas?
Plus précisément, ces protocoles nécessitent que les clients et les utilisateurs soient préalablement connus du serveur d'authentification. Mais je ne comprends pas ton besoin, donc je ne peux pas te dire si tu es dans le champ ou pas.
Dans un contexte à base d'API REST, je verrais quelque chose comme ca:
Chaque application est connue du serveur OAuth2 par un identifiant/mot de passe.
Il existe un ou plusieurs services REST qui ont pour tâche de te renvoyer un JWT signé contenant les données que tu lui as fournies. Seuls ces services REST connaissent les clés privées pour signer les messages, mais les clés publiques sont publiques justement, donc n'importe qui (n'importe quel noeud) peut vérifier la signature pour s'assurer que ledit message est bien valide, et résoudre une partie du problème des généraux byzantins: le message n'a pas été altéré pendant le transport.
Lorsqu'une application souhaite envoyer un message aux noeuds, elle se connecte au serveur OAuth2, lui réclame un access token en utilisant son identifiant/mot de passe.
Le message non signé est transmis au service REST de signature qui lui renvoie le message signé sous forme de JWT
Le message signé est enfin prêt à être distribué via XMPP ou tout autre moyen aux autres noeuds qui n'auront qu'à vérifier la signature tout seuls.
Bonus: les response type
client credentialoupasswordne nécessitent pas d'url de retour.