F5 APM – Fédération OAuth
J'ai travaillé avec OAuth dans l'APM F5 cette année pour un projet SSO. J'avais déjà travaillé avec la fédération SAML mais je n'avais pas tellement travaillé avec la fédération OAuth jusqu'à présent. OAuth et SAML sont des protocoles pour encourager et standardiser l'interopérabilité. Cependant, SAML est vraiment bon pour le processus d'authentification tandis que OAuth est la meilleure solution pour le processus d'authentification et d'autorisation. En fait, OAuth est très utilisé par des entreprises telles qu'Amazon, Google, Facebook, Microsoft et Twitter pour permettre aux utilisateurs de partager des informations sur leurs comptes avec des applications ou des sites Web tiers.
Open Authorization (OAuth) 2.0 est une infrastructure qui permet à une application d'obtenir un accès limité au nom d'un utilisateur à un service HTTP. Cependant, si nous voulons configurer OAuth, nous devons d'abord connaître la terminologie OAuth. Premièrement, le serveur de ressources (RS) est un serveur hébergeant la ressource protégée. Par exemple, un serveur virtuel BIG-IP LTM+APM. Deuxièmement, le propriétaire de la ressource (RO) est une entité capable d'accorder l'accès à une ressource protégée. Cela peut être, ou est généralement, un utilisateur sur un appareil client. Troisièmement, l'application client est une entité effectuant des demandes de ressources protégées au nom du propriétaire de la ressource et avec son autorisation. Les exemples incluent les applications de messagerie et de bureautique. Enfin, le serveur d'autorisation (AS) émet des jetons d'accès à l'application cliente après avoir authentifié avec succès le propriétaire de la ressource et obtenu l'autorisation. Cela peut être connecté à une base de données d'utilisateurs comme OpenLdap ou Active Directory.
Le diagramme suivant décrit le flux général du protocole OAuth 2.0. Tout d'abord, l'utilisateur accède à l'application cliente. Ensuite, l'application redirige l'utilisateur vers l'AS pour authentification. Lors de l'authentification, l'utilisateur est redirigé vers l'application cliente avec une autorisation accordée. Puis, l'application client récupère le jeton d'accès de l'AS en fournissant l'identifiant/secret client et l'octroi de l'autorisation. Finalement, l'application cliente accède aux données utilisateur sur le serveur de ressources en fournissant le jeton d'accès.
Open Authorization (OAuth) 2.0 est une infrastructure qui permet à une application d'obtenir un accès limité au nom d'un utilisateur à un service HTTP. Cependant, si nous voulons configurer OAuth, nous devons d'abord connaître la terminologie OAuth. Premièrement, le serveur de ressources (RS) est un serveur hébergeant la ressource protégée. Par exemple, un serveur virtuel BIG-IP LTM+APM. Deuxièmement, le propriétaire de la ressource (RO) est une entité capable d'accorder l'accès à une ressource protégée. Cela peut être, ou est généralement, un utilisateur sur un appareil client. Troisièmement, l'application client est une entité effectuant des demandes de ressources protégées au nom du propriétaire de la ressource et avec son autorisation. Les exemples incluent les applications de messagerie et de bureautique. Enfin, le serveur d'autorisation (AS) émet des jetons d'accès à l'application cliente après avoir authentifié avec succès le propriétaire de la ressource et obtenu l'autorisation. Cela peut être connecté à une base de données d'utilisateurs comme OpenLdap ou Active Directory.
Le diagramme suivant décrit le flux général du protocole OAuth 2.0. Tout d'abord, l'utilisateur accède à l'application cliente. Ensuite, l'application redirige l'utilisateur vers l'AS pour authentification. Lors de l'authentification, l'utilisateur est redirigé vers l'application cliente avec une autorisation accordée. Puis, l'application client récupère le jeton d'accès de l'AS en fournissant l'identifiant/secret client et l'octroi de l'autorisation. Finalement, l'application cliente accède aux données utilisateur sur le serveur de ressources en fournissant le jeton d'accès.
Flux de protocole OAuth 2.0 |
Ci-dessous, vous pouvez voir comment un jeton d'accès est obtenu à partir de l'application client Postman par rapport au serveur d'autorisation OAuth configuré dans F5 APM. En outre, vous pouvez voir que l'utilisateur ne peut pas accéder à la ressource protégée lorsque le jeton d'accès est révoqué.
Avez-vous déjà configuré OAuth dans F5 APM ?
Commentaires
Enregistrer un commentaire