Pont SAML 2.0 / OpenID Connect
Par défaut, FoxIDs est un pont entre SAML 2.0 et OpenID Connect / OAuth 2.0 sans configuration supplémentaire.
La gestion des identités fédérées (FIM) vise à lier les identités entre domaines, tandis que l’authentification unique (SSO) simplifie l’accès aux applications. FoxIDs prend en charge FIM et SSO, et le pont les rend possibles entre SAML 2.0 et OpenID Connect.
OpenID Connect (OIDC) et SAML 2.0 sont deux protocoles largement utilisés pour la fédération d’identité, l’authentification unique (SSO) et l’authentification des utilisateurs. Cependant, ils sont fondamentalement différents dans leur structure et leur conception. Parfois, vous devez établir un pont ou intégrer ces protocoles, par exemple pour permettre à une application compatible OpenID Connect de fonctionner avec un fournisseur d’identité (IdP) qui ne prend en charge que SAML 2.0.
Principales différences entre les deux types de protocoles :
- OIDC : construit sur OAuth 2.0, protocole moderne conçu pour les applications web et mobiles avec des API RESTful. Utilise des JSON Web Tokens (JWT) pour les jetons d’identité et les jetons d’accès.
- SAML 2.0 : basé sur XML et orienté SSO navigateur, souvent utilisé en environnement d’entreprise. Utilise des assertions / jetons XML.
Pour connecter un système OpenID Connect à un système SAML 2.0, vous avez besoin d’une couche de traduction ou de pont de protocole. Cela peut être réalisé à l’aide d’un intermédiaire qui agit à la fois comme fournisseur OpenID Connect (OP) et comme fournisseur de service SAML (SP), ou l’inverse.
Si vous configurez une méthode d’authentification SAML 2.0 vers un fournisseur d’identité (IdP) externe et connectez votre application comme application OpenID Connect en sélectionnant la méthode d’authentification SAML 2.0. Une requête de connexion provenant de votre application est routée comme une requête de connexion SAML 2.0 externe. La réponse de connexion SAML 2.0 est ensuite mappée vers une réponse OpenID Connect pour votre application. Les revendications SAML 2.0 sont automatiquement converties en revendications JWT (OAuth 2.0).
L’inverse est également possible en démarrant la requête de connexion depuis une application de registre d’application SAML 2.0 et en routant vers un fournisseur OpenID (OP) externe configuré comme méthode d’authentification OpenID Connect. La réponse est ensuite convertie en réponse SAML 2.0.
FoxIDs prend en charge le pont pour la connexion, la déconnexion et le single logout entre SAML 2.0 et OpenID Connect.
Un environnement - un fournisseur d’identité
Toutes les fonctionnalités de pont peuvent être combinées dans le même environnement. Permet à une application OpenID Connect de prendre en charge la connexion via une méthode d’authentification SAML 2.0 ou OpenID Connect en même temps. L’application OpenID Connect peut soit sélectionner la méthode d’authentification de manière programmatique, soit laisser l’utilisateur sélectionner sur une page de home realm discovery (HRD).
Il est recommandé d’avoir une infrastructure applicative avec des clients OpenID Connect activés et des API OAuth 2.0 activées. Où toutes les applications (clients et API) font confiance au même fournisseur d’identité (IdP) - un IdP équivaut à un environnement FoxIDs. En utilisant la fonctionnalité de pont dans FoxIDs, les jetons SAML 2.0 sont mappés vers des jetons ID et des jetons d’accès qui peuvent être utilisés pour authentifier les applications OpenID Connect et appeler les API existantes.
Échange de jetons
Si un utilisateur obtient l’accès à une application SAML 2.0 après une connexion réussie avec un fournisseur d’identité (IdP) SAML 2.0 externe, l’utilisateur obtient l’accès à l’application SAML 2.0 dans le contexte de l’utilisateur lui-même. Avec le zero trust (ne jamais faire confiance, toujours vérifier), vous devrez appeler vos API dans le contexte de l’utilisateur. Cela est possible en utilisant l’échange de jetons où le jeton SAML 2.0 peut être échangé contre un jeton d’accès avec l’identité de l’utilisateur final. Ensuite, votre API OAuth 2.0 peut être appelée dans le contexte de l’utilisateur.
Mappages de revendications
FoxIDs utilise des revendications JWT en interne et mappe les revendications SAML 2.0 vers des revendications JWT. Par défaut, un ensemble de revendications JWT standard vers SAML 2.0 est mappé comme suit : sub vers http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, email vers http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, etc.
Vous pouvez ajouter des mappages supplémentaires de revendications JWT vers SAML 2.0.
Si aucun mappage n’existe pour une revendication particulière, le nom long de revendication SAML 2.0 est conservé depuis les revendications reçues dans un jeton SAML 2.0 au lieu d’un nom de revendication JWT plus court équivalent. Il en va de même dans l’autre sens.