单点登录原理时序图
domino单点登录ltpatoken生成原理
Domino单点登录LTPAtoken生成原理一、WebSphere与Domino之间的SSO首先让我们来了解一下Websphere与Domino之间是怎么完成SSO的：1、Web用户向Websphere发起一个登录请求。
2、Websphere判断为合法用户，登录成功。
3、生成ltpatoken，将ltpatoken写入cookie。
这样，当Web用户后续向Domino发起登录请求时，Domino会找到存放在cookie信息中的ltpatoken信息，并且认为这个ltpatoken有效，完成在domino的登录过程。
那么这里会有2个疑问。
第1个，Domino怎么会找的到Websphere存放的cookie，这就是为什么配置SSO的时候需要2个系统是在同一个DNS域下面，因为浏览器cookie共享的限制，跨域不能共享cookie嘛（当然也能用一些其他的手段生成跨域的cookie，这样其实通过一定的开发是可以让LTPATOKEN 跨域的，本案例不讨论这个问题）。
第2个问题，domino找到这个token之后，凭什么认识这个ltpatoken，并且认为它有效呢，所以要求domino和Websphere在生成ltpatoken的时候就有某种约定。
这就是为什么配置Domino SSO文档的时候需要引入Websphere的密钥了。
有了这些前提Domino和Websphere之间就能互相认识对方生成的ltpatoken，并且从中读出需要登录的用户名，只要用户名匹配得上（这就是为什么W和D需要用同一个LDAP目录），该用户就完成登录了。
以上就是简单的Websphere与Domino之间SSO的原理。
当然其实SSO过程还没有这么简单，比如还需要验证ltpatoken的有效期等。
现在我们知道实现SSO的关键在于LtpaToken，Websphere与Domino之间采用LtpaToken 来共享认证信息。
那么基本上任何一个系统只能要完成以下2件事情，它就有可能参与LtpaToken认证的SSO 方案了：1、能生成一个有效的LtpaToken提供给别人。
NC系统集成之单点登录讲解
什么是单点登录？
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企 业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户 只需要登录一次就可以访问所有相互信任的应用系统。
单点登录功能示意图
ቤተ መጻሕፍቲ ባይዱ
单点登录实例流程图
NC产品 - 单点登录
NC单点登录-过程说明
1.当客户端用户希望进入NC系统时，首先向外部的认证系统提交请求。 2.由外部认证系统向nc服务器注册客户端的登录信息，这些信息是nc系 统所必需的信息（例如：用户登录账号）。可以通过 一个随机的键值 key来索引登录信息。 3.客户端将通过该键值来进入nc系统。即客户端将向nc应用服务器提交 其键值。nc服务器将利用该键值从注册中心中获取登录信息（同时注销 注册信息）。然后利用这些登录信息登录到NC系统。 4.超时处理：注册的登录信息有其生命期，超过生命期的注册信息将会 被清除。客户端只能在超时以前登录nc才有效，否则不能进入nc系统。 超时的值在配置文件中进行配置。
e=01&m_strUserCode=hb&m_strPassword=1&m_strLoginDate=2009-0622&m_strLangCode=simpchn 参数说明： logintype：登录类型，单点登录请使用值portal或者不使用 m_strUnitCode：登录单位 m_strUserCode：登录用户 m_strPassword：登录密码 m_strLoginDate：登录日期 m_strLangCode：登录语种
NC单点登录-注册URL
1.注册用的url 外部系统服务器利用此URL向NC服务器注册登录信息。 http://localhost/servlet/nc.bs.sm.login2.RegisterServlet?key=emhvdWxvbmc&la nguage=simpchn&accountcode=01&pkcorp=1001&workdate=2009-0622&usercode=1&pwd=1&width=1024&&height=800 参数说明： key值为注册登录信息的键值，必须保证唯一。 language值为语言。 pkcorp值为登录公司主键。 accountcode值为账套。 workdate值为登录日期。
keycloak单点登录原理
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)
【黑马程序员】单点登录实现原理（SSO）简介∙单点登录是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的保护资源，若用户在某个应用系统中进行注销登录，所有的应用系统都不能再直接访问保护资源，像一些知名的大型网站，如：淘宝与天猫、新浪微博与新浪博客等都用到了这个技术。
原理∙单点登录∙有一个独立的认证中心，只有认证中心才能接受用户的用户名和密码等信息进行认证，其他系统不提供登录入口，只接受认证中心的间接授权。
间接授权通过令牌实现，当用户提供的用户名和密码通过认证中心认证后，认证中心会创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌即得到了授权，然后创建局部会话。
∙示例：下面对上图进行解释：∙当用户还没进行用户登录的时候∙用户去访问系统1的保护资源，系统1检测到用户还没登录，跳转至SSO认证中心，SSO认证中心也发现用户没有登录，就跳转到用户至认证中心的登录页面∙用户在登录页面提交用户相应信息后，认证中心会校验用户信息，如果用户信息正确的话认证中心就会创建与该用户的全局会话（全局会话过期的时候，用户就需要重新登录了。
全局会话中存的信息可能有令牌，用户信息，及该在各个系统的一些情况），同时创建授权令牌，然后进行下一步，否则认证中心给出提示（用户信息有误），待用户再次点击登录的时候，再一次进行校验用户信息∙认证中心带着令牌跳转到用户最初请求的地址（系统1），系统1拿到令牌后去SSO认证中心校验令牌是否有效，SSO认证中心校验令牌，若该令牌有效则进行下一步∙注册系统1，然后系统1使用该令牌创建和用户的局部会话（若局部会话过期，跳转至SSO认证中心，SSO认证中心发现用户已经登录，然后执行第3步），返回受保护资源∙用户已经通过认证中心的认证后用户访问系统2的保护资源，系统2发现用户未登录，跳转至SSO认证中心，SSO 认证中心发现用户已经登录，就会带着令牌跳转回系统2，系统2拿到令牌后去SSO 认证中心校验令牌是否有效，SSO认证中心返回有效，注册系统2，系统2使用该令牌创建与用户的局部会话，返回受保护资源。
CAS单点登录
CAS基本原理与配置1版本1.0日期：2015年11月20日2目录1基本原理 (4)1.1概念简介 (4)1.2CAS基本原理 (5)2配置说明 (8)2.1配置JDK证书 (8)2.2配置CAS服务器 (10)2.3配置CAS客户端 (11)2.4定制化说明 (17)2.4.1 页面定制化 (17)2.4.2 数据库定制化 (18)2.4.3 增加图片验证和短信验证 (20)2.4.4 增加自定义登录验证 (27)31基本原理1.1概念简介单点登录（ Single Sign-On , 简称 SSO ）是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
CAS （ Central Authentication Service ）是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。
CAS 开始于 2001 年，并在 2004 年 12 月正式成为 JA-SIG 的一个项目。
CAS主要特性：1、开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等；2、支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；3、安全策略：使用票据（ Ticket ）来实现支持的认证协议；4、支持授权：可以决定哪些服务可以请求和验证服务票据（ ServiceTicket ）；5、提供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；6、支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等；41.2CAS基本原理结构体系：CAS包括两部分，CAS Server和CAS Client。
单点登陆(SSO)功能实现流程介绍
SSO单点登录功能实现介绍SSO在我们的应用中非常常见，例如我们在OA系统登录了，我们就可以直接进入采购系统，不需要再登录了，这样使我们非常方便。
现在网上也有很多实现方法，于是乎我也想写一个看看。
我主要用到的是cookie的机制。
在此，分享给大家。
进入主题：工程说明SSO的实现一般是会有一个SSO Server，也会叫认证中心，同时也会有被认证的系统，如OA系统、采购系统等，他们就相当于SSO Server的client。
为了更形象体现SSO，我写的SSO是有三个工程：一个SSO Server端口为808 1，一个OA系统端口为8082，一个采购系统端口为8083。
如图：流程介绍在整个SSO流程当，有两个流程非常重要，第一个是用户没有登录系统到登录系统的过程；第二是用户在一个系统当中已经登录（例如在OA系统中登录了），但又想进入另一个系统（例如进入PRO系统）的过程，如果把这两个过程搞定了，那么SSO也就搞定了。
我画了两幅图来说明这两个过程。
先看用户没有登录系统到登录系统的过程，如图：1：用户通过URL访问OA系统。
2：在OA系统中的filter发现这个URL没有ticket（你暂且就把ticket看做是门票），此时就会跳转到SSO Server。
3：SSO Server中的filter发现该客户端中的cookie中没有相应信息，也即是一个没有登录的用户，那么会跳转到登录页面。
4：用户在登录页面填写相应信息，然后通过post方式提交到SSO Server中。
5：SSO Server会校验用户信息（我为了快，我的校验方式就是要用户名为：clo ud，同时密码为：cloud），同时在cookie中放username。
6：将生成ticket和username放到JVMCache中，在实际项目应该放到Memcac hed中，它的用处等下分析。
7，8：就是在用户访问OA系统的URL基础上加上了一个ticket参数，这样跳转到OA系统。
单点登录和权限认证
单点登录和权限认证1、登录认证1、Session-Cookie认证传统认证图基于Session-Cookie机制的认证是⽐较原始的⼀种认证⽅式，由于HTTP协议是纯⽂本，⽆状态的传输协议，那么在⼀些需要记录状态的场景就很⿇烦，如淘宝的购物车，不同⽤户登录后看到的购物车数据是不⼀致的；所以需要⼀种机制能让服务端知道请求的客户端是谁。
这样Cookie就应运⽽⽣，在客户端登录成功后，服务端返回的响应报⽂头中会带上⼀个set-cookie，客户端浏览器判断拿到这个请求头后会放在本地，每次访问cookie中指定的路径时都会带上到请求头中。
1、缺点基于Session-Cookie会带来⼀系列的问题。
⽐如：服务端的Session都保存在内存中，登录⽤户过多后会对服务端造成较⼤的压⼒可能会引起CSRF攻击分布式系统中⽆法进⾏登录认证2、解决⽅案集中式session认证为解决Session存储在服务端导致的性能瓶颈的痛点，可以将session信息放⼊到缓存或者是数据库中进⾏存储，服务端在校验登录进来的信息时直接从缓存或者数据库中获取对应的信息进⾏⽐对，业内⼀般将Session信息放⼊到Redis中进⾏保存。
SpringSession1 引⼊pom<dependency><groupId>org.springframework.session</groupId><artifactId>spring-session</artifactId><version>1.2.2.RELEASE</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-redis</artifactId></dependency>2 application.yaml配置spring:redis:database: 1host: localhostpool:max-active: 203 开启@EnableRedisHttpSessionSpringSession原理先从@EnableRedisHttpSession注解类分析开始@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.TYPE})@Documented@Import({RedisHttpSessionConfiguration.class})@Configurationpublic @interface EnableRedisHttpSession {int maxInactiveIntervalInSeconds() default 1800;String redisNamespace() default "spring:session";RedisFlushMode redisFlushMode() default RedisFlushMode.ON_SAVE;String cleanupCron() default "0 * * * * *";}可以看到该注解⽤到了Spring的Import来加载需要的bean在RedisHttpSessionConfiguration配置类中主要的功能有以下：@Beanpublic RedisOperationsSessionRepository sessionRepository() {RedisTemplate<Object, Object> redisTemplate = this.createRedisTemplate();RedisOperationsSessionRepository sessionRepository = new RedisOperationsSessionRepository(redisTemplate);sessionRepository.setApplicationEventPublisher(this.applicationEventPublisher);if (this.defaultRedisSerializer != null) {sessionRepository.setDefaultSerializer(this.defaultRedisSerializer);}sessionRepository.setDefaultMaxInactiveInterval(this.maxInactiveIntervalInSeconds);if (StringUtils.hasText(this.redisNamespace)) {sessionRepository.setRedisKeyNamespace(this.redisNamespace);}sessionRepository.setRedisFlushMode(this.redisFlushMode);int database = this.resolveDatabase();sessionRepository.setDatabase(database);return sessionRepository;}@Beanpublic <S extends Session> SessionRepositoryFilter<? extends Session> springSessionRepositoryFilter(SessionRepository<S> sessionRepository) {SessionRepositoryFilter<S> sessionRepositoryFilter = new SessionRepositoryFilter(sessionRepository);sessionRepositoryFilter.setServletContext(this.servletContext);sessionRepositoryFilter.setHttpSessionIdResolver(this.httpSessionIdResolver);return sessionRepositoryFilter;}创建⼀个RedisOperationsSessionRepository对象提供给SessionRepositoryFilter操作session的⼯具。
CAS单点登录(SSO)服务器配置
CAS单点登录（SSO）服务器配置一、单点登录的概念单点登录（SSO）英文全称Single Sign On，单点登录。
SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。
它是目前比较流行的企业业务整合的解决方案之一。
简单的 SSO 的体系中，会有下面三种角色： 1 、 User （多个） 2 、 Web 应用（多个） 3 、 SSO 认证中心（1 个）虽然 SSO 实现模式千奇百怪，但万变不离其宗：1） Web 应用不处理 User 的登录，否则就是多点登陆了，所有的登录都在 SSO 认证中心进行。
2） SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是谁。
3） SSO 认证中心和所有的Web 应用建立一种信任关系，SSO 认证中心对用户身份正确性的判断会通过某种方法告之Web 应用，而且判断结果必须被Web 应用信任。
二、单点登录原理当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket 送到认证系统进行效验，检查ticket的合法性。
如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
CAS单点登录原理图：三、CAS 单点登录配置1.SSL配置先在CAS官方上下载cas server，解压后找到在modules文件夹中找到cas-server-webapp-3.4.11.war，将文件名更改为cas.war后置于tomcat应用目录下。
因为CAS的服务器验证需要通过SSL来完成，所以SSL对于CAS来说是必须的,SSL 的配置不是本文的重点，我们只是做简要的介绍。
单点登录实现
1 引言企业在信息化建设过程中，由于经常采用逐步信息化的方式，因此会造成企业内部各个应用系统的用户目录不完全兼容，各应用系统相互孤立，形成“信息孤岛”。
信息孤岛的存在，使得信息系统用户需要做重复的登录。
因此实际中，需要一个统一的用户登录管理系统平台，来实现用户统一身份验证。
用户登录到某一应用系统(通常是门户站点，如办公自动化系统)后，当需要访问其他应用系统时，不必登录就可以直接进入应用系统。
单点登录系统平台采用统一的用户信息数据库，实现用户统一验证。
从用户的角度只需进行一次登录就可实现全局访问；从管理员的角度，能够记录用户登录各个系统的日志信息，方便进行统计分析。
2 单点登录的实现原理2.1 单点登录的一般模型单点登录模型，一般由三部分构成，分别是：用户、身份提供者和服务提供者，如图1所示。
(1)用户是指通过浏览器来使用应用服务的个体。
(2)身份提供者是指对个体进行身份验证的服务提供者。
(3)服务提供者是指为用户进行应用服务的具体应用服务提供者。
单点登录的工作原理是：用户首先在身份提供者那里注册身份；当用户进行单点登录时，在身份提供者处登录，进行身份验证，由身份提供者为用户标记登录信息；当访问其他的服务提供者时，被访问的服务提供者首先直接与身份提供者进行交互，确定该用户是否已进行单点登录，从而确定允许该用户来访问自己提供的服务。
2.2 单点登录的重要概念2.2.1 单点登录点理想的情况是用户通过任何应用系统都能进行SSO(Single Sign-on)，这对于基于Web的系统是可行的。
这种单一的登录点在整个系统的设计中是惟一认证用户的地方，由登录点将SSO token(单点登录标志)(针对不同的C／S，B／S应用可能还需要传递用户名，口令)传递给应用系统，应用系统利用SSOtoken进行用户已认证的验证。
将这个单一的登录点称为SSO Entry(单点登录点)。
2.2.2 对原有应用系统的修改并不是任何系统都能够使用SSO，只有那些符合SSO规范，使用SSO API的应用系统才具有SSO的功能。
CA单点登录介绍
单 点 登 录 -eTrust SSO 概述在当今世界的分布计算环境中， 用户每天要登录到很多不同的系统和应用中。
每个系统 都有自己的认证过程，要求用户输入不同的用户名、口令。
用户需要进入的系统越多，用户 出错的概率和安全问题出现的可能性就越多。
在 Internet 中，如果访问一个公司网站过于复 杂或者不安全，客户或合作者可能中止和他们的业务关系，对公司业务的影响不言而喻。
CA 的 eTrust Single-Sign On，使用户进行单一认证。
一旦获得认证，用户可以立即访问 所有被授权的系统，包括 C/S 系统。
系统或安全管理员可以实施安全控制，但不用改变或影 响用户登录。
eTrust Single Sign On 支持多种第三方用户认证方式，这使管理员加强和客户 化了登录过程的安全性。
体系架构为了实现单点登录的功能，eTrust SSO 采用了 Client/Server 软件结构。
主要包括如下部 分： 1) 授权引擎－eTrust SSO 服务器。
它决定着用户是否可以登录以及他们可以访问哪些资 源。
它通过安全地管理用户口令集并自动对每一 Web 和非 Web 应用提交正确的口令 来完成本功能。
它简化了最终用户的登录过程，减少了口令管理工作量，并增强了总 体应用的安全性。
该产品支持多种验证最终用户身份的方法，从而为使用该产品的所 有公司提供了灵活性。
eTrust SSO 数据库 存储了所有关于用户、组、资源、应用、登录参数和访问控制规则 等信息，与其它 eTrust 产品所使用的是同一个数据库。
一旦你在该数据库中录入信息， 这些产品都可对该共享数据库进行访问和更新操作， 以满足其各自的或共同的需求， 从 而为用户提供了有效而先进的方法。
在安装该数据库的过程中或安装完成以后， 您可以 将公司已有数据库中的用户和组信息导入其中。
您还可以通过运行一个 eTrust Single Sign-On 支持的实用程序，或使用 eTrust Single Sign-On 所支持的命令行界面来输入用本文档仅限深圳市卓越方达科技有限公司和被呈送方内部使用，未经许可，请勿扩散到第三方。