【问题标题】:PingFederate and NGinx integration and deployment optionsPingFederate 和 NGinx 集成和部署选项
【发布时间】:2017-01-03 07:21:07
【问题描述】:

在我们开始研究如何将PingFederate 集成到我们的基础架构之前的一段时间。

我们的初始用例如下:我们为我们的应用程序提供多租户访问,不同的公司可能使用不同的(他们的)身份提供者来访问我们的应用程序。

目前流程仅限于以下工作流程: Mutiple Idp(s) to one SP

不过未来流量可能会扩展到Many-to-many relations

目前我们正在使用 NGINX 作为反向代理,并且根据 PingFed 文档,完全难以理解我们现在拥有的部署选项。

基于取自此guide 的图表

对于 apache httpd,这种集成是如何工作的或多或少已经很清楚了。主要有 apache PingFed Agent 与 apache 上的 SSO 流一起工作,主要是验证“会话”或启动 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.

主要在第 5 步,apache 代理使用请求标头或 Apache 环境变量将有关用户的信息传递给实际应用程序。

根据上面提到的所有信息,这里有 2 个问题:

  1. 如何为 PingFed 和 NGINX 进行类似的部署(对于这个问题中使用 apache httpd 描述的选项)?
  2. 是否需要与 PingFederate 一起使用 Web 服务器(反向代理)。或者 Ping Federate 也可以充当 WebServer?如果是,可能会感谢一些链接和其他解释。

【问题讨论】:

    标签: nginx single-sign-on saml-2.0 httpd.conf pingfederate


    【解决方案1】:

    PingIdentity 已发布NGINX certified PingAccess Agent for NGINX servers。 这个 PingAccess 代理可以作为 PEP 部署在 NGINX Web 服务器上,从而消除了对代理服务器的需要

    【讨论】:

      【解决方案2】:

      值得发表关于解决方案的最终想法和我们的观察结果

      1. 当我们尝试集成 PingFed 时,我们了解到 pingFed 非常自然地与 Ping Access 集成。 Ping Access 充当反向代理。

      PingAccess 和 PingFed 之间的身份验证的主要思想是使用 OpenId 连接协议完成的。 PingFederate 和 Auth 提供者之间的身份验证可以通过非常不同的方式完成:

      1. 可以是SAML
      2. 它可以是另一个 SSO 协议
      3. Ping Fed 还可以提供登录页面并使用某些自定义 DB 或 LDAP 进行身份验证

      但是应用程序的身份验证流程将保持不变,因为 PingFed 隐藏了这种复杂性

      【讨论】:

        【解决方案3】:
        1. 没有来自 Ping Identity 的 PingFederate 代理体系结构 支持 nginx。我建议您查看“无代理适配器”(也称为参考适配器)并构建自己的。
        2. 不需要使用反向代理 PingFederate。 PingFederate 使用 Jetty 作为其 Web 容器,并且是 完全能够为交通服务。我们提供反向选项 代理,以支持那些有要求的组织 反对直接向应用服务器开放端口。

        【讨论】:

        • 所以通常你建议遵循这个模式(没有 NGINX):documentation.pingidentity.com/display/AIK12/… ?您能否提供链接 PingFed 在典型反向代理任务方面的优势:静态内容兑现、SSL 终止……还是我应该看看 Jetty 功能?
        • lua-resty-openidc - 你能补充一点解释它在这个任务中如何有用吗?不确定我是否完全掌握了想法。
        • @HansZ.,这不是“受支持”的架构,来自 Ping。
        • @user1459144 - 是的,一般来说,我会说 Apache 工具包提供的架构足以完成许多任务。或者 IIS 工具包。或任何数量的我们的其他套件。坦率地说,我猜你想要完成什么 - 如果你是客户,你应该联系你的区域解决方案架构师,并与他们讨论你的所有需求。
        • 截至 2017 年 4 月,Pingfederate 支持 nginx。在此处添加此评论作为更新,以防有人查看答案并认为它仍然不受支持。 pingidentity.com/en/company/blog/2017/04/05/…
        猜你喜欢
        • 2013-04-01
        • 2013-12-08
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-05-12
        • 2015-06-02
        相关资源
        最近更新 更多