Beaucoup, (mais pas toutes, c'est surtout dans le monde web, même si ça évolue) applications sont capable de déléguer leur authentification à une application dédié (dans le language SAML V2, on l'appel IdP : Identity Provider).
lorsque l'application à besoin d'authentifier un utilisateur, elle le redirige vers son IdP qui se charge de la partie authentification proprement dite (et est capable de détecter si un utilisateur est déjà connecter via sa session et donc de ne pas redemander l'authentification dans se cas. C'est donc transparent pour l'utilisateur). Une fois l'utilisateur authentifié, l'IdP envoie un jeton d'authentification à l'application. L'appliation n'a plus qu'a truster ce dernier pour ouvrir "ses portes" sans avoir connaissance des identifiants mot de passe de l'utilisateur.
en SAML la sécurité se base essentiellement par de la signature de jetons (le chiffrement et aussi possible). Tout passe par le navigateur, il n'y a pas besoin d'ouverture de flux.
en OpenId Connect, cela depend du token utilisé et du flow utilisé :
access_token : doit être valider par le client au prêt de "l'IdP"
un id_token, tout comme SAML est signé et est donc autoporteur
Note : OpenId Connect est utilisé par google, facebook,... pour leur authentification sociale. C'est aussi le protocole utilisé par france connect. SAML lui est beaucoup utilisé en entreprise ou université (exemple renater : https://services.renater.fr/federation/introduction/comment-ca-marche) car la techno est plus ancienne.
Note 2 : d'autres IdP que keycloak existe : shibboleth, simplesamlphp, ...
[^] # Re: Fédération
Posté par Mathieu CLAUDEL (site web personnel) . En réponse au message Quel logiciel pour gérer une base d'utilisateurs centralisée ?. Évalué à 3. Dernière modification le 29 mai 2018 à 16:15.
Beaucoup, (mais pas toutes, c'est surtout dans le monde web, même si ça évolue) applications sont capable de déléguer leur authentification à une application dédié (dans le language SAML V2, on l'appel IdP : Identity Provider).
lorsque l'application à besoin d'authentifier un utilisateur, elle le redirige vers son IdP qui se charge de la partie authentification proprement dite (et est capable de détecter si un utilisateur est déjà connecter via sa session et donc de ne pas redemander l'authentification dans se cas. C'est donc transparent pour l'utilisateur). Une fois l'utilisateur authentifié, l'IdP envoie un jeton d'authentification à l'application. L'appliation n'a plus qu'a truster ce dernier pour ouvrir "ses portes" sans avoir connaissance des identifiants mot de passe de l'utilisateur.
en SAML la sécurité se base essentiellement par de la signature de jetons (le chiffrement et aussi possible). Tout passe par le navigateur, il n'y a pas besoin d'ouverture de flux.
en OpenId Connect, cela depend du token utilisé et du flow utilisé :
access_token : doit être valider par le client au prêt de "l'IdP"
un id_token, tout comme SAML est signé et est donc autoporteur
Note : OpenId Connect est utilisé par google, facebook,... pour leur authentification sociale. C'est aussi le protocole utilisé par france connect. SAML lui est beaucoup utilisé en entreprise ou université (exemple renater : https://services.renater.fr/federation/introduction/comment-ca-marche) car la techno est plus ancienne.
Note 2 : d'autres IdP que keycloak existe : shibboleth, simplesamlphp, ...