EBS单点登录SSO

单点登录是指在多个业务应用系统中，用户只需要登陆一次，就可以访问所有有权限的业务应用系统。在企业内部使用单点登录还是挺常见的，记录一下单点登录是什么主要是发现Oracle EBS也能单点登录，抽空特意了解了一下Oracle EBS单点登录的机制。

官方文档见 UG

EBS的单点登录是需要依靠Oracle Access Manage和Oracle Directory Services，启用SSO之后，EBS会将登录的功能委派给Oracle Access Manger。

从实现原理的角度看，EBS的单点登录主要是依靠cookie实现。EBS会要求需要使用相同的域名来实现单点登录

打开EBS的网址后，如果EBS没有登录的话(判断EBS的cookie是否还存在且有效)就会重定向到OAM的网址去做登录

如果OAM已经登录了(判断OAM的cookie是否存在且有效)，就会重定向回EBS(返回到ebs的url中会包含用户信息，EBS会根据OAM的登录结果产生EBS的cookie)，这时EBS就会自动登录

如果OAM还没有登录，用户会在OAM的网站登录，成功登录后(OAM会创建一个cookie)，之后会重新回到EBS的界面，这时EBS就会自动登录了。

基本工作逻辑见下图

PS: Oracle Directory Services主要是用来存储用户名和密码信息以及映射到EBS的用户名

以上是基于标准模块的功能原理配置，如果要使用其他第三方SSO登录的软件的话，原理和上面的类似，都需要启用Oracle Access Manage和Oracle Directory Services。 只是OAM可以把登录的权限在委派给第三方的SSO软件

单点登出:也就是用户在EBS上面注销后应该一并注销单点登录认证，这需要在Access Gate做一些特殊处理清理一些cookies

EBS实施单点登录时的一些特殊考量点：

CAS是一个单点登录的协议，详细逻辑见 官网 。

从实现的角度感觉也还是用了session的功能。当第一次登陆SSO系统的时候，就会生成一个ticket，然后存放到了服务器，同时会分配给ticket给应用系统。之后应用系统访问SSO系统的时候就会带上ticket，SSO系统验证ticket来判断用户时候有效。

SSO是Single Sign On的缩写，OAuth是Open Authority的缩写，这两者都是使用令牌的方式来代替用户密码访问应用。流程上来说他们非常相似，但概念上又十分不同。

以上两者，你在业务系统中都没有账号和密码，账号密码是存放在登录中心或微信服务器中的，这就是所谓的使用令牌代替账号密码访问应用。

两者有很多相似之处，下面我们来解释一下这个过程。先来讲解SSO，通过SSO对比OAuth20，才比较好理解OAuth20的原理。SSO的实现有很多框架，比如CAS框架，以下是CAS框架的官方流程图。

上面的流程大概为：

OAuth20有多种模式，这里讲的是OAuth20授权码模式，OAuth20的流程跟SSO差不多

以上，就是我的SSO和OAuth20的理解。

1、cookie+session

2、token

3、sso 单点登录

4、OAuth 第三方登录

实现流程：

缺点：

a、由于服务器要对接大量的客户端，所以服务器要存储大量的session,这会给服务器造成很大的压力

b、如果服务以集群的方式部署，为了同步登入态，那么还得同步session到每一台服务器上

c、由于seesionId是存放在cookie中的，所以无法避免一些攻击

为了解决以上问题，我们可以使用token方式

实现流程：

优缺点：

这里的token不存储在服务器，所以不会造成服务器的压力。并且服务器是集群也不需要同步数据到每台机器，不会增加维护成本。token可以存储在前端的任何地方，并不一定需要存储在cookie,提升了页面安全性。可以给token设置有效期，只要在有效期内token就一直有效，但是服务端却不容易收回有效期内token的权限。

token的生成方式：

最常见的生成token的方式是jwt(son web token)。服务器并不存储token,那后端服务是怎么校验token的呢？其实token并不是杂乱无章的字符串。

jwt由三部分组成：header、payload、signature

header 部分指定了该 JWT 使用的签名算法:

playload 部分表明了 JWT 的意图：

token的生成

服务器再校验token时，主要是判断两个方式得到的signatue是否一样

概念：

搭建一个认证中心服务，只要在该认证中心服务登录过了之后，就可以登录该服务群的任何一个服务取获取资源。

实现流程：

访问acom下的页面，先去认证中心进行登录认证

认证中心认证完之后，继续访问acom下的页面

访问bcom下的页面

由于浏览器存储了访问认证中心ssocom下的cookie,所以已经是登录了认证中心，认证中心直接下发tickit,之后的流程就和访问acom下的页面差不多了。

当服务群中的一个服务退出了登录，怎么让服务群中的其它服务也退出登录呢？

当认证中心注册服务的时候，顺便也把服务对应的api也注册好吧

a、ccom退出登录，清空ccom下的cookie

b、请求认证中心下的退出登录api

c、认证中心遍历下发过的ticket的服务，并调用这些服务的退出api

使用sso登录完成了服务集群登录共享态，但是这是基于一个共同的认证中心，其实实现起来还是比较复杂的。我们其实还可以使用第三方登录，比如微信登录。

acom 的运营者需要在微信开放平台注册账号，并向微信申请使用微信登录功能。申请成功后，得到申请的 appid、appsecret。

sso单点登录原理是当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改。

单点登录系统基于一种安全的通信协议，该协议通过多个系统之间的用户身份信息的交换来实现单点登录。

使用单点登录系统时，用户只需要登录一次，就可以访问多个系统，不需要记忆多个口令密码。单点登录使用户可以快速访问网络，从而提高工作效率，同时也能帮助提高系统的安全性。

扩展资料

要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

另外：

1、单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，事实上，只要统一认证系统，统一ticket的产生和校验，无论用户信息存储在什么地方，都能实现单点登录。

2、统一的认证系统并不是说只有单个的认证服务器

当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统2的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。