SSO 原理浅谈
- 格式:doc
- 大小:623.50 KB
- 文档页数:13
单点登录拦截原理单点登录(Single Sign-On,简称SSO)拦截原理主要基于客户端/服务端架构,具体实现过程如下:1. SSO客户端拦截未登录请求:SSO客户端通过拦截未登录用户请求的方式,将用户引导至SSO认证中心进行登录操作。
Java中可以采用servlet、filter、listener三种方式拦截请求,这里我们采用filter方式。
2. SSO客户端接收并存储令牌:SSO客户端在用户登录成功后,接收并存储由SSO认证中心发送的令牌。
3. SSO客户端与SSO服务器通信:SSO客户端使用令牌与SSO服务器进行通信,校验令牌的有效性。
4. 建立局部会话:SSO客户端在验证令牌有效后,建立局部会话,以便后续对用户请求进行拦截和校验。
5. 拦截用户注销请求:SSO客户端拦截用户的注销请求,并向SSO认证中心发送注销请求。
6. 接收注销请求并销毁局部会话:SSO客户端接收SSO认证中心发出的注销请求,销毁局部会话,完成用户的注销操作。
7. SSO服务器验证用户登录信息:SSO服务器验证用户的登录信息,确保用户已成功登录。
8. 创建全局会话和授权令牌:SSO服务器创建全局会话,并生成授权令牌。
9. SSO服务器与SSO客户端通信发送令牌:SSO服务器将授权令牌发送给SSO客户端,供后续请求校验使用。
10. 校验SSO客户端令牌有效性:SSO服务器校验SSO客户端的令牌有效性,确保用户已成功登录并具有访问权限。
11. 系统注册:SSO服务器接收并存储SSO客户端的注册信息,以便后续管理。
12. 接收SSO客户端注销请求并注销所有会话:当用户选择注销时,SSO 客户端向SSO服务器发送注销请求。
SSO服务器接收请求后,注销所有与该用户相关的会话和令牌。
通过以上步骤,单点登录系统实现了对用户请求的拦截、校验和注销管理,确保了用户在多个应用系统中的单点登录和统一管理。
单点登录技术方案介绍单点登录(SSO)是一种身份验证和授权技术,允许用户只需一次登录即可访问多个相关系统和应用程序。
这减少了用户需要记住多个用户名和密码的负担,提高了系统的易用性和安全性。
本文将介绍单点登录技术的工作原理和常见的实现方案,以及其在企业应用中的优势和挑战。
工作原理单点登录的工作原理基于令牌(Token)的概念。
当用户成功登录主认证系统后,主认证系统会生成一个令牌并将其发送给用户的浏览器。
该令牌包含了用户的身份信息和有效期限等相关信息。
当用户尝试访问其他关联系统时,这些系统会将用户重定向到主认证系统,并携带令牌作为参数。
主认证系统收到请求后,验证令牌的合法性和有效期限。
如果令牌有效,主认证系统会向关联系统发送一个授权凭证,允许用户访问特定资源。
用户的浏览器将授权凭证传递给关联系统,以完成身份验证和授权过程。
实现方案基于Cookie的实现方案基于Cookie的单点登录是最常见的实现方式之一。
主认证系统在用户成功登录后,生成一个包含用户身份信息的加密Cookie,并将其发送给浏览器。
当用户尝试访问其他关联系统时,这些系统会在用户的浏览器中查找该Cookie,并验证其合法性和有效期。
如果Cookie有效,关联系统会完成身份验证,并允许用户访问特定资源。
由于Cookie存储在用户的浏览器中,因此存在一定的安全风险。
为了增强安全性,可以使用加密和签名技术对Cookie进行保护,防止被篡改或伪造。
基于Token的实现方案基于Token的单点登录是一种无状态的实现方式。
主认证系统在用户成功登录后,生成一个包含用户身份信息的令牌,并将其发送给浏览器。
令牌通常使用JSON Web令牌(JWT)的格式进行编码,包含了用户身份信息、有效期限等相关信息。
用户在访问其他关联系统时,将令牌作为参数携带在请求中。
关联系统在接收到请求后,通过验证令牌的合法性和有效期,完成身份验证和授权过程。
基于Token的单点登录相对于基于Cookie的实现更加安全,因为令牌不存储在用户的浏览器中,且可以通过加密和签名技术进行保护。
sso登录原理SSO(Single Sign-On)即单点登录,是一种允许用户使用一组凭证(例如用户名和密码)访问多个相关但独立的系统的身份验证机制。
SSO的原理是通过将用户认证信息保存在一个中央身份验证服务器上,然后在用户访问其他系统时,这些系统将向中央服务器发送身份验证请求,并根据返回的结果决定是否授权用户访问。
SSO的实现原理如下:1. 用户访问一个需要身份验证的应用程序,例如一个在线商城。
用户尚未登录,因此被重定向到身份验证服务器。
2. 身份验证服务器向用户展示一个登录页面,要求用户输入其凭证信息,例如用户名和密码。
3. 用户输入凭证信息后,身份验证服务器会验证这些凭证信息的有效性。
验证的方式可以是通过比对用户提供的凭证信息与事先存储在身份验证服务器上的用户凭证信息,或者通过与其他身份验证机制(如LDAP或Active Directory)进行通信来验证凭证信息。
4. 如果凭证信息有效,身份验证服务器将生成一个令牌(Token),该令牌包含有关用户身份的信息,并将其发送回给用户的浏览器。
5. 用户的浏览器将令牌保存在本地存储中,例如Cookie或本地存储。
6. 用户再次访问其他需要身份验证的应用程序时,浏览器将自动附加保存的令牌信息。
应用程序收到令牌后,将其发送给身份验证服务器以进行验证。
7. 身份验证服务器验证令牌的有效性,并确认该用户已通过身份验证。
如果令牌有效,身份验证服务器将向应用程序发送授权令牌,以确认用户的身份。
8. 应用程序接受授权令牌,并向用户授予访问权限。
用户可以在不需要重新输入凭证信息的情况下访问应用程序。
通过上述过程,用户只需要登录一次,就可以访问多个相关应用程序,实现了单点登录的目标。
这种机制不仅方便了用户,还提高了用户体验,并减轻了系统管理员的工作负担。
SSO的实现可以采用不同的协议和技术,常见的有基于令牌的SSO 和基于身份提供者的SSO。
基于令牌的SSO通常使用JSON Web Token(JWT)或Security Assertion Markup Language(SAML)等令牌格式来传递用户身份信息。
SSO实现方式深入浅出SSO,单一登录(single sign-on),意思是指在多套系统并存的环境下,用户只需登录一次即可访问其他授权的系统。
提起SSO(单一登录),大概企业里的IT人员无人不知,但真正意识到其复杂度的,未必有多少,只有亲身实施过的技术人员,也许才明白个中玄妙。
本文基于蓝凌为国内几十家大中型企业的服务案例,针对SSO的相关技术和案例进行一些探讨,希望能帮助到企业IT人员更深刻理解SSO技术及其应用。
一、企业级SSOSSO涉及的领域大致上可以分为三种:社会性网站间的SSO、部门SSO、企业级SSO。
社会性网站间的SSO主要涉及的帐号信息开放性问题,能否实施成功主要取决于各大网站帐号管理是否遵循相同的标准协议,如Openid、Passport等。
部门级SSO比较简单,一般涉及的系统不多,由技术人员通过编程方式实现即可,但一旦牵涉系统众多,安全性要求高的情况,就不适用了。
企业级SSO是三者中最复杂的领域,因涉及的系统可能五花八门,这些系统也许是老旧的C/S结构系统、可能是某种大型软件系统(如SAP),还可能是某种非web登录方式(如windows域登录);其安全性要求也远比前两者高,如要求同享登录有效时间等,因此企业级SSO在技术难度上是最高的,但也因此是IT人员最愿意钻研的领域。
而绝大部分国内企业,其内部系统常常因为历史原因导致多套系统缺乏统一规划,缺乏标准而导致整合代价高昂。
因此SSO也是许多大中型企业IT部门比较头疼的事情。
本文主要讨论的领域,就是企业级SSO。
二、深入企业级SSOSSO是一把双刃剑:SSO可以简化用户登录过程,提升用户的登录体验;同时可以降低IT管理员大量账户和密码维护成本;SSO还提供了符合萨班斯法案的密码集中管理工具;但SSO同时也产生了一种安全风险,某一系统用户身份一旦被攻破,则意味着所有参与SSO网络的应用系统也被穿透。
因此需要慎重考虑SSO的范围及安全级别的局限性。
SSO实现原理SSO实现原理图1、用户登录A系统,系统检查ticket.1.1有,提交认证中心验证,认真通过重定向A系统并返回USERNAME,A系统生成自己的Session.1.2无,提交LOGIN进行COOKIE检查,有则重定向返回A系统并TICKET,A系统生成自己的Session;无则重新登录重点:根据PORTAL服务器上的COOKIE判断用户是否登录过PORTAL, COOKIE里带有TICKET.2、其他系统重复此动作1. SSO需求单点登录(Single Sign On, SSO)是企业应用集成中最常见的需求。
异构系统间往往都有各自的用户管理和身份验证机制,为避免用户在进行系统切换时频繁输入用户名和密码,因此必须要实现单点登录。
2. SSO原理说到SSO的原理,先得说一般Web应用的身份验证原理。
Web身份验证之所以能成为问题主要在于HTTP协议的无状态性,这导致了每次HTTP的请求和响应的无关性。
而应用的状态保持是大部分应用系统的一般性需求,因此必须借助其他机制,这就是Cookie。
2.1. Cookie的原理一个Cookie由name、value、domain、path、expires组成。
可以给HTTP响应添加Cookie,然后Cookie就作为HTTP响应的Headers返回给浏览器,例如Domino的登录成功后的Cookie 响应头为:Set-Cookie: DomAuthSessId=1AD479C4D11CD10278A4C523320A6918; path=/没有设置expires就表示仅在当前浏览器进程生命期内有效,不保存到客户机上;若expires 时间大于当前时间,则浏览器在收到这个Cookie以后将其写入到客户机文件中,一般是保存在C:\Documents and Settings\Administrator\Cookies\下。
没有设置domain就表示只在当前域内有效。
单点登录解决方案引言随着互联网的快速发展,单点登录(Single Sign-On,SSO)已经成为各种网络应用中的常见需求。
单点登录指的是用户只需通过一次身份验证,即可在多个应用中访问和使用资源,而无需再次输入用户名和密码。
这大大提高了用户的使用体验,减轻了用户的负担。
本文将介绍单点登录的基本原理以及实现单点登录的常见解决方案。
基本原理单点登录的基本原理包括三个主要组成部分:身份提供者、服务提供者和用户。
身份提供者是负责用户身份验证和授权的服务,通常是一个独立的认证系统,如LDAP、Active Directory等。
服务提供者是各个应用系统,它们依赖于身份提供者来验证用户身份和授权。
用户是最终需要访问各个应用系统的个体。
在单点登录的过程中,当用户访问一个需要身份验证的应用系统时,该系统会将用户重定向到身份提供者进行身份验证。
一旦验证成功,身份提供者将生成一个令牌(Token),并将用户重定向回原始应用系统。
应用系统使用该令牌进行身份验证和授权,从而免除用户在每个应用系统中重复登录的繁琐过程。
解决方案1. 基于代理服务器的单点登录基于代理服务器的单点登录是一种简单且传统的解决方案。
该方案将所有应用系统的流量通过一个代理服务器进行转发,该代理服务器负责身份验证和授权。
用户在访问应用系统之前,需要先登录到代理服务器。
代理服务器通过验证用户的身份后,将用户请求转发到对应的应用系统,并将验证信息添加到请求中。
这种解决方案的优点是简单易用,无需对应用系统进行任何修改。
但是同时也存在一些限制,如需要单独设置代理服务器、影响网络性能等。
2. 基于令牌的单点登录基于令牌的单点登录方案将用户身份信息存储在令牌中,令牌在各个应用系统之间进行传递和验证。
当用户登录成功后,身份提供者会生成一个令牌,并将其返回给用户。
用户在访问其他应用系统时,将该令牌带上并提交到应用系统中进行验证。
这种解决方案的优点是实现相对较为简单,使用方便。
Keycloak 单点登录原理解析什么是单点登录?单点登录(Single Sign-On,简称 SSO)是一种身份认证和授权机制,允许用户使用一组凭据(如用户名和密码)登录到多个应用程序或系统中,而不需要在每个应用程序中单独进行身份验证。
在单点登录中,用户只需要登录一次,然后可以无缝地访问其他受信任的应用程序,而无需再次输入凭据。
Keycloak 简介Keycloak 是一个开源的身份和访问管理解决方案,可以为应用程序提供单点登录、身份验证和授权服务。
Keycloak 提供了一组 RESTful API 和前端界面,可以用于管理用户、角色、资源等。
它支持 OpenID Connect、OAuth 2.0 和 SAML 等标准协议,可以与各种应用程序和身份提供商集成。
Keycloak 的单点登录原理基于 OpenID Connect 和 OAuth 2.0 协议,下面将详细介绍其基本原理。
OpenID Connect 原理OpenID Connect(简称 OIDC)是建立在 OAuth 2.0 协议之上的身份认证协议,它扩展了 OAuth 2.0,添加了身份认证的功能。
OIDC 使用 JSON Web Token(JWT)作为身份令牌,以便在不同的应用程序之间传递和验证身份信息。
下面是 OpenID Connect 的基本原理:1.用户访问客户端应用程序,并尝试进行身份验证。
2.客户端应用程序将用户重定向到 Keycloak 的身份验证服务器。
3.用户在 Keycloak 的登录页面上输入用户名和密码。
4.Keycloak 验证用户的凭据,并生成一个身份令牌(ID Token)和访问令牌(Access Token)。
5.Keycloak 将身份令牌和访问令牌返回给客户端应用程序。
6.客户端应用程序使用身份令牌和访问令牌来验证用户的身份和访问权限。
7.客户端应用程序可以通过访问令牌来访问受保护的资源服务器。
sso系统介绍-概述说明以及解释1.引言1.1 概述部分应该对SSO系统进行简要介绍,让读者对该系统有一个初步的了解。
以下是概述的一个示例:概述单点登录(Single Sign-On,简称SSO)系统是一种身份验证和授权机制,用于简化用户在不同应用程序之间进行登录的流程。
通过SSO系统,用户只需一次登录,就可以在多个关联应用中进行访问和使用,无需重复输入用户名和密码。
SSO系统的出现是为了满足用户在当今数字化时代中面临的身份验证问题。
在传统的登录方式中,用户在每个应用程序中都需要单独进行登录,这不仅浪费时间,也容易导致繁琐的账号密码管理问题。
而SSO系统通过集成不同应用程序的登录认证,为用户提供了一种便捷、高效的身份验证机制。
相较于传统的登录方式,SSO系统具有许多优势。
首先,用户只需记住一个统一的登录凭证,大大减轻了用户的记忆负担。
其次,SSO系统可以提供更高的安全性,通过集成多种身份验证措施和安全策略,确保用户的身份和数据得到有效保护。
此外,SSO系统还能提高用户的使用便捷性和体验,让用户可以方便地在不同应用中切换和共享数据。
在SSO系统中,存在一个身份提供者(Identity Provider,简称IdP)和一个或多个服务提供者(Service Provider,简称SP)。
用户首先在身份提供者上进行登录认证,成功后,便可以在多个服务提供者上访问相应的资源和功能。
SSO系统通过在应用程序之间传递身份凭证实现用户的无缝登录。
总而言之,SSO系统解决了多应用登录的繁琐问题,提供了一种高效便捷的身份验证机制,为用户提供了更好的使用体验和安全保障。
在接下来的章节中,本文将深入探讨SSO系统的定义和工作原理,以帮助读者全面了解这一身份管理解决方案。
1.2 文章结构文章结构:本文将从以下几个部分来介绍SSO系统。
首先,我们会在引言部分对SSO系统进行概述,包括它的基本概念和作用。
其次,我们将详细讲解文章的结构,以便读者能清晰地了解后续内容的组织方式。
sso方案SSO方案引言单点登录(Single Sign-On,简称SSO)是一种身份认证和授权的解决方案,允许用户在进行多个应用程序之间进行无缝的访问。
它的目标是通过使用一组凭据,例如用户名和密码,使用户可以一次登录即可访问多个应用程序。
本文将探讨单点登录的原理、优势以及如何实施一个SSO方案。
单点登录的原理和工作流程原理单点登录允许用户使用一组凭证登录到一个主要的身份提供者,然后再将这些凭证传递给其他相关的应用程序。
该身份提供者负责验证用户的身份,并提供一个令牌,用于作为凭证传递给其他应用程序。
工作流程1. 用户打开一个应用程序,并尝试进行登录。
2. 应用程序检测到用户未经身份验证,将用户重定向到身份提供者的登录页面。
3. 用户输入凭证并提交给身份提供者。
4. 身份提供者验证凭证,并为用户颁发一个令牌。
5. 身份提供者将令牌返回给应用程序。
6. 应用程序使用该令牌进行用户身份验证,并为用户授权访问。
7. 用户在其他相关应用程序上访问时,不需要重新登录,令牌将作为凭证传递给这些应用程序。
SSO的优势简化用户体验SSO方案通过一次登录即可访问多个应用程序,大大简化了用户登录和身份验证的流程。
用户无需为每个应用程序都记住不同的用户名和密码,只需要一次性登录即可。
提高安全性SSO方案使用标准的身份验证协议和加密算法,确保用户的凭证在传输过程中是安全的。
此外,由于用户只需登录一次,减少了输入密码的次数,降低了密码被攻击的风险。
降低开发和维护成本SSO方案可以减少多个应用程序中进行身份验证和授权的代码和逻辑。
这意味着开发人员可以专注于其他核心功能,提高了开发效率;同时,维护一个单独的身份提供者要比每个应用程序中都进行身份验证更简单和易于管理。
实施一个SSO方案的步骤步骤一:选择合适的身份提供者选择一个可靠和受信任的身份提供者非常重要。
身份提供者需要具备以下特点:- 提供标准的身份验证协议,如SAML或OAuth等。
单点登录的原理流程单点登录(Single Sign-On,简称SSO)是一种身份认证的解决方案,通过一次登录,用户可以在多个应用系统中进行访问和操作,而无需重复输入登录凭证。
单点登录的原理流程主要包括身份认证、令牌传递和会话管理三个步骤。
一、身份认证在单点登录的流程中,首先需要进行身份认证。
用户通过输入用户名和密码进行登录,系统验证用户的身份信息,并生成一个身份令牌。
该令牌用于标识用户的身份,通常使用加密算法保证令牌的安全性。
二、令牌传递在用户进行跨系统访问时,单点登录系统将用户的身份令牌传递给其他应用系统。
这个过程中,通常使用一种称为令牌传递的方式。
令牌传递可以通过多种方式实现,如URL传递、表单传递、HTTP 头传递等。
其中,最常用的方式是通过URL传递,将令牌作为参数附加在URL后面,发送给目标应用系统。
三、会话管理目标应用系统接收到身份令牌后,会使用该令牌进行用户身份验证。
验证通过后,系统会为用户创建一个会话,并将会话相关信息存储在服务器端。
会话信息可以包括用户ID、用户名、权限等。
同时,系统会为用户生成一个新的令牌,用于在该应用系统中进行后续操作。
在用户访问其他应用系统时,单点登录系统会根据用户的请求,验证用户的身份令牌。
验证通过后,单点登录系统会将用户重定向到目标应用系统,并将新的令牌传递给目标应用系统。
目标应用系统接收到令牌后,进行身份验证,并为用户创建一个新的会话。
通过以上流程,用户可以在不同的应用系统中进行访问和操作,而无需重复进行身份认证。
同时,单点登录系统可以实现对用户的统一管理,包括用户的注册、注销、密码重置等功能。
这样,用户可以方便地使用多个应用系统,提高了用户体验和工作效率。
需要注意的是,单点登录系统需要具备一定的安全机制来保护用户的身份信息。
例如,可以使用HTTPS协议进行通信,使用加密算法对用户的密码和身份令牌进行加密。
同时,单点登录系统还需要考虑会话的有效期和注销功能,以保证用户的账号安全。
单点登录方案随着互联网的发展和应用的广泛普及,人们使用各种各样的在线服务来满足他们的需求。
然而,随之而来的问题是,每个在线服务都需要用户进行独立的身份验证,这导致了繁琐的登录过程和大量的账户管理工作。
为了解决这个问题,单点登录(Single Sign-On,简称SSO)方案应运而生。
一、什么是单点登录(SSO)?单点登录是一种身份验证和访问控制的解决方案,通过一次登录获得对多个相关但独立的系统或应用的访问权限。
换句话说,用户只需要进行一次身份验证,就可以访问多个应用,而无需重复登录。
二、单点登录的工作原理在单点登录方案中,有三个主要的角色:身份提供者(Identity Provider,简称 IdP)、服务提供者(Service Provider,简称 SP)和用户。
1. 身份提供者(IdP):负责管理用户的身份信息,并为用户提供身份验证服务。
当用户尝试访问某个服务时,该服务会将用户重定向到身份提供者,并请求验证用户的身份。
2. 服务提供者(SP):其为用户提供服务的网站或应用程序,不直接管理用户的身份信息,而是依靠身份提供者进行身份验证。
3. 用户:通过身份提供者进行身份验证,并可以访问多个服务提供者。
具体的工作流程如下:1. 用户访问某个服务提供者的网站或应用程序。
2. 服务提供者检测用户未进行身份验证,将用户重定向到身份提供者。
3. 用户在身份提供者的登录页面进行身份验证。
4. 身份提供者验证用户的身份,并生成一个访问令牌(Token)。
5. 身份提供者将访问令牌发送给用户的浏览器。
6. 用户的浏览器将访问令牌发送给服务提供者。
7. 服务提供者接收到访问令牌后,验证其有效性,并为用户提供相应的服务。
三、单点登录的优势1. 方便性:用户只需进行一次登录,即可无缝访问多个应用,大大简化了登录流程,提高了用户体验。
2. 安全性:通过集中管理用户的身份信息,减少了密码泄漏和遗忘密码的风险。
同时,也便于对用户的访问进行监控和管理。
单点登录(SSO)一、SSO(单点登录)介绍SSO英文全称Single SignOn,单点登录。
SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。
它是目前比较流行的企业业务整合的解决方案之一。
实现机制当用户第一次访问应用系统1的时候,因为还没有登录,会被引导到认证系统中进行登录;根据用户提供的登录信息,认证系统进行身份校验,如果通过校验,应该返回给用户一个认证的凭据--ticket;用户再访问别的应用的时候就会将这个ticket带上,作为自己认证的凭据,应用系统接受到请求之后会把ticket送到认证系统进行校验,检查ticket的合法性。
如果通过校验,用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
下面对上图简要描述1.用户访问系统1的受保护资源,系统1发现用户未登录,跳转至sso认证中心,并将自己的地址作为参数2.sso认证中心发现用户未登录,将用户引导至登录页面3.用户输入用户名密码提交登录申请4.sso认证中心校验用户信息,创建用户与sso认证中心之间的会话,称为全局会话,同时创建授权令牌5.sso认证中心带着令牌跳转会最初的请求地址(系统1)6.系统1拿到令牌,去sso认证中心校验令牌是否有效7.sso认证中心校验令牌,返回有效,注册系统18.系统1使用该令牌创建与用户的会话,称为局部会话,返回受保护资源9.用户访问系统2的受保护资源10.系统2发现用户未登录,跳转至sso认证中心,并将自己的地址作为参数11.sso认证中心发现用户已登录,跳转回系统2的地址,并附上令牌12.系统2拿到令牌,去sso认证中心校验令牌是否有效13.sso认证中心校验令牌,返回有效,注册系统214.系统2使用该令牌创建与用户的局部会话,返回受保护资源用户登录成功之后,会与sso认证中心及各个子系统建立会话,用户与sso认证中心建立的会话称为全局会话,用户与各个子系统建立的会话称为局部会话,局部会话建立之后,用户访问子系统受保护资源将不再通过sso认证中心,全局会话与局部会话有如下约束关系1.局部会话存在,全局会话一定存在2.全局会话存在,局部会话不一定存在3.全局会话销毁,局部会话必须销毁2、注销单点登录自然也要单点注销,在一个子系统中注销,所有子系统的会话都将被销毁,用下面的图来说明sso认证中心一直监听全局会话的状态,一旦全局会话销毁,监听器将通知所有注册系统执行注销操作下面对上图简要说明1.用户向系统1发起注销请求2.系统1根据用户与系统1建立的会话id拿到令牌,向sso认证中心发起注销请求3.sso认证中心校验令牌有效,销毁全局会话,同时取出所有用此令牌注册的系统地址4.sso认证中心向所有注册系统发起注销请求5.各注册系统接收sso认证中心的注销请求,销毁局部会话6.sso认证中心引导用户至登录页面总结单点登录(SSO)的所有流程都介绍完了,原理大家都清楚了。
单点登录(SSO)详解背景在企业发展初期,企业使⽤的系统很少,通常⼀个或者两个,每个系统都有⾃⼰的登录模块,运营⼈员每天⽤⾃⼰的账号登录,很⽅便。
但随着企业的发展,⽤到的系统随之增多,运营⼈员在操作不同的系统时,需要多次登录,⽽且每个系统的账号都不⼀样,这对于运营⼈员来说,很不⽅便。
于是,就想到是不是可以在⼀个系统登录,其他系统就不⽤登录了呢?这就是单点登录要解决的问题。
单点登录英⽂全称Single Sign On,简称就是SSO。
它的解释是:在多个应⽤系统中,只需要登录⼀次,就可以访问其他相互信任的应⽤系统。
如图所⽰,图中有4个系统,分别是Application1、Application2、Application3、和SSO。
Application1、Application2、Application3没有登录模块,⽽SSO只有登录模块,没有其他的业务模块,当Application1、Application2、Application3需要登录时,将跳到SSO系统,SSO系统完成登录,其他的应⽤系统也就随之登录了。
这完全符合我们对单点登录(SSO)的定义。
技术实现在说单点登录(SSO)的技术实现之前,我们先说⼀说普通的登录认证机制。
如上图所⽰,我们在浏览器(Browser)中访问⼀个应⽤,这个应⽤需要登录,我们填写完⽤户名和密码后,完成登录认证。
这时,我们在这个⽤户的session中标记登录状态为yes(已登录),同时在浏览器(Browser)中写⼊Cookie,这个Cookie是这个⽤户的唯⼀标识。
下次我们再访问这个应⽤的时候,请求中会带上这个Cookie,服务端会根据这个Cookie找到对应的session,通过session来判断这个⽤户是否登录。
如果不做特殊配置,这个Cookie的名字叫做jsessionid,值在服务端(server)是唯⼀的。
同域下的单点登录⼀个企业⼀般情况下只有⼀个域名,通过⼆级域名区分不同的系统。
什么是SSO单点登陆(SSO,Single sign-on的缩写)。
一、SSO实现原理1、概念:SSO的一种偏向技术的说法:用户只需登陆一次,就可使用多个SSO enable的应用系统。
(1)、单一的登陆点。
理想的情况是用户通过任何应用系统都能进行SSO,这对于基于Web的系统是可行的。
这种单一的登陆点在整个系统的设计中是唯一认证用户的地方,由登陆点将SSO token(针对不同的C/S,B/S应用可能还需要传递用户名,口令)传递给应用系统,应用系统利用SSO token来进行用户已认证的验证。
我们将这个单一的登陆点称为SSO Entry。
(2)、SSO enable意味着对应用系统的修改不可避免。
并不是任何系统都能够使用SSO,只有那些符合SSO规范,使用SSO I的应用系统才具有SSO的功能。
简单地说就是要修改已有的应用系统,屏蔽已有的应用系统的用户认证模块,使用系统提供的SSO API来验证用户,以及对用户的操作进行授权。
(3)、需要统一的认证,权限信息库。
通常,认证与授权管理模块以一种应用专有的方式实现,系统的授权模型、认证,授权信息存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。
这种设计与实现方式的缺点是显而易见的:由于认证、授权模块与应用逻辑之间的紧耦合使得认证、授权模块很难进行扩展与维护;认证、授权模块的设计与编码需要很大的工作量,而且很难在不同的应用系统之间共享与重用。
这也是越来越多企业应用需要SSO的原因之一。
SSO要求有统一的认证,权限存放库。
但现实中,有的系统无法使用外部的认证,授权信息库,所以就需要在应用系统和Portal Server之间进行认证,同时进行授权信息的数据同步。
2、实现描述:在用户成功登录 weblogic Portal之后,系统提供的Login Delegate机制来为用户登录到其有权可以使用的应用系统。
系统提供Logout Delegate机制实现用户的注销功能(即SSO logout)。
统一身份认证原理统一身份认证(Single Sign-On,简称SSO)是一种认证机制,允许用户在访问多个应用程序或系统时只需登录一次,而不需要多次输入相同的凭据。
SSO 的原理基于以下核心概念:1. 认证中心(Authentication Authority):SSO 的核心是一个认证中心,也称为身份提供者(Identity Provider,IdP)。
认证中心负责验证用户的身份,并生成令牌(Token)以供其他应用程序使用。
2. 令牌(Token):用户在成功登录认证中心后,认证中心会生成一个令牌,通常是一个包含用户身份信息的加密字符串。
这个令牌用于表示用户已经通过身份验证,并且可以被传递给其他应用程序进行验证。
3. 单点登录(Single Sign-On):用户在第一次成功登录认证中心后,认证中心会创建一个会话,并将令牌传递给用户的浏览器。
当用户访问其他需要身份验证的应用程序时,浏览器会自动传递令牌给这些应用程序,从而实现单点登录。
4. 身份验证流程:当用户尝试访问一个需要身份验证的应用程序时,应用程序会检查用户是否已经有有效的令牌。
如果没有,用户将被重定向到认证中心进行身份验证。
认证中心验证用户身份后,生成新的令牌并将其返回给应用程序,用户可以继续访问应用程序。
5. 注销(Single Sign-Out):当用户注销或退出系统时,认证中心会通知所有相关的应用程序注销用户。
这确保用户的注销操作在所有应用程序中都生效。
6. 标准协议:SSO 的实现通常基于标准的身份认证协议,如OAuth(Open Authorization)、OpenID Connect、SAML(Security Assertion Markup Language)等。
这些协议定义了认证中心和应用程序之间的通信方式和数据格式。
总体而言,SSO 的原理是通过在用户登录成功后生成令牌,用户再次访问其他应用程序时,应用程序通过验证令牌来确认用户的身份,从而实现在多个应用程序之间的单点登录。
ssocas 原理
SSO(Single Sign On)即单点登录,是一种企业业务整合的解决方案,允许用户在多个应用系统中只需登录一次,就可以访问所有相互信任的应用系统。
CAS(Central Authentication Service)是一款为Web应用提供单点登录的开源框架。
CAS包含两个主要部分:
1.CAS Server:负责完成对用户的认证工作,需要独立部署,并处理用户名、密
码等凭证(Credentials)。
2.CAS Client:负责处理对客户端受保护资源的访问请求,当需要对请求方进行
身份认证时,它会重定向到CAS Server进行认证。
一旦认证成功,CAS Server会将用户名和密码放到session中,并添加一个证据,然后跳转到系统的主界面。
此后,客户端应用不再接受任何的用户名密码等Credentials。
CAS最基本的协议过程如下:
1.第一次登录系统,用户打开浏览器,通过地址请求受保护的资源。
2.CAS客户端会把请求自动的重定向到CAS服务器端。
3.CAS服务器端发现没有证据,就直接把CAS服务器的登录界面转到浏览器,
呈现给用户。
4.用户输入用户名和密码进行验证。
5.验证成功,CAS服务器会把用户名和密码放到session中,并添加一个证据,
然后跳转到系统的主界面。
通过这种方式,CAS实现了单点登录功能,简化了用户在多个系统之间的登录过程,提高了效率和便利性。
请注意,以上内容仅供参考,如需更详细的信息,建议查阅相关文献或咨询专业技术人员。
Java SSO 实现原理什么是 SSOSingle Sign-On(SSO)是一种身份验证和授权机制,允许用户使用一组凭据登录到多个相关但相互独立的应用程序或系统中。
SSO通过在用户登录到一个应用程序之后,无需再次输入凭据即可自动登录到其他应用程序,提供了更好的用户体验和便利性。
SSO 的基本原理SSO 的基本原理可以分为以下步骤:1.用户向 SSO 系统发起登录请求。
2.SSO 系统检查用户是否已经登录。
3.如果用户已经登录,则直接生成一个令牌(token)并返回给用户。
4.如果用户未登录,则要求用户进行身份验证。
5.用户提供正确的凭据后,SSO 系统会验证并生成一个令牌(token)。
6.用户将该令牌(token)发送给要访问的应用程序。
7.应用程序接收到令牌后,将其发送给 SSO 系统进行验证。
8.验证通过后,应用程序会为用户创建一个本地会话,并将该会话与令牌关联起来。
9.用户在其他相关应用程序中访问时,只需携带令牌即可自动登录。
下面详细解释每个步骤:1. 用户向 SSO 系统发起登录请求用户在浏览器中输入 SSO 系统的 URL,并点击登录按钮,向 SSO 系统发起登录请求。
2. SSO 系统检查用户是否已经登录SSO 系统接收到用户的登录请求后,首先会检查用户是否已经登录。
如果用户已经登录,则直接进入第6步;如果用户未登录,则进入第4步。
3. 如果用户已经登录,则直接生成一个令牌并返回给用户如果用户已经在 SSO 系统中登录过,那么系统会为该用户生成一个令牌,并将其返回给用户。
这个令牌是一个加密的字符串,用于标识该用户的身份。
4. 如果用户未登录,则要求用户进行身份验证如果用户未在 SSO 系统中登录过,那么系统会要求用户进行身份验证。
通常情况下,这需要输入用户名和密码等凭据来验证身份。
5. 用户提供正确的凭据后,SSO 系统会验证并生成一个令牌当用户提供了正确的凭据后,SSO 系统会对其进行验证。
SSO 原理浅谈SSO 是一个非常大的主题,我对这个主题有着深深的感受,自从广州UserGroup 的论坛成立以来,无数网友都在尝试使用开源的CAS ,Kerberos 也提供另外一种方式的SSO ,即基于Windows 域的SSO ,还有就是从2005 年开始一直兴旺不衰的SAML 。
如果将这些免费的SSO 解决方案与商业的Tivoli 或Siteminder 或RSA Secure SSO 产品做对比,差距是存在的。
毕竟,商业产品的安全性和用户体验都是无与伦比的,我们现在提到的SSO ,仅仅是Web SSO ,即Web-SSO 是体现在客户端;另外一种SSO 是桌面SSO ,例如,只需要作为Administrator 登录一次windows 2000 ,我便能够在使用MSN/QQ 的时候免去登录的环节( 注意,这不是用客户端软件的密码记忆功能) ,是一种代理用户输入密码的功能。
因此,桌面SSO 是体现在OS 级别上。
今天,当我们提起SSO 的时候,我们通常是指Web SSO ,它的主要特点是,SSO 应用之间走Web 协议( 如HTTP/SSL) ,并且SSO 都只有一个登录入口。
简单的SSO 的体系中,会有下面三种角色:1 ,User (多个)2 ,Web 应用(多个)3 ,SSO 认证中心(1 个)虽然SSO 实现模式千奇百怪,但万变不离其宗:l Web 应用不处理User 的登录,否则就是多点登陆了,所有的登录都在SSO 认证中心进行。
l SSO 认证中心通过一些方法来告诉Web 应用当前访问用户究竟是不是张三/ 李四。
l SSO 认证中心和所有的Web 应用建立一种信任关系,SSO 认证中心对用户身份正确性的判断会通过某种方法告之Web 应用,而且判断结果必须被Web 应用信任。
2. CAS 的基本原理CAS(Central Authentication Service) 是Yale 大学发起的一个开源项目,据统计,大概每10 个采用开源构建Web SSO 的Java 项目,就有8 个使用CAS 。
对这些统计,我虽然不以为然,但有一点可以肯定的是,CAS 是我认为最简单实效,而且足够安全的SSO 选择。
本节主要分析CAS 的安全性,以及为什么CAS 被这样设计,带着少许密码学的基础知识,我希望有助于读者对CAS 的协议有更深层次的理解。
2.1 CAS 的结构体系从结构体系看,CAS 包含两部分:l CAS ServerCAS Server 负责完成对用户的认证工作,CAS Server 需要独立部署,有不止一种CAS Server 的实现,Yale CAS Server 和ESUP CAS Server 都是很不错的选择。
CAS Server 会处理用户名/ 密码等凭证(Credentials) ,它可能会到数据库检索一条用户帐号信息,也可能在XML 文件中检索用户密码,对这种方式,CAS 均提供一种灵活但同一的接口/ 实现分离的方式,CAS 究竟是用何种认证方式,跟CAS 协议是分离的,也就是,这个认证的实现细节可以自己定制和扩展。
l CAS ClientCAS Client 负责部署在客户端(注意,我是指Web 应用),原则上,CAS Client 的部署意味着,当有对本地Web 应用的受保护资源的访问请求,并且需要对请求方进行身份认证,Web 应用不再接受任何的用户名密码等类似的Credentials ,而是重定向到CAS Server 进行认证。
目前,CAS Client 支持(某些在完善中)非常多的客户端,包括Java 、 .Net 、ISAPI 、Php 、Perl 、uPortal 、Acegi 、Ruby 、VBScript 等客户端,几乎可以这样说,CAS 协议能够适合任何语言编写的客户端应用。
2.2 CAS 协议剖析协议就像剖析设计模式,有些时候,协议让人摸不着头脑。
CAS 的代理模式要相对复杂一些,它引入了一些新的概念,我希望能够在这里描述一下其原理,有助于读者在配置和调试CAS SSO 有更清晰的思路。
如果没记错,CAS 协议应该是由Drew Mazurek负责可开发的,从CAS v1 到现在的CAS v3 ,整个协议的基础思想都是基于Kerberos 的票据方式。
CAS v1 非常原始,传送一个用户名居然是”yes\ndavid.turing” 的方式,CAS v2 开始使用了XML 规范,大大增强了可扩展性,CAS v3 开始使用AOP 技术,让Spring 爱好者可以轻松配置CAS Server 到现有的应用环境中。
CAS 是通过TGT(Ticket Granting Ticket) 来获取ST(Service Ticket) ,通过ST 来访问服务,而CAS 也有对应TGT ,ST 的实体,而且他们在保护TGT 的方法上虽然有所区别,但是,最终都可以实现这样一个目的——免去多次登录的麻烦。
下面,我们看看CAS 的基本协议框架:2.1.1 基础协议CAS 基础模式上图是一个最基础的CAS 协议,CAS Client 以Filter 方式保护Web 应用的受保护资源,过滤从客户端过来的每一个Web 请求,同时,CAS Client 会分析HTTP 请求中是否包请求Service Ticket( 上图中的Ticket) ,如果没有,则说明该用户是没有经过认证的,于是,CAS Client 会重定向用户请求到CAS Server (Step 2 )。
Step 3 是用户认证过程,如果用户提供了正确的Credentials ,CAS Server 会产生一个随机的ServiceTicket ,然后,缓存该Ticket ,并且重定向用户到CAS Client (附带刚才产生的Service Ticket ),Service Ticket 是不可以伪造的,最后,Step 5 和Step6 是CAS Client 和CAS Server 之间完成了一个对用户的身份核实,用Ticket 查到Username ,因为Ticket 是CAS Server 产生的,因此,所以CAS Server 的判断是毋庸置疑的。
该协议完成了一个很简单的任务,就是User(david.turing) 打开IE ,直接访问helloservice 应用,它被立即重定向到CAS Server 进行认证,User 可能感觉到浏览器在helloservcie 和casserver 之间重定向,但User 是看不到,CAS Client 和CAS Server 相互间的Service Ticket 核实(Validation) 过程。
当CAS Server 告知CAS Client 用户Service Ticket 对应确凿身份,CAS Client 才会对当前Request 的用户进行服务。
2.2.2 CAS 如何实现SSO当我们的Web 时代还处于初级阶段的时候,SSO 是通过共享cookies 来实现,比如,下面三个域名要做SSO :如果通过CAS 来集成这三个应用,那么,这三个域名都要做一些域名映射,因为是同一个域,所以每个站点都能够共享基于 的cookies 。
这种方法原始,不灵活而且有不少安全隐患,已经被抛弃了。
CAS 可以很简单的实现跨域的SSO ,因为,单点被控制在CAS Server ,用户最有价值的TGC-Cookie 只是跟CAS Server 相关,CAS Server 就只有一个,因此,解决了cookies 不能跨域的问题。
回到CAS 的基础协议图,当Step3 完成之后,CAS Server 会向User 发送一个Ticket granting cookie (TGC) 给User 的浏览器,这个Cookie 就类似Kerberos 的TGT ,下次当用户被Helloservice2 重定向到CAS Server 的时候,CAS Server 会主动Get 到这个TGC cookie ,然后做下面的事情:1,如果User 的持有TGC 且其还没失效,那么就走基础协议图的Step4 ,达到了SSO 的效果。
2,如果TGC 失效,那么用户还是要重新认证( 走基础协议图的Step3) 。
2.2.2 CAS 的代理模式模式1 已经能够满足大部分简单的SSO 应用,现在,我们探讨一种更复杂的情况,即用户访问helloservice ,helloservice 又依赖于helloservice2 来获取一些信息,如同:User à helloservice à helloservice2这种情况下,假设helloservice2 也是需要对User 进行身份验证才能访问,那么,为了不影响用户体验(过多的重定向导致User 的IE 窗口不停地闪动) ,CAS 引入了一种Proxy 认证机制,即CAS Client 可以代理用户去访问其它Web 应用。
代理的前提是需要CAS Client 拥有用户的身份信息( 类似凭据) 。
与其说之前我们提到的TGC 是用户持有对自己身份信息的一种凭据,则这里的PGT 就是CAS Client 端持有的对用户身份信息的一种凭据。
凭借TGC ,User 可以免去输入密码以获取访问其它服务的Service Ticket ,所以,这里,凭借PGT ,Web 应用可以代理用户去实现后端的认证,而无需前端用户的参与。
如下面的CAS Proxy 图所示,CAS Client 在基础协议之上,提供了一个额外的PGT URL 给CAS Server, 于是,CAS Server 可以通过PGT URL 提供一个PGT 给CAS Client 。
初学者可能会对上图的PGT URL 感到迷惑,或者会问,为什么要这么麻烦,要通过一个额外的URL( 而且是SSL 的入口) 去传递PGT ?如果直接在Step 6 返回,则连用来做对应关系的PGTIOU 都可以省掉。
PGTIOU 设计是从安全性考虑的,非常必要,CAS 协议安全性问题我会在后面一节介绍。
于是,CAS Client 拿到了PGT( PGTIOU-85…..ti2td ) ,这个PGT 跟TGC 同样地关键,CAS Client 可以通过PGT 向后端Web 应用进行认证。
如下图所示,Proxy 认证与普通的认证其实差别不大,Step1, 2 与基础模式的Step 1,2 几乎一样,唯一不同的是,Proxy 模式用的是PGT 而不是TGC ,是Proxy Ticket (PT )而不是Service Ticket 。
最终的结果是,helloservice2 明白helloservice 所代理的客户是David. Turing 同学,同时,根据本地策略,helloservice2 有义务为PGTURL=http://helloservice/proxy 服务(PGTURL 用于表示一个Proxy 服务) ,于是它传递数据给helloservice 。