HQY 一个和谐有爱的空间

推荐点击下面图片，通过本站淘宝优惠价购买:

一、背景和目的

 

解决如下问题：

1. 打通所有系统的账户密码，只需要记住一个就行，而且登录一个系统后，打开其他系统不需要再登录。

2. 不需要记住多个系统的地址，甚至不需要在多个系统页面跳来跳去，通过一个门户网站，串通起常用功能。

需求如下：

1. 具备单点登录功能，并且能为第三方应用提供主流的登录认证。

2. 具备用户的基本信息、角色、资源权限等集中管理和控制。

3. 提供统一的集中办公Portal门户网站，在里面无缝链接其他系统的页面和功能。

 

关键术语：

    IAM（Identity and Access Management），即“身份识别与访问管理”，具有单点登录、强大的认证管理、基于策略的集中式授权和审计、动态授权、企业可管理性等功能。

 

本文涉及关键词：

    IAM, SSO, CAS, OpenID, OICD, OAUTH, SAML, Keycloak, LDAP, RSA, RBAC, MFA等。

    如果这些关键词你都熟悉，就不用继续看了。

 

一、相关技术研究

 

1、单点登录

 

用户仅需要在门户系统登录一次，就可以获得授权范围内所有企业应用程序的访问权，用户只需要记住一个帐号即可。

 

1）门户认证中心

    利用门户系统建立统一的 SSO 认证中心，通过 SSO 中心认证后，应用系统利用 SSO API 同 Portal Server 通信，验证用户是否经过认证。新开发的应用系统大多使用这种 SSO 的实现方式。这种方式需要对应用系统的认证模块进行修改。

 

2）单点登录的实现方式非常非常多，此处仅举一例（后面会详细讨论） 

    LTPA：Lightweight Third-Party Authentication 是IBM Websphere和Domino产品中使用单点登录技术。当服务器配置好LTPA认证方式，用户通过浏览器成功登录后，服务器会自动发送一个session cookie给浏览器；此cookie中包含一个LTPA Token。

    参与SSO的系统必须在同一个DNS域下面（因为浏览器cookie共享的限制，跨域不能共享cookie）。

    参考文档：

https://wenku.baidu.com/view/c8cc8a5da58da0116d17496f.html

https://www.cnblogs.com/hannover/archive/2011/05/29/2061798.html

 

2、伪单点登陆

 

    通过 统一Portal认证后，应用系统还要自己进行用户的认证。这种方式适用于那些无法修改认证模块的应用系统。这种情况可以利用应用系统比较基础的接口来实现，如 URL+User+Password、Form 表单代填等。主要有以下几种技术选择：

 

1）基于 Form 方式

    这种方式是通过模拟用户凭证提交，将业务系统相关的用户凭证通过 Form 提交的方式，传递给业务系统认证模块。

这种方式适合待集成的业务系统认证方式采用 From 表单，当通过 portlet 技术封装 Form 表单包含有业务系统相关的用户凭证，以及资源 URL。通过将业务系统所需的用户凭证通过 Form（表单）提交方式，模拟用户登陆，业务系统将用户所需的资源通过 web 方式反馈用户。

 

点评：不靠谱，由于安全性限制，“Form 表单代填”在浏览器上几乎无法实现。

 

2）URL

    将用户凭证直接通过 URL 的方式发送给业务系统，业务系统的认证程序将截获的用户请求 URL 中获取用户凭证，从而实现门户与业务系统的单点登陆。或者将用户凭证存储在 HTTP 请求报头，业务系统认证程序通过解析 HTTP 请求头信息，获取用户凭证。

 

点评：要求不高的情况下，可以采用这种方法。

 

3）模拟证书

    实现单点登陆的业务系统用户认证方式并不是基于 Form，也不是采用 HTTP Header。需要客户端（此是门户信息系统将被作为客户端，业务系统将作为服务器）提供客户电子证书，这需要通过 portlet 应用程序，或 J2EE 应用程序来实现模拟将电子证书发送给业务系统认证模块。

 

3、整合第三方软件的单点登陆

 

使用信任关联拦截器（TAI）的第三方认证。如 Tivoli Access Manager，CA SiteMinder 等。门户通过使用第三方认证服务器作为外部安全管理器单点登陆。通过定义访问控制规则，由第三方认证服务器来实现用户登陆业务系统的认证功能，将大大简化集成带来的烦琐工作。

 

通常第三方认证服务器（如 Tivoli Access Manager、WebSeal 或者 CA SiteMinder）会提供默认的验证机制采用内置共享库的形式支持通过用户名和密码客户方证书 RSA SecurID 令牌或 HTTP header( 报头 )。选择性将会更多，便于用户根据实际软件需求配置所需的方式。

 

认证方式包括

• Forms-based login

• HTTP basic authentication

• Digital Certificate (X.509v3)

• RSA SecurID Token

• WAP identity mechanism

• Resource-sensitive authentication

• Kerborse

还可以支持 Credentials Acquisition Service (CAS)，从而实现外挂的用户认证方式，如：

• 数据库的认证方式，如 Oracle，DB/2

• 其它 security tokens (Vasco DigiPass)

• 用户定义的认证方式，如使用用户访问代码 PIN 和 Code

• RADIUS

• Biometrics

 

综上，总结如下：

    最主流的还是 单点登录，但是单点登录的协议、形式、平台多种多样（后文会重点分析）。

    一般不考虑 伪单点登录，因为安全性太低。

 

4、页面前端集成展现（基于页面内容的集成）

iFrame Portlet

基于页面的集成整合可以通过 iFrame Portlet 的方式，这也是门户项目中常见的一种集成方式。

 

通过 iFrame Portlet 集成依赖于以下几种情况：

 

1）此方法只适合 B/S 的业务应用系统。

此种集成方式的前提是：门户系统和应用系统之间已经实现 SSO。由于应用系统的页面之间在门户页面中展现，故需要考虑 SSO 的自动实现。

实现方式：在用户登陆门户站点时，将登陆门户的业务系统账号统一保存在用户会话中。并且实现应用系统的认证环节，当通过 iFrame 方式实现页面集成时，通过将业务系统的用户凭证从用户会话提取，然后直接通过配置的 URL 展现即可。

 

2）需要应用系统提供具体的，可配置的 URL。

可选，为了更好的适应集成的需要，可能需要更改业务系统 URL 级接口或者修改认证模块。例如：业务系统修改认证模块，来满足集成的要求 ; 业务系统修改功能模块加入 URL 认证能力。

 

3）业务系统界面需满足 VI 设计要求

为保证门户站点的整体风格，业务系统的展示页面将必须满足门户站点的 VI 设计要求。

 

另外，有非常非常低的几率会遇到页面的问题：

• 使用 Iframe 框架，可能会改变原有应用的 HTML 结构，导致某些脚本无法运行。

• 在一个页面中过多的嵌入 IFrame，由于不同 浏览器版本对于 IFrame 的处理能力各异，可能会出现不可预料的异常效果。

 

总结：

    如果非要做页面集成展现的话，

• 1）只有iframe是最通用、简单的办法了。除此之外，还有如下两个笨办法：

• 2）集中部署，把相关项目合并，部署在同一个war包中，这种方式我曾经做过，但是问题很多，例如上线问题；

• 3）各项目提供API，然后把页面代码 单独放在一个项目中，这种方式对大型项目不实用，开发工作量太大，只适合小功能小需求。

 

   总之，我个人并不建议做大规模的页面集成，用单点登录，能统一访问到各个平台就行了，没必要把各个平台的页面集成到同一个视图中，这样用户体验反而不好，特殊需求，可以按（3）的办法做集成，提供一个统一管理平台就行了。

 

5、SSO单点登录涉及的基本对象

应用/模块/对象	说明
前台站点	需要登录的站点
SSO站点-登录	提供登录的页面
SSO站点-登出	提供注销登录的入口
SSO服务-登录	提供登录服务
SSO服务-登录状态	提供登录状态校验/登录信息查询的服务
SSO服务-登出	提供用户注销登录的服务
数据库	存储用户账户信息
缓存	存储用户的登录信息，通常使用Redis

 

参考资料：https://ken.io/note/sso-design-implement

 

6、OIDC (OpenID Connect) 和 SAML (The Security Assertion Markup Language)

（可以直接看我的中文翻译）

1）What is OpenID Connect? How does it work?

    OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message.（一个基于OAuth2.0的认证协议，使用REST/JSON消息）

    OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.（支持各种客户端，包括Web应用、手机APP等）

    OAuth 2.0, is a framework, specified by the IETF in RFCs 6749 and 6750 (published in 2012) designed to support the development of authentication and authorization protocols. It provides a variety of standardized message flows based on JSON and HTTP; OpenID Connect uses these to provide Identity services.（OAuth2是一个授权协议，它无法提供完善的身份认证功能，而OIDC使用OAuth2的授权服务器来为第三方客户端提供用户的身份认证，并可以适用于各种类型的客户端（比如服务端应用，移动APP，JS应用），且完全兼容OAuth2，也就是说你搭建了一个OIDC的服务后，也可以当作一个OAuth2的服务来用）

    OIDC的核心在于在OAuth2的授权流程中，一并提供用户的身份认证信息（ID Token）给到第三方客户端，ID Token使用JWT格式来包装，得益于JWT（JSON Web Token）的自包含性，紧凑性以及防篡改机制，使得ID Token可以安全的传递给第三方客户端程序并且容易被验证。此外还提供了UserInfo的接口，用户获取用户的更完整的信息。

 

6）ID Tokens

    OpenID Connect Id Token是一个签名的JSON Web Token（JWT：RFC7519），它和OAuth access token一起提供给Client应用程序。Id Token包含一组关于身份认证会话的声明（claim），包括用户的标识（sub）、颁发令牌的提供程序的标识符（iss）、以及创建此标识的Client的标识符（aud）。此外，Id Token还包含token的有效生存期（通常非常短）以及其他相关的上下文信息。由于Client知道Id Token的格式，因此它能直接分析出token的内容而无需依赖外部服务。此外，OpenId Connect还颁发access token给Client，允许Client保持对token的不透明，因为这是属于OAuth规范的一部分。最后，token本身是由提供程序的私钥进行签名的，除了在获取token中受TLS的保护之外，还添加了一个额外的保护层，以防止类似的模拟攻击。通过对此token的一些校验检查，Client可以保护自己免受大量常见的攻击。

    由于Id token是授权服务器签名的，它还提供了在authorization code（c_hash）和access token(at_hash)上添加分离签名的位置，这些hash可以由Client来验证，同时仍保留authorization code和access token对Client不透明的语义，从而防止这一类的注入攻击。

    应该指出的是，Client不再需要使用access token，因为Id token已经包含了处理身份认证所需的所有信息。然而，为了保持和OAuth的兼容性，OpenId Connect会同时提供Id token和acces token。

 

7）UserInfo Endpoint

    除了Id token包含的信息之外，还定义了一个包含当前用户信息的标准的受保护的资源。如上所述，这些信息不是身份认证的一部分，而是提供附加的标识信息。比如说应用程序提示说“早上好：Jane Doe”，总比说“早上好：9XE3-JI34-00132A”要友好的多。它提供了一组标准化的属性：比如profile、email、phone和address。OpenId Connect定义了一个特殊的openid scope，可以通过access token来开启Id token的颁发以及对UserInfo Endpoint的访问。它可以和其他scope一起使用而不发生冲突。这允许OpenId Connect和OAuth平滑的共存。

 

8）动态服务发现以及客户端注册

    OAuth2为了允许各种不同的部署而编写，但是这样的设计并没有指定这些部署如何设置以及组件之间如何互相了解，在OAuth自己的世界中这是没问题的。在使用OpenId Connect时，一个通用的受保护的API部署在各种各样的Client和提供者中，所有这些都需要彼此互相了解才能运行。对于每个Client来说，不可能事先了解有关每个提供程序，并且要求每个提供者了解每个潜在的Client，这将大大削弱扩展性。

    为了抵消这种情况，OpenId Connect定义了一个发现协议，它允许Client轻松的获取有关如何和特定的身份认证提供者进行交互的信息。在另一方面，还定义了一个Client注册协议，允许Client引入新的身份提供程序（identity providers）。通过这两种机制和一个通用的身份API，OpenId Connect可以运行在互联网规模上运行良好，在那里没有任何一方事先知道对方的存在。

 

9）OIDC 主要术语

主要的术语以及概念介绍（完整术语参见http://openid.net/specs/openid-connect-core-1_0.html#Terminology）：

• EU：End User：一个人类用户。

• RP：Relying Party ,用来代指OAuth2中的受信任的客户端，身份认证和授权信息的消费方；

• OP：OpenID Provider，有能力提供EU认证的服务（比如OAuth2中的授权服务），用来为RP提供EU的身份认证信息；

• ID Token：JWT格式的数据，包含EU身份认证的信息。

• UserInfo Endpoint：用户信息接口（受OAuth2保护），当RP使用Access Token访问时，返回授权用户的信息，此接口必须使用HTTPS。

 

参见：http://www.cnblogs.com/linianhui/p/openid-connect-core.html

https://openid.net/connect/faq/

https://help.aliyun.com/document_detail/93698.html

 

10）相关技术

参见： OAuth 2.0 Core and Extensions, OpenID Connect 1.0, and Javascript Object Signing and Encryption (JWT-JOSE)

 

11）SAML 联合登录的基本思路（以阿里云为例）

    阿里云与外部企业身份系统的集成场景中，阿里云是服务提供商（SP），而企业自有的身份服务则是身份提供商（IdP）。企业员工通过企业自有身份服务登录到阿里云控制台的基本流程如下，

    当管理员在完成 SAML 联合登录的配置后，企业员工可以通过如图所示的方法登录到阿里云控制台：

1. 企业员工 Alice 使用浏览器登录阿里云，阿里云将 SAML 认证请求返回给浏览器。

2. 浏览器向企业 IdP 转发 SAML 认证请求。

3. 企业 IdP 提示企业用户登录，并且在用户登录成功后生成 SAML 响应返回给浏览器。

4. 浏览器将 SAML 响应转发给阿里云。

5. 阿里云通过 SAML 互信配置，验证 SAML 响应的数字签名以验证 SAML 断言的真伪，并通过 SAML 断言的用户名称，匹配到对应云账号中的 RAM 用户身份。

6. 登录服务完成认证，阿里云向浏览器返回登录 session 以及阿里云控制台的 URL。

7. 浏览器重定向到阿里云管理控制台。

说明 在第 1 步中，企业员工从阿里云发起登录并不是必须的。企业员工也可以在企业自有 IdP 的登录页直接点击登录到阿里云的链接，向企业 IdP 发出登录到阿里云的 SAML 认证请求。

参见：https://help.aliyun.com/document_detail/93684.html?spm=a2c4g.11186623.6.569.5a6f5cedf4m43L

https://www.keycloak.org/docs/latest/authorization_services/index.html

 

8、其他身份验证技术

SASL（简单身份验证会话层）

Generic Security Service API (GSSAPI)

LDAP、Active Directory

Kerberos（由JBoss开源的）

Multifactor Authentication (MFA) 多因素认证

OTP(One-time Password)

Proxy Authentication

 

9、资源权限控制模型

以开源的Casbin项目为例，它支持如下一些权限模型：

1. ACL (Access Control List)

2. ACL with superuser

3. ACL without users: especially useful for systems that don't have authentication or user log-ins.

4. ACL without resources: some scenarios may target for a type of resources instead of an individual resource by using permissions like write-article, read-log. It doesn't control the access to a specific article or log.

5. RBAC (Role-Based Access Control)

6. RBAC with resource roles: both users and resources can have roles (or groups) at the same time.

7. RBAC with domains/tenants: users can have different role sets for different domains/tenants.

8. ABAC (Attribute-Based Access Control): syntax sugar like resource.Ownercan be used to get the attribute for a resource.

9. RESTful: supports paths like /res/*, /res/:id and HTTP methods like GET, POST, PUT, DELETE.

10. Deny-override: both allow and deny authorizations are supported, deny overrides the allow.

11. Priority: the policy rules can be prioritized like firewall rules.

最常用的是 RBAC 的变种增强模式，当然其他各种模型也有用武之地。

有了这些模型后，还得定一套资源权限定义的语法及解析工具，这些Casbin都为我们做了。

参见：https://www.v2ex.com/t/531053

 

还有一个开源项目 ladon，亚马逊就是用的这个

https://github.com/ory/ladon

 

对比分析参见：https://www.v2ex.com/t/536855

 

 

二、技术选型和对比

 

1、确定采用哪种身份认证协议、数据源和授权方案（CAS, SAML, OpenID Connect等等） 

 

首先说 SAML2.0，它是第一个身份认证标准（但不是唯一一个），而且功能非常强大，已经流行了很多年，像Windows Server等都自带了 SAML 2.0的认证。目前阿里云、腾讯云等，都支持 SAML 2.0登录。

SAML2.0的缺点是

1）太复杂；

2）基于XML，对浏览器不太友好；

3）对移动端APP支持不好；
4）年事已高，在新系统中用得越来越少。

 

再说 OpenID Connect，它是后起之秀，起于2014年，目前Google等很多大公司都在使用了。它的优点主要有：

1）后起之秀，吸取了SAML 2.0等其他标准的优点，功能也非常强大。

2）基于JSON（JWT），对浏览器友好，且原生支持移动端（Android系统直接内置了）；

缺点是：

1）还是很复杂……

2）基于OAuth2.0，对OAuth2.0是强依赖。

 

再说 CAS，v1/v2/v3，目前最新是v3版本，MIT提出来的，也有很多年历史了，但是它功能弱，主要适用于WebApp，还有就是 主要和 CAS projects绑定在一起使用，在Java应用中比较流行。还有，CAS既是一个协议，也是一套解决方案，CAS Projects已经非常成熟，缺点是非常非常的庞大冗余，后面会详细讲这个问题。

 

再说 LDAP，它也可以用来做SSO，而且很多系统和软件都支持LDAP登录。但是它只是一个用来认证用户和密码的方法而已，说得更直接一点，你可以把LDAP看做一个存储用户数据的统一的数据库而已，所谓的SSO就是在这个统一的LDAP数据库中去查询用户名和密码，在某些场景，完全可以用MySQL等数据库直接替换掉LDAP。

 

再说 基于OAuth2.0的身份认证，这种方式 属于 伪身份认证，功能非常弱，不如 OpenID Connect专业，故直接Pass掉。

 

以上是我的研究结论，一家之言。可以再看看其他人的分析：

https://www.keycloak.org/docs/latest/securing_apps/index.html#openid-connect-vs-saml

 

结论如下：

身份认证协议，最终决定用OpenID Connect

授权协议，没什么好说的，目前大家都在用 OAuth 2.0，它是最佳选择

 

PS：差一点我就选CAS了，选CAS无非是看重它的简单和成熟，然而试用了CAS 平台之后，我发现并非如此，故放弃。

 

崩溃1：学习、分析对比这些协议，让我精神崩溃。来个最简单的——CAS协议，感受一下：

https://apereo.github.io/cas/development/protocol/CAS-Protocol.html

 

2、确定采用哪个平台（Apereo CAS、MITREid Connect、KeyCloak等） 

 

各种协议的平台非常非常多，开源的、商业的，都很多，甚至有Okta这样的专业的，已经发展成独角兽、上市公司的平台。

这里先排除 商业的平台，这些商业的平台，给人的感觉是，万能的，功能非常强大，几乎所有协议都支持的，然而我只想要一个简单的能完全自己掌握的产品。

 

再排除 除了OpenID Connect之外的其他协议的平台，重点考虑对OpenID Connect支持较好的平台。

另外，暂时只考虑Java语言实现的平台。

那么就剩下，Apereo CAS、MITREid Connect、KeyCloak。

 

首先说 Apereo CAS，号称支持各种协议，支持很多种语言的clients集成，而且它在业界也比较有名了，应该也比较成熟了。

所以，我开始把它作为首选。然而，我下载它的Demo，调试了很多功能之后，几乎就要哭了。主要有以下问题：

1）产品线铺得太宽，太冗余；

2）项目太大（war包180多MB），源码和配置官方都不建议改，使用非常不灵活；

3）配置项太多（估计有几千个配置项吧），文档写得太少，网上资料也很少（其实网上教程很多，但是99%都千篇一律的基础）。

4）项目集成了太多东西，光是maven pom.xml文件都有7500行，而且是war包调试非常困难。

 

弄了几天之后，终于决定放弃（并且想到以后要在上面做配置和二次开发，问题肯定不少，折磨人）

 

再说 MITREid Connect，只支持OpenID Connect协议，但是算比较专业的，功能比较全，关键是开源的OpenID Connect Provider（OP）选择也不多，当然比商业的一些OP功能要弱。我试用了一下，比较顺利，源码也可以调试，但是基于Spring Security，还是比较复杂，而且从设计上讲，不算特别优雅。

 

对CAS失望后，我就开始把 MITREid Connect当做主打，但明显感觉需要很多的二次开发工作（与CAS比，缺失了很多功能），而且代码还比较复杂。

 

再说 KeyCloak，这也是一个集大成的平台，支持多种协议，服务器都支持 jetty、tomcat、WildFly、jboss等等，自带功能很强，和CAS有得一比：

• CAS主打CAS，并支持其他协议，而KeyCloak主打OpenID Connect，并支持SAML2.0；

• KeyCloak为后起之秀，为JBoss开源，背景够硬，而CAS也与时俱进，但相比而言，KeyCloak没有那么多历史包袱，从内到外都是全新，CAS只是看起来新，实则从设计到代码都是很旧的；

• KeyCloak为JBoss团队设计和开发，设计优雅，文档比较清晰，这点比CAS要好得多；

• 上手体验，KeyCloak上手非常容易，直接解压启动即可，CAS则较难，而且KeyCloak自带的Portal和相关功能很容易使用；

• KeyCloak为JBoss核心项目，天然支持各种复杂的场景，当然CAS也比较成熟，但是CAS的成熟给人的感觉是后期一步一步加上去的，而非最初的设计就很成熟。

另外注意，KeyCloak自带了权限控制模型，这个模型我感觉很好用，虽然没有Casbin、ladon等专业，但是应该能应对绝大多数的项目。再说了，很多项目都有自己的权限控制模型，要接管统一管理，难度不小，这方面后续还得进一步讨论。

值得一提的是，Keycloak前端采用了AngularJS技术，这个技术在国外很流行，但是在国内还是Vue和React用得多。

 

KeyCloak是无意间看到的，刚开始觉得可能非常复杂，没怎么想去碰他，直到后来看了几次它的文档之后，发现功能确实强大，而且文档写得还不错，就下载试了一下，发现设计优美，上手简单，功能强大，且完全满足甚至超越了我的期望，堪称完美。

 

崩溃2：看这些平台的文档，看得我都精神崩溃了。

崩溃3：试用这些平台，调试Demo程序，调得我精神崩溃。

 

综上，结论如下：

    开发平台，最终决定用KeyCloak，功能强大，设计优美，文档清晰，要说缺点可能比较复杂，改代码比较难，但自带的功能基本足够了；

    备选 MITREid Connect，因为它功能简陋，设计普通，需要很多很多的二次开发才行，如果要做到KeyCloak那样的功能，没有个三、五个月怕是搞不定。

    放弃 Apereo CAS，虽说功能强大，但是功能杂乱，代码十分复杂，文档简陋，应对复杂的场景和特殊的需求，实在难以搞定。

 

3、确定采用哪个开发框架（Shiro、Spring Security、Pac4j、MITreid、Nimbus等）

    先说 Java界两大开源安全框架：Shiro和 Spring Security，

    我从 2013年接触 Spring Security时，就感觉不太好，一个集大成的框架，但是太复杂了。

    而Shiro则给人感觉简单得多，而且功能足够了，这么多年都很稳定，和Spring集成也很简单。

    如果要用到一些高级功能，推荐用Spring Security，如果是一般应用，建议用Shiro。

 

Spring Security是主流，很多第三方工具、应用，都支持：

    Apereo CAS、 KeyCloak和MITREid Connect 都是官方支持Spring Security，只有CAS官方支持Shiro。

 

再说 Pac4j，官方说明是：

Security engine for Java (authentication, authorization, multi frameworks): OAuth, CAS, SAML, OpenID Connect, LDAP, JWT...

它是CAS团队开源的一套组件，主要作者都是 Jérôme Leleu（leleuj）。

个人感觉，Pac4j就是从CAS剥离出来的一套比较纯粹、干净的组件。

 

由于比较简单、纯粹，而且又有CAS团队多年的经验沉淀，我还是比较推荐用这个组件。

它和 Spring Security、Shiro都能很好的集成。而且它从设计上，就是和Spring无关的，它支持在非Spring环境下使用。

 

再说 MITreid client，这个就是 MITREid Connect官方提供的client库，强依赖于 Spring Security，设计上也只 支持OpenID Connect，所以如果不是用 MITREid Connect + Spring Security，个人不是很建议用它。

 

再说Nimbus，这是一个主流OpenID Connect商业产品（Connect2id Ltd.）随便开源的一个 支持OAuth和OIDC的库，只是开源只读代码而已，没有社区成员参与维护。一般不建议用，除非完全把它的代码私有化，自行维护。

 

综上，结论如下：

在选择 KeyCloak 平台的前提下，

开发框架，首选 Spring Security，因为 KeyCloak官方提供了对 Spring Security很好的支持，直接用官方的spring-security-adapters就可以。

次选 Shiro + Pac4j（buji-pac4j），因为它支持标准的OIDC，所以接入 KeyCloak 也没问题。

本文链接：https://www.hqyman.cn/post/3909.html 非本站原创文章欢迎转载，原创文章需保留本站地址！

休息一下，本站随机推荐观看栏目: