Options d'intégration et de déploiement de PingFederate et NGinx

Question

Quelque temps avant, nous avons commencé à chercher comment intégrer PingFederate dans notre infrastructure.

Notre cas d'utilisation initial est le suivant : nous fournissons un accès à notre application à plusieurs locataires et différentes entreprises peuvent utiliser différents fournisseurs d'identité pour accéder à notre application.

Actuellement, le flux est limité à ce flux de travail : Idp(s) multiple(s) vers un SP

Cependant, à l'avenir, le flux pourrait être étendu à Relations entre plusieurs personnes

Actuellement, nous utilisons NGINX comme Reverse Proxy et, d'après la documentation de PingFed, il est totalement difficile de comprendre les options de déploiement dont nous disposons actuellement.

Basé sur le diagramme qui a été pris de ce guide

La façon dont cette intégration fonctionne pour apache httpd est plus ou moins claire. Il y a principalement l'agent PingFed d'apache qui fonctionne avec les flux SSO sur apache et principalement il valide la "session" ou initie le flux SSO.

    Processing Steps
1. A user attempts to access a resource on the Apache server protected by the PingFederate
Apache Agent.
2. The user is redirected to the PingFederate server for authentication.
(If an OpenToken session already exists, the user is granted immediate access.)
3. The PingFederate server redirects the user’s browser to an IdP for authentication using either the
SAML or WS-Federation protocols. The IdP partner authenticates the user and returns a SAML
assertion.
4. PingFederate validates the assertion and creates an OpenToken for the user including any
configured attributes. PingFederate then redirects the browser, including the OpenToken, back to
the Apache Agent.
5. The Agent verifies the OpenToken and grants access to the protected resource. The User ID and
any attributes from the OpenToken are exposed to the resource as HTTP Request Headers or Apache Environment Variables.

Et principalement à l'étape 5, l'agent Apache transmet les informations sur l'utilisateur à l'application réelle en utilisant les en-têtes de requête ou les variables d'environnement Apache.

Sur la base de toutes les informations mentionnées ci-dessus, voici deux questions :

1. Comment faire un déploiement similaire pour PingFed et NGINX (pour l'option décrite dans cette question avec apache httpd) ?
2. Est-il nécessaire d'utiliser un serveur Web (Reverse Proxy) avec PingFederate ? Ou Ping Federate peut également faire office de serveur Web ? Si oui, des liens et des explications supplémentaires seraient les bienvenus.

Answer 1

Cela vaut la peine de publier les idées finales sur la solution et nos observations.

1. Lorsque nous avons essayé d'intégrer PingFed, nous avons compris que pingFed est intégré de manière très native à Ping Access. Et Ping Access agit comme un Reverse proxy.

Et l'idée principale est que l'authentification entre PingAccess et PingFed est faite en utilisant le protocole OpenId connect. L'authentification entre PingFederate et le fournisseur d'authentification peut se faire de différentes manières :

1. Il peut s'agir de SAML
2. Il peut s'agir d'un autre protool SSO
3. Ping Fed peut également servir de page de connexion et effectuer l'authentification en utilisant une base de données personnalisée ou LDAP.

Cependant, le flux d'authentification pour l'application restera le même car PingFed cache cette complexité.

Answer 2

1. Il n'existe pas d'architecture d'agent PingFederate de Ping Identity qui supporte nginx. Je vous suggère d'étudier l'adaptateur sans agent (également connu sous le nom d'adaptateur de référence) et de créer le vôtre.
2. Il n'y a pas d'obligation d'utiliser un reverse proxy avec PingFederate. PingFederate utilise Jetty comme conteneur web, et est parfaitement capable de gérer le trafic. Nous proposons des options de reverse proxy inversé afin de soutenir les organisations qui ont des exigences contre l'ouverture d'un port directement vers un serveur d'application.

Answer 3

PingIdentity a publié Agent PingAccess certifié par NGINX pour les serveurs NGINX . Cet agent PingAccess peut être déployé sur le serveur web NGINX en tant que PEP, éliminant ainsi le besoin de serveurs proxy.