使用 SAML 扩展和 Shibboleth 在 Spring 中进行单点登录 [英] Single Sign-On in Spring by using SAML Extension and Shibboleth

问题描述

我想在基于 Spring 的应用程序中实现单点登录 (SSO) 身份验证层，目的是支持来自不同安全域的身份验证和授权.我已选择 Shibboleth 作为 IdP，但我尚未确定我将用于 SP 的内容.

选项是:

• Spring Security SAML 扩展: 组件使新的和现有的应用程序能够在基于 SAML 2.0 协议的联合中充当服务提供者并启用 Web 单点登录.Spring Security Extension 允许在单个应用程序中无缝组合 SAML 2.0 和其他身份验证和联合机制.所有在身份提供者模式下支持 SAML 2.0 的产品(例如 ADFS 2.0、Shibboleth、OpenAM/OpenSSO、RM5 IdM 或 Ping Federate)均可用于连接 Spring Security SAML 扩展.

• Shibboleth(也称为 SP):Shibboleth 是一种基于 Web 的技术，它实现了 SAML 的 HTTP/POST、工件和属性推送配置文件，包括身份提供商 (IdP) 和服务提供商 (SP) 组件.

所以，我有一些问题:

1. 就以下方面而言，直接使用 Spring SAML 作为 SP 是个好主意吗?可扩展性和可维护性?
2. 可以将外部 SP 与 Spring Security 一起使用吗?我该如何配置我的应用程序和/或我的应用程序服务器 (JBoss 8.0 - WildFly)?
3. 在哪里定义角色(针对每个场景)?
4. 哪个是值得的选择?

最好的问候，V.

解决方案

两者的主要区别在于部署场景:

• Shibboleth SP 插件直接部署到 Apache/IIS Web 服务器.
• Spring SAML 已嵌入您的应用程序中.

两者各有利弊.

<小时><块引用>

1. 就可扩展性和可维护性而言，直接使用 Spring SAML 作为 SP 是个好主意吗?

Spring SAML

• 提供对如何执行身份验证以及身份验证过程如何与您的应用程序交互的强大控制.你可以例如创建您自己的配置 UI 并动态添加 IDP，创建自定义登录屏幕作为您应用程序的一部分，对错误处理进行完整且轻松的控制，轻松支持多个 IDP，动态配置 SSO 的详细信息(请求的 AuthnContexts、NameID、绑定、身份验证强制)).
• 轻松解析收到的各种格式的 SAML 属性，在同一应用程序中支持多种身份验证方法.
• 动态生成 SP 元数据，它提供有限的多租户并支持所有其他选项(例如单点注销、密钥持有者、IDP 发现)中不可用的配置文件.
• 与 Spring Security 无缝交互，这带来了一系列自身的好处.使用 Spring SAML，您还可以直接在您的应用程序中配置完整的身份验证和授权策略(例如，哪些页面需要身份验证以及何时不需要身份验证、基于角色的内容访问控制、动态条件下的身份验证升级等).
• 允许您在任何应用程序服务器或容器上以及在任何反向代理或 Web 服务器之后部署应用程序，而不会影响功能.

Shibboleth 插件

• 这些是静态配置的，通常通过 HTTP 标头与您的应用程序交互.它们将身份验证逻辑与应用程序本身分离，因此您唯一需要注意的是接受标头并使用正确的安全上下文初始化应用程序会话.哪些页面受保护的定义存在于 IIS/Apache 服务器上并基于 URL 模式，这意味着身份验证和授权策略部分是在您的应用程序之外定义的.
• 您需要确保只能通过 Web 服务器访问应用程序(= 禁止所有直接访问)，因为这会允许伪造标头.
• 不需要对应用程序本身进行很多更改，因此通常可以轻松用于旧系统.

<小时><块引用>

2. 可以将外部 SP 与 Spring Security 一起使用吗?我如何配置我的应用程序和/或我的应用程序服务器(JBoss 8.0 - WildFly)?

是的，这是可能的，但这需要努力.你可以例如配置 WildFly 以设置加密格式的共享域 cookie，并在 Spring Security 配置中验证 cookie.

<小时><块引用>

3. 在哪里定义角色(针对每个场景)?

使用 Spring SAML，您可以在处理 SAML 响应时定义角色，例如解析 SAML 属性.这是通过实现 SAMLUserDetailsS​​ervice 接口并插入 samlAuthenticationProvider 来完成的.

使用 Shibboleth，您可以将从 IDP 接收到的属性与标头一起转发到您的应用程序，并在您的应用程序中解析它们.

WildFly(可能)允许您直接在 SP 中定义安全上下文和角色，而无需在您的应用程序中进行配置.此类配置可能无法跨应用服务器移植.

<小时><块引用>

4. 哪个是值得的选择?

所有选项都将使您能够使用 SAML 2.0 执行 WebSSO.人们通常根据他们的要求(例如定制需求)、环境(使用的 Web 服务器、应用程序服务器)、首选的开发方法(Java、.NET、其他)、使用的框架、遗留代码进行选择.许多客户都在使用 Spring SAML 和 Shibboleth 插件.

I'd like to implement a Single Sign-on (SSO) authentication layer in my Spring-based application with the aim of supporting authentication and authorization from different security domains. I've chosen Shibboleth as IdP, but I have yet to identify what I will use for the SP.

The choices are:

• Spring Security SAML Extension: component enables both new and existing applications to act as a Service Provider in federations based on SAML 2.0 protocol and enable Web Single Sign-On. Spring Security Extension allows seamless combination of SAML 2.0 and other authentication and federation mechanisms in a single application. All products supporting SAML 2.0 in Identity Provider mode (e.g. ADFS 2.0, Shibboleth, OpenAM/OpenSSO, RM5 IdM or Ping Federate) can be used to connect with Spring Security SAML Extension.

• Shibboleth (also as SP): Shibboleth is a web-based technology that implements the HTTP/POST, artifact, and attribute push profiles of SAML, including both Identity Provider (IdP) and Service Provider (SP) components.

So, I've some questions:

1. Is it a good idea to use directly Spring SAML as SP in terms of scalability and maintainability?
2. It is possible to use an external SP together with Spring Security? How have I to configure my application and/or my application sever (JBoss 8.0 - WildFly)?
3. Where do I define the roles (for each scenario)?
4. Which is the worthwhile choice?

Best regards, V.

解决方案

The main difference between the two is deployment scenario:

• Shibboleth SP plugins are deployed directly to the Apache/IIS web server.
• Spring SAML is embedded in your application.

Both have pros and cons.

---

1. Is it a good idea to use directly Spring SAML as SP in terms of scalability and maintainability?

Spring SAML

• Offers great control over how authentication is performed and how the authentication process interacts with your application. You can e.g. create your own configuration UIs and dynamically add IDPs, create custom login screens as part of your application, have complete and easy control over error handling, easily support multiple IDPs, dynamically configured details of the SSO (requested AuthnContexts, NameIDs, bindings, authentication forcing).
• Easily parse received SAML attributes in various formats, support multiple authentication methods in the same application.
• Dynamically generate SP metadata, it provides limited multi-tenancy and supports profiles not available in all other options (e.g. Single Logout, Holder of Key, IDP Discovery).
• Seamlessly interacts with Spring Security which brings a set of benefits of its own. With Spring SAML you can also configure complete authentication and authorization policy directly in your application (e.g. which pages require authentication or not and when, role based access control to content, authentication step-up on dynamic conditions, ...).
• Allows you to deploy the application on any application server or container and behind any reverse proxy or web server with no affect on functionality.

Shibboleth plugins

• These are statically configured and typically interact with your application through HTTP headers. They decouple authentication logic from the application itself, so the only thing you need to take care of is acceptance of the headers and initialization of your application session with correct security context. The definition of which pages are secured is present on the IIS/Apache server and based on URL patterns which means that authentication and authorization policy is partly defined outside of your application.
• You need to make sure that the application can only be accessed through the web server (= prohibit all direct access) as that would allow forging of the headers.
• Doesn't require many changes to the application itself and can therefore typically be easily used with legacy systems.

---

2. It is possible to use an external SP together with Spring Security? How have I to configure my application and/or my application sever (JBoss 8.0 - WildFly)?

Yes, it is possible, but it will require effort. You could e.g. configure WildFly to set a shared domain cookie in encrypted format and verify the cookie in your Spring Security configuration.

---

3. Where do I define the roles (for each scenario)?

With Spring SAML you define roles when processing the SAML Response by e.g. parsing of the SAML attributes. This is done by implementing SAMLUserDetailsService interface and plugging in to the samlAuthenticationProvider.

With Shibboleth you can forward attributes received from IDP to your application with headers and parse them in your application.

WildFly (probably) allows you to define security context and roles directly in SP with no need to configure this in your application. Such configuration might not be portable across application servers.

---

4. Which is the worthwhile choice?

All options will enable you to perform WebSSO with SAML 2.0. People typically choose based on their requirements (e.g. customization needs), environment (used web server, application server), preferred development methodology (Java, .NET, other), used frameworks, legacy code. Both Spring SAML and Shibboleth plugins are used by many customers.

这篇关于使用 SAML 扩展和 Shibboleth 在 Spring 中进行单点登录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！