JAVA单点登录的实现与应用整合中SSO的技术实现
java单点登录的实现在门户项目中，经常会遇到如何实现单点登录的问题，下面就本人的经验做个总结。
欢迎大家进行补充讨论。
单点登录的具体实现有很多种选择，包括：1.采用专门的SSO商业软件：主要有：Netgrity的Siteminder，已经被CA收购。
Novell公司的iChain。
RSA公司的ClearTrust等。
2.采用门户产品供应商自己的SSO产品，如：BEA的WLES，IBM的Tivoli Access Manager，Sun公司的identity Server，Oracle公司的OID等。
3.这些商业软件一般适用于客户对SSO的需求很高，并且企业内部采用COTS软件如：Domino,SAP,Sieble的系统比较多的情况下采用。
并结合身份管理。
统一认证等项目采用。
采用这些软件一般都要对要集成的系统做些改造，如在要集成的系统上安装AGENT。
现在一般只提供常见软件如：Domino,SAP,Sieble，常见应用服务器：weblogic,websphere等的AGENT。
要先统一这些系统的认证。
一般采用LDAP或数据库。
然后才能实现SSO。
比较麻烦。
4.另外，如果不想掏银子，也有OPEN SOURCE的SSO软件可选：主要有：/https:///等。
具体怎么样就不清楚了。
如果项目对SSO的要求比较低，又不想对要被集成的系统做任何改动，可采用下面介绍的方式简单实现：下面我们通过一个例子来说明。
假如一个门户项目要对下面的几个系统做SSO。
用户在这些系统中的用户名，密码各不相同，如：员工号为001的员工在这些系统中的用户名，密码分别如下：用户系统用户名密码001Portal系统A1234001邮件系统B2345001DOMINO系统C AAAA001报销系统D CCCC001工资系统E BBBB首先，建立员工在PORTAL系统中的用户名和其他系统中的用户名之间的对应关系首先，要建立员工在PORTAL系统中的用户名和其他系统中的用户名之间的对应关系并保存。
可保存在表中或LDAP中或文件系统中。
当然要考虑这些系统之间的数据同步问题。
比较好的方式是找到用户在这些系统中的都存在的唯一信息（如员工号，MAIL地址，姓名等）。
通过唯一信息实时到各个系统中去取认证所需要的信息。
就不需要考虑数据同步问题。
比较实用。
可以建立类似下面的表：密码可采用加密保存。
如果是采用BEA的Weblogic Portal,可采用UUP来保存这些信息。
(uservarchar2(20),app_name varchar2(20),architect varchar2(4),app_company varchar2(50),app_department varchar2(50),app_user varchar2(15),app_passwd varchar2(15),app_cookie varchar2(30),form_user varchar2(20),form_passwd varchar2(20),app_special varchar2(20));通过IFRAME或超连接方式集成目标系统，并进行SSO通过IFRAME或超连接方式集成目标系统,并在URL中带上用户名和密码。
如集成DOMINO可采用如下方式：width=">或：Href src=“http:// host1/names.nsf?Login&Username=admin&Password=pass&RedirectTo=/names.nsf”以上采用的是在HTTP中直接传递明码，为提高安全性，可采用HTTPS来传递用户名和密码。
另外采用这种方式被集成的系统必须支持FORM方式认证。
J2EE应用，DOMINO等都支持FORM认证。
这两种方式如果SSO成功，就自动进入目标系统的界面，如果实现会显示目标系统的登录界面。
其效果图如下：这种方式，必须维护对应关系表，如上面的sso_info。
更好的方式是提供界面，让最终用户自己维护这种对应关系，可模仿Compoze portlets for lotus的做法，在用户第一次进入要与之做SSO的系统时，如DOMINO系统，显示一个界面，让用户自己输入他在该系统中的用户名/密码等信息。
并保存到表中或LDAP等其他数据源中。
以后用户要进入这些系统时，就直接从表中或其他数据源中取用户的用户名/密码等信息，帮助用户做认证。
建议采用这种方式。
如下图所示。
如果用户改变了自己在DOMINO系统中的用户名，密码。
从门户系统进入DOMINO系统时，认证会失败，就重新显示类似下面的界面。
让用户重新输入他在DOMINO系统中新的用户名，密码并保存。
以上这种实现方式，一般需要浏览器支持COOKIE，所以要注意浏览器的配置，在开发阶段，为方便调试，可设置IE，让它显示COOKIE的名称。
如下所示：采用这种方式，对要集成的系统不需要做任何的改动。
如果PORTAL系统中的用户在被集成的系统中的权限都一样，可采用建立一个通用用户的做法。
也就是所有在PORTAL系统中的用户都采用这个通用用户进入目标系统。
这种方式等于是采用页面集成方式做集成。
比较方便使用。
另外，有时候需要采用调用API，或配置Adapter等应用集成方式来集成其他系统，一般也是通过定义一个连接专用的用户。
在API中或在配置Adapter的时候写死。
如采用JAVA API方式集成DOMINO：lotus.domino.Session dominoSession=NotesFactory.createSession(dominoServer,“admin”,“password”);CS结构实现方式经常有人问CS结构的应用如何实现SSO，本人的建议是对这种系统不要自己去实现SSO。
很麻烦，其实输个用户名，密码没什么大不了的。
如果要实现，一是采用商业软件。
另外也可以采用以下方式：在PORTAL 的PORTLET上建立超连接。
并通过APPLET方式启动CS结构的应用系统的登录界面。
然后通过如下的方式把用户名/密码传递过去。
-不能做任何改动的客户端-WIN消息（给登录窗口发送用户名，密码等登录所需要的信息）,模拟键盘（java有模拟键盘输入的API）-可以做改动的客户端-参数传递，并让登录的EXE文件读取参数进行认证。
因为要让APPLET执行本地的EXE文件，所以必须对IE中的JRE的安全进行设置。
其他：在采用以上方式实现了SSO后，要注意LOGOUT，可采用与LOGIN相同的方式。
也可以通过被集成系统的超时设置来实现。
单点登录SSO技术资料收集∙统一用户认证和单点登录解决方案:计算机世界网上的文章,比较全面的介绍统一用户认证和单点登录解决方案∙惠普灵动单点登录(SSO)解决方案:包括C/S结构的系统单点登录解决方案∙网站用户单点登录系统解决方案:通过令牌方式实现网站用户单点登录∙WebLogic平台的Web SSO（SAML）解决方案:在WebLogic8.1SP4中，提供了用于和Microsoft Windows客户端进行SSO的Single Pass Negotiate Identity AssertionProvider。
本文对其做了详细的介绍。
∙/index.php?blogId=4:收录了一些SSO方面的文章∙应用整合中SSO的技术实现:作者介绍了南京地税进行应用整合SSO的技术实现方案应用整合中SSO的技术实现在税务行业信息化发展的关键阶段，应用整合已经非常重要，而应用整合的表现层首先要实现的就是单点登陆（SSO，Single sign-on的缩写），以下是笔者结合南京地税进行应用整合中SSO的技术实现。
南京地税目前有多种企业应用，包括征管系统、行政系统、辅助决策系统、公文系统、人事系统、电子地图、邮件系统等等，这些应用主要是采用三层体系结构（IE6.0+weblogic portal7.0+weblogic server7.0 +oracle9i）来构架。
所有的用户登陆需要通过weblogic portal进行。
我们在系统中使用SSO来实现用户通过一次认证（authenticate）来存取多个受保护的资源，也就是说，用户随后对受保护资源的存取，将不会导致每一次都要用户提供认证的信息，只需要一次认证即可。
一、SSO实现原理1、概念：SSO的一种偏向技术的说法：用户只需登陆一次，就可使用多个SSO enable的应用系统。
（1）、单一的登陆点。
理想的情况是用户通过任何应用系统都能进行SSO，这对于基于Web的系统是可行的。
这种单一的登陆点在整个系统的设计中是唯一认证用户的地方，由登陆点将SSO token（针对不同的C/S，B/S应用可能还需要传递用户名，口令）传递给应用系统，应用系统利用SSO token来进行用户已认证的验证。
我们将这个单一的登陆点称为SSO Entry。
（2）、SSO enable意味着对应用系统的修改不可避免。
并不是任何系统都能够使用SSO，只有那些符合SSO规范，使用SSO API的应用系统才具有SSO的功能。
简单地说就是要修改已有的应用系统，屏蔽已有的应用系统的用户认证模块，使用系统提供的SSO API来验证用户，以及对用户的操作进行授权。
（3）、需要统一的认证，权限信息库。
通常，认证与授权管理模块以一种应用专有的方式实现，系统的授权模型、认证，授权信息存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。
这种设计与实现方式的缺点是显而易见的：由于认证、授权模块与应用逻辑之间的紧耦合使得认证、授权模块很难进行扩展与维护；认证、授权模块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与重用。
这也是越来越多企业应用需要SSO的原因之一。
SSO要求有统一的认证，权限存放库。
但现实中，有的系统无法使用外部的认证，授权信息库，所以就需要在应用系统和Portal Server之间进行认证，同时进行授权信息的数据同步。
2、实现描述：在用户成功登录weblogic Portal之后，系统提供的Login Delegate机制来为用户登录到其有权可以使用的应用系统。
系统提供Logout Delegate机制实现用户的注销功能（即SSO logout）。
用户存取由Portal SSO保护的若干资源，SSO会话服务（Session/SSO Service）提供了授权的证明，这样就不再需要用户重新进行身份验证了。
在这种方式下，即使用户要访问不同的域（weblogic domain）的应用，我们提供的Portal SSO Service为其保持会话服务。
同时，SSO还包括的与登录恰恰相反的，统一的注销点，即用户一旦从Portal注销，则亦当从所有参与Portal SSO的应用注销。
SSO单点登录解决方案
SSO单点登录解决方案单点登录（SSO）是一种身份验证授权机制，允许用户在多个互联网应用程序和网站之间共享一个单一的登录凭据。
它通过一次认证，使用户能够在各个应用程序中访问受保护的资源，无需再次输入登录凭据。
以下是一个详细介绍SSO单点登录解决方案的文章，超过1200字。
引言：在现代的互联网时代，用户常常需要在多个应用程序和网站上进行登录。
这不仅使用户要记住多个不同的账号和密码，而且给用户带来了繁琐和不便。
为了解决这个问题，单点登录（SSO）技术应运而生。
什么是单点登录？单点登录（SSO）是一种身份验证和授权机制，允许用户一次登录凭据在多个应用程序和网站之间进行身份验证。
用户只需在一个应用程序上进行登录，便可以自由访问所有与之关联的应用程序，而无需再次输入登录凭据。
SSO解决方案的优点：1.提高用户体验：用户只需记住一个登录凭据，即可随意访问所有与之关联的应用程序，大大简化了用户的登录流程，提高了用户的便利性和满意度。
2.提高安全性：通过使用SSO解决方案，用户的登录凭据只需在一个可信的认证系统中验证，而不需要在每个应用程序中都输入凭据。
这减少了密码暴露的风险，并提高了系统的整体安全性。
3.简化管理：通过使用SSO解决方案，管理员可以轻松地管理应用程序和用户，而无需在每个应用程序中都进行独立的帐户管理。
减少了管理员的工作量，提高了管理效率。
4.降低成本：使用SSO解决方案可以减少密码重置和帐户管理等常见问题的费用。
此外，SSO解决方案还可以帮助组织简化其IT基础设施，减少硬件和软件的购买和维护成本。
SSO解决方案的实现方式：1.基于令牌的SSO：这种解决方案使用令牌来实现单点登录。
用户在登录到第一个应用程序时，会向认证服务器发送他们的凭据。
认证服务器会验证凭据的有效性，并生成一个令牌，并将该令牌返回给用户。
用户随后可以在其他应用程序上使用该令牌进行登录。
2.基于代理的SSO：这种解决方案使用代理服务器来实现单点登录。
单点登录实现方案
单点登录实现方案单点登录（Single Sign-On, 简称SSO）是一种用于企业内部系统和网络服务的身份验证解决方案。
它允许用户只需一次登录就能够访问多个相关的应用程序，提供了便捷和安全性。
本文将介绍几种常见的单点登录实现方案，探讨其优点和适用场景。
一、基于身份提供者的单点登录基于身份提供者的单点登录是一种常见的实现方案。
在这种方案中，用户只需通过一次身份验证就能够访问多个应用程序。
身份提供者在用户登录后生成一个令牌（Token），并将其发送给相关应用程序。
这样，用户在访问其他应用程序时只需将该令牌发送给应用程序，应用程序将验证该令牌的有效性，并授权用户访问相关资源。
优点：这种方案简化了用户的登录流程，提高了用户体验。
同时，身份提供者可以集中管理用户身份和权限，增强了安全性。
适用场景：该方案适用于企业内部网络和应用系统。
比如，一个企业内部拥有多个应用系统，员工只需通过一次登录就能够访问这些应用系统，方便了企业内部的业务流程。
二、基于代理服务器的单点登录基于代理服务器的单点登录是另一种常见的实现方案。
在这种方案中，代理服务器作为用户和应用程序之间的中间层，负责用户的身份验证和授权。
当用户访问一个应用程序时，代理服务器会首先验证用户的身份，并为用户生成一个令牌。
然后，代理服务器将令牌发送给应用程序，应用程序通过验证令牌来判断用户的身份和权限。
优点：这种方案可以灵活适应不同的应用程序和网络环境。
代理服务器可以根据不同的业务需求进行扩展和定制，提供更好的灵活性和安全性。
适用场景：该方案适用于企业内外网结合的环境。
企业可以在内部网络搭建代理服务器，实现对内外网应用程序的统一管理和安全控制。
三、基于标准协议的单点登录基于标准协议的单点登录是一种开放式的实现方案。
在这种方案中，使用标准协议来实现不同系统之间的认证和授权。
常见的标准协议包括OAuth和OpenID Connect等。
用户通过登录认证服务器后，认证服务器会生成一个授权码，再通过用户的许可，将授权码发送给应用程序。
单点登录的3种实现方式
单点登录的3种实现方式单点登录（Single Sign-On，简称SSO）是一种在多个应用系统中，用户只需要一次登录就可以访问所有相互信任的应用系统的认证方式。
实现SSO有多种方式，下面将介绍三种常用的实现方式。
1.基于令牌的实现方式：基于令牌的SSO是目前应用较广泛的一种方式。
在这种方式中，用户登录成功后，一个包含用户认证信息的令牌会被生成，并存储在服务端。
在用户访问其他应用系统时，该令牌会被传递给其他应用系统进行验证。
应用系统收到令牌后，会到服务端验证令牌的有效性，如果验证通过，用户就可以在该应用系统中访问受保护资源。
这种方式的优点是简单易懂，不需要在应用系统中存储用户的认证信息，而且可以避免跨域访问的安全问题。
但是该方式需要依赖于服务端的共享存储，令牌的传递也会带来一定的网络开销。
2.基于身份提供者的实现方式：基于身份提供者的SSO是一种将认证过程交由专门的身份提供者来完成的方式。
在这种方式中，用户登录的请求首先发送到身份提供者。
身份提供者会验证用户的身份，并生成一个用户的认证凭证，然后将该凭证发送给应用系统。
应用系统接收到凭证后，会向身份提供者验证凭证的有效性。
如果验证通过，用户就可以在该应用系统中访问受保护资源。
这种方式的优点是可以集中管理用户的身份认证，减轻了应用系统的认证工作量。
同时，身份提供者还可以提供其他的安全特性，比如多因素认证、账号锁定等。
但是该方式需要依赖于身份提供者的稳定性和性能。
3.基于代理的实现方式：基于代理的SSO是一种通过代理服务器来实现的方式。
在这种方式中，用户在登录成功后，代理服务器会为用户生成一个会话标识，并将该会话标识存储在共享存储中。
用户在访问其他应用系统时，首先会发送一个从代理服务器获取会话标识的请求。
代理服务器验证用户的身份，并根据用户是否已经登录，决定是否颁发一个有效的会话标识给用户。
用户在访问其他应用系统时，会将会话标识附加在请求中。
应用系统在收到请求后，会向代理服务器验证会话标识的有效性。
单点登录的几种实现代码
单点登录的几种实现代码单点登录（Single Sign-On，简称SSO）是一种身份验证技术，允许用户使用一组凭据登录多个相关但独立的系统。
以下是几种实现单点登录的常见方法的代码示例：1. SAML（Security Assertion Markup Language）实现SSO：```java// Service Provider端public class ServiceProvider {public boolean authenticate(String username, String password) { // 身份验证逻辑}public void ssoRedirect(String idpUrl, String relayState) {// 构建SAML请求// 发送重定向请求到IdP}public void handleResponse(HttpServletRequest request) {// 解析SAML响应// 验证响应的签名// 获取用户信息}}// Identity Provider端public class IdentityProvider {public boolean authenticate(String username, String password) { // 身份验证逻辑}public void handleSSO(HttpServletRequest request) {// 解析SAML请求// 构建SAML响应// 签名响应// 发送响应到SP}}```2. OAuth 2.0 实现 SSO：```java// 授权服务器端public class AuthorizationServer {public String generateAuthorizationCode() {// 生成授权码}public String generateAccessToken() {// 生成访问令牌}public void authorize(HttpServletRequest request, HttpServletResponse response) {// 校验客户端身份String authorizationCode = generateAuthorizationCode();String redirectUri = request.getParameter("redirect_uri"); // 重定向到客户端指定的 redirect_uri，并携带授权码 }public void issueAccessToken(HttpServletRequest request, HttpServletResponse response) {// 校验授权码String accessToken = generateAccessToken();// 返回访问令牌}}// 客户端（资源服务器）端public class ClientServer {public void accessToken(HttpServletRequest request, HttpServletResponse response) {// 发送认证请求到授权服务器// 获取访问令牌}public void processResource(HttpServletRequest request, HttpServletResponse response) {// 处理资源请求}}```3. JWT（JSON Web Tokens）实现 SSO：```java// 认证服务器端public class AuthenticationServer {public String generateToken(String userId) {// 生成 JWT}public void authenticate(HttpServletRequest request, HttpServletResponse response) {// 身份验证逻辑String userId = "123";String token = generateToken(userId);// 返回 JWT}}// 资源服务器端public class ResourceServer {public void processResource(HttpServletRequest request, HttpServletResponse response) {// 处理资源请求String token = request.getHeader("Authorization");// 验证 JWT，提取用户信息}}```请注意，这些示例仅用于说明不同方法的实现，实际的代码实现可能因应用的需求和技术栈而有所不同。
单点登录sso的实现原理
单点登录SSO（Single Sign-On）是一种实现跨应用程序认证的技术，其核心原理在于用户只需要登录一次便可访问多个应用，而不必重复登录。
下面我们将详细介绍单点登录实现原理。
第一段，介绍单点登录的背景及意义。
随着企业信息化的深入，各类软件系统和应用互相交织，已成为现代化企业的必备设施。
但同时，如何解决多系统间的用户认证问题却成为很多企业面临的问题。
单点登录技术通过一次登录便可访问不同系统，大大简化了认证流程，提高了用户体验，降低了企业的安全风险。
第二段，介绍单点登录实现的三种方式，包括Cookie传递、Session共享和Token传递。
Cookie传递指的是在用户访问第一个应用并登录后，该应用会将一个特定的Cookie存储在用户浏览器上。
当用户访问其他应用时，这些应用将从Cookie中获取用户信息。
Session共享则是将第一个应用程序中的session_id传递到其他应用程序，以共享登录状态。
Token传递是通过专用的Token机制，在不同应用程序之间传递一个Token，以获取用户信息。
第三段，讲述OAuth 2.0认证流程。
OAuth 2.0是现代企业Web认证流程的主流方式，其基于Token的方式支持多种应用间的单点登录。
OAuth 2.0认证流程分为四个步骤：授权请求、用户授权、颁发访问令牌和使用访问令牌。
在这个过程中，可以实现多个应用程序间的用户身份认证。
第四段，介绍OpenID Connect的工作原理。
OpenID Connect是构建于OAuth 2.0协议之上的认证体系，通过在OAuth 2.0的基础上增加标准化的身份验证方案，为企业提供了一种基于Web的单点登录解决方案。
OpenID Connect的核心原理在于通过一个认证服务器获取用户的身份信息，存储在ID Token中，然后发送给客户端应用，以实现用户身份认证。
第五段，讲述单点登录的优点和缺点。
单点登录技术能够带来很多好处，如提高用户体验、提高安全性和降低成本等。
java 单点登录实现方案
java 单点登录实现方案Java单点登录（Single Sign-On，简称SSO）是一种身份验证机制，允许用户使用一组凭据（如用户名和密码）登录到多个相关的应用程序或系统，而无需在每个应用程序中单独进行身份验证。
本文将介绍Java单点登录的实现方案。
在实现Java单点登录时，可以采用以下方案：1. 基于Token的认证方案：这是目前较为常见的单点登录实现方案之一。
用户在登录成功后，后台生成一个Token，将其返回给用户，并存储在服务器端。
用户在访问其他应用程序时，将Token作为身份凭证发送到服务器端进行验证。
服务器端通过验证Token的有效性来判断用户的身份。
常见的Token生成方式包括JWT（JSON Web Token）和OAuth2.0。
2. 基于代理的认证方案：该方案使用一个代理服务器来处理用户的身份验证。
用户在登录成功后，代理服务器会为用户生成一个身份标识，并将其存储在Cookie中。
当用户访问其他应用程序时，请求会先发送到代理服务器，代理服务器会验证用户的身份，并将请求转发给相应的应用程序。
3. 基于Session的认证方案：该方案使用Java的Session机制来实现单点登录。
用户在登录成功后，后台会为用户创建一个Session，并将Session的ID存储在Cookie中。
当用户访问其他应用程序时，应用程序会通过Cookie中的Session ID来验证用户的身份。
无论采用哪种方案，Java单点登录的实现步骤大致相同：1. 用户登录：用户在登录页面输入用户名和密码进行登录。
后台验证用户的凭据是否正确，如果正确则进行下一步操作。
2. 生成身份凭证：在用户登录成功后，后台会生成一个身份凭证（Token、身份标识或Session），并将其返回给用户。
3. 存储身份凭证：服务器端会将生成的身份凭证存储起来，可以存储在数据库、缓存或服务器内存中。
4. 跨应用程序身份验证：当用户访问其他应用程序时，应用程序会验证用户的身份凭证的有效性。
sso单点登录的几种实现方式
sso单点登录的几种实现方式
单点登录（SSO）是一种身份验证和授权的机制，允许用户仅需一次登录就可以访问多个应用程序。
以下是几种常见的SSO实现方式：
1. 基于共享 Cookie：在这种方式下，所有应用程序共享一个中心服务器，该服务器负责验证用户身份并颁发加密的Cookie。
用户登录后，Cookie会在不同的应用程序之间进行传递，以实现无需再次输入用户名和密码即可访问应用程序。
2. 基于令牌：这种方式下，用户成功登录后，认证服务器会颁发一个令牌给用户。
该令牌包含用户身份信息和权限验证。
用户在访问其他应用程序时，只需要将令牌发送给认证服务器验证即可。
3. 基于身份提供商（Identity Provider）：也称为Federation SSO，这种方式下，企业或组织委托第三方身份提供商来管理用户身份验证。
用户登录时，会被重定向到身份提供商进行验证，验证成功后，身份提供商会向应用程序提供一个供其验证用户身份的令牌。
4. 基于OAuth协议：OAuth是一个开放标准的授权协议，被广泛应用于SSO。
它允许用户使用第三方应用程序（被称为客户端）代表用户请求访问受保护的资源，而无需提供第三方应用程序的用户名和密码。
用户登录成功后，授权服务器会颁发一个访问令牌给客户端，客户端可以使用该令牌来访问受保护的资源。
这些实现方式可以根据具体的需求和系统架构选择使用。
统一门户与业务系统的sso整合技术方案（单点登录）
统⼀门户与业务系统的sso整合技术⽅案（单点登录）⼀、单点登录（SSO，Single Sign On）整合⽬前计划接⼊统⼀门户的所有业务系统均为基于JavaEE技术的B/S架构系统。
由于统⼀门户的单点登录技术选⽤的是JA-SIG组织开发的Cas Server，故为了与Cas Server进⾏⽆缝整合，各业务系统选⽤的技术依然是由JA-SIG组织开发的Cas Client。
根据各业务系统服务端技术架构的不同，现提供如下2种整合⽅式：1. 在web.xml中配置4个过滤器此⽅式适⽤于所有JavaWeb应⽤。
1) 所需jarcas-client-core-3.3.3.jarslf4j-api-1.7.1.jar2) 配置4个过滤器（其中两个可选）<filter><filter-name>CAS Authentication Filter</filter-name><filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class><init-param><param-name>casServerLoginUrl</param-name><param-value>http://CAS_SERVER/cas-server/login</param-value></init-param><init-param><param-name>serverName</param-name><param-value>http://CAS_CLIENT</param-value></init-param></filter><filter-mapping><filter-name>CAS Authentication Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping><!-- 使⽤CAS 2.0协议校验票据 --><filter><filter-name>CAS Validation Filter</filter-name><filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class><init-param><param-name>casServerUrlPrefix</param-name><param-value>http://CAS_SERVER/cas-server</param-value></init-param><init-param><param-name>serverName</param-name><param-value>http://CAS_CLIENT</param-value></init-param></filter><filter-mapping><filter-name>CAS Validation Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping><!-- 包装了HttpServletRequest, 使得可以通过getRemoteUser()和getPrincipal()可以返回CAS相关⼊⼝ --><filter><filter-name>CAS HttpServletRequest Wrapper Filter</filter-name><filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class></filter><filter-mapping><filter-name>CAS HttpServletRequest Wrapper Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping>说明：<1> 可选配置。
单点登录原理及操作方法
单点登录原理及操作方法
单点登录（Single Sign-On，简称SSO）是一种身份验证的方法，允许用户通过一次登录就可以访问多个关联的应用程序、系统或资源而无需重复输入凭据。
单点登录的原理如下：
1. 用户登录：用户通过输入用户名和密码登录到主SSO系统。
2. 验证身份：主SSO系统验证用户的凭据是否有效。
3. 创建会话：验证通过后，主SSO系统为用户创建一个会话，并生成一个唯一的令牌（Token）。
4. 令牌分发：主SSO系统将令牌发送给用户的浏览器。
5. 应用访问：当用户访问关联的应用程序时，浏览器将令牌作为身份验证凭据发送给应用程序。
6. 验证令牌：应用程序接收到令牌后，将其发送给主SSO系统进行验证。
7. 授权访问：主SSO系统验证令牌后，确认用户的身份，并向应用程序授权用户访问权限。
8. 应用登录：应用程序根据用户的授权信息，允许用户访问相应的资源。
操作方法如下：
1. 在SSO系统中注册用户信息，并将其与关联的应用程序进行绑定。
2. 用户通过SSO系统登录，并获取到令牌。
3. 用户访问关联的应用程序时，将令牌发送给应用程序进行验证和授权。
4. 应用程序根据验证结果和授权信息，决定是否允许用户访问。
5. 用户在SSO系统中登出时，会话和令牌会被销毁，用户需要重新登录。
总结来说，单点登录通过一次登录后获取的令牌进行身份验证和授权，实现了用户在多个应用程序间的无缝访问。
这样能够提高用户体验、简化用户登录过程，并增加应用程序之间的安全性。
单点登录的实现原理
单点登录的实现原理嘿，你有没有想过，在这个信息爆炸的时代，我们每天要登录各种各样的系统，什么社交媒体账号、办公软件、网上银行等等。
每次登录都要输入用户名和密码，是不是感觉特别麻烦？要是有个魔法，能让我们只登录一次，就能畅游所有这些系统，那该多好啊！其实啊，这种魔法是存在的，它就叫单点登录（SSO）。
那单点登录到底是怎么实现这个神奇功能的呢？这就像是一场精心编排的舞蹈，每个参与者都有自己的角色。
我们先来说说身份提供者（IdP）。
这个身份提供者就像是一个大管家，它掌管着所有用户的身份信息。
比如说，在一个大型企业里，这个身份提供者可能是企业内部的一个专门的服务器。
它知道每个员工的用户名、密码，还有其他一些身份相关的信息。
当用户第一次登录某个系统的时候，这个系统就会把用户引导到身份提供者那里。
这就好比你去一个高档小区拜访朋友，门口的保安不会直接让你进去，而是把你带到物业管理处，让他们核实你的身份。
身份提供者会要求用户输入用户名和密码。
这一步很关键，就像是在一个神秘的城堡前，你要说出正确的口令才能进入。
如果用户输入的信息是正确的，身份提供者就会给用户颁发一个“通行证”。
这个“通行证”可不是普通的纸条，它是一种特殊的加密令牌，里面包含了用户的身份信息，但又经过了加密处理，就像一个神秘的密码盒，只有特定的系统才能解读它。
那这个“通行证”怎么在各个系统之间通用呢？这就涉及到各个系统和身份提供者之间的信任关系了。
各个系统就像是一个个独立的小王国，它们要信任身份提供者这个“大管家”。
当用户拿着“通行证”来到另一个系统的时候，这个系统会把“通行证”送到身份提供者那里进行验证。
这就好比你拿着物业管理处给的访客证去小区里的其他地方，每个地方的管理员都会打电话到物业管理处确认你的身份。
我有个朋友小明，他在一家跨国公司工作。
公司内部有很多不同的业务系统，以前每次登录不同的系统都要输入账号密码，他经常抱怨说这简直是浪费生命。
后来公司采用了单点登录系统。