A presentation at Very Tech Trip in in Paris, France by Seb Ferrer
L’utilisateur s’authentifie 3 fois, une fois par appli Une identité et un système d’authentification par appli Une création de compte à faire par appli, une paire de login/password à retenir Les 3 applis appartiennent à une même entreprise, l’admin est obligé d’ajouter les utilisateurs sur toutes les applis et si l’un d’eux quitte l’entreprise, il faut lui couper les accès partout Plus on a un système hétérogène, plus la sécurité est instable MFA, notifications, on est obligé de les ajouter partout
Les identités sont centralisées au sein d’un même endroit Un seul système d’authentification L’utilisateur s’authentifie à un seul endroit L’identity Provider redescend l’identité au sein des applications Les applis n’ont pas leur propre système d’authentification, elles vont déléguer ce système à l’identity provider, et ainsi déléguer ses identités C’est ça qu’on appelle la Fédération d’identité En fédération, on parle de Service Provider et d’Identity Provider
Quelques exemples. Ici on introduit les deux types de férédation : la fédération corp et les logins sociaux.
Ils se connaissant malgré le fait qu’ils ne se touchent pas Pas d’accès direct de SP à AD Introduire le trust en raisonnant par l’absurde
To do this, the SP requires at least the following: Certificate - The SP needs to obtain the public certificate from the IdP to validate the signature. The certificate is stored on the SP side and used whenever a SAML response arrives. ACS Endpoint - Assertion Consumer Service URL - often referred to simply as the SP sign-in URL. This is the endpoint provided by the SP where SAML responses are posted. The SP needs to provide this information to the IdP. IdP Sign-in URL - This is the endpoint on the IdP side where SAML requests are posted. The SP needs to obtain this information from the IdP.
Petit détour par un mécanisme de délégation d’authorisations : OAuth2
OAuth2 name équivalences :
Introduire l’arrive d’OIDC. Le fait qu’on retrouve l’idée dommune de délégation de quelque chose (identité chez SAML, autorisations chez OAuth2), et que les gens ont fini par se dire que ce serait bien de déléguer également de l’identité via OAuth2
Expliquer rapidement pourquoi OIDC est fondé sur OAuth: le systeme de token existait déja chez google facebook etc… Du coup faire évoluer les choses ne devait pas vraiment etre complexe.
OAuth + Identité = OpenID Connect
Détails: Scopes: demande de droits via OAuth profile: droit de voire les info de l’utilisateur (nom, prénom, email, email_verified) openid: droit de reçevoir un identity token qui sert de preuve de connection
Les informations de profile sont dupliqué dans le token d’identité
Authorisation: Le SP demande redirige l’utilisateur vers l’endpoint /authorize de l’IdP code_verifier : PKCE request scopes (oidc + profile) callback url client_id state (allows SP to identify which user is login in)
Utilisateur se connecte (si nécéssaire) et accepte les scopes demandées (cf slides). L’utilisateur est redirigé vers le SP avec le code d’authorisation -> pas d’authentification entre le SP et l’IdP
Le SP utilise client_id/client_secret pour s’identifier sur l’endpoint /token de l’IdP et fournis le code d’authorisation et le code_verifier client_id/client_secret authorization_code code_verifier
L’IdP renvoie un access_token et un id_token Le SP valide le login de l’utilisateur
Parler de JIT. Limitations : vous ne connaissez l’identité que los de la première authentification et ne saurez jamais quand elle sera supprimée
References SAML: - https://developer.okta.com/docs/concepts/saml/ https://www.youtube.com/watch?v=l-6QSEqDJPo https://samltest.id/ https://github.com/crewjam/saml https://kantarainitiative.github.io/SAMLprofiles/saml2int.html http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf OIDC: - 18 https://developer.okta.com/docs/concepts/oauth-openid https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc https://www.rfc-editor.org/rfc/rfc6749 https://openid.net/specs/openid-connect-core-1_0.html Icons: Icons created by Freepik – Flaticon https://www.flaticon.com/
Dans notre monde numérique, nous utilisons couramment diverses applications web, dans lesquelles nous sommes authentifiés via notre identité.
Est-il forcément nécessaire de créer un compte à chaque endroit qui nécessite une identité ? Comment une application web peut-elle déléguer son authentification à une entité tierce ?
Vous êtes-vous déjà demandé ce qui se cache derrière les boutons “Se connecter via Google/Facebook”, ou FranceConnect ?
Vous êtes-vous déjà demandé pourquoi vous n’avez pas à vous authentifier plus d’une fois pour tous les outils dans votre entreprise ?
Comment tout cela est-il sécurisé ?
Dans ce talk, nous expliquerons le principe d’identité fédérée et de “Single Sign-On” (SSO).
Nous vous raconterons comment cette notion est devenue universelle, et à quel point votre identité dans le monde numérique renferme des secrets fascinants.
Nous expliquerons, sans rentrer dans les détails, le fonctionnement des deux protocoles très majoritairement utilisés pour faire de la fédération d’identité, à savoir SAML et OIDC.
for free. You
can too.