单点登录（二）

OAuth2是一个授权框架，或称为授权标准，可以使第三方应用程序或客户端获得对http服务上用户账号信息的有限访问权限。

OAuth2通过将用户身份验证委派给托管用户账户的服务以及授权客户端访问用户账户进行工作上。OAuth2可以为web应用和桌面应用以及移动应用提供授权流程。

OAuth标准定义了以下角色： 资源所有者（resource owner） 资源服务器（resource server） 授权服务器（authorization server） 客户端（client）

资源所有者是OAuth2四大基本角色之一。代表授权客户端访问本身资源信息的用户。也就是应用场景的开发者A，客户端访问用户账户的权限仅限于用户授权的范围。

资源服务器托管了受保护的用户账号信息，而授权服务器验证用户身份然后为客户端派发资源访问令牌。

在OAuth2中，客户端即代表意图访问受限资源的第三方应用。在访问实现之前，必须先经过用户授权，并且获得的授权凭证将进一步有授权服务器进行验证。

CAS(Central Authentication Service)是耶鲁Yale大学发起的java开源项目，在为web应用系统提供可靠的单点登录解决方案（web sso）。

从结构上，cas包含两个部分：CAS server和CAS client

CAS server 需要独立部署，主要负责对用户的认证工作，处理用户名/密码等凭证(Credentials)；

CAS server 负责完成对用户的认证工作，CAS server需要独立部署；

CAS server 会处理用户名/密码等凭证，可能会到数据库检索一条用户账号信息，也可能在XML文件中检索用户密码等，CAS均提供一种灵活但统一的接口/实现分离的方式，CAS协议是分离的，这个认证的实现细节可以自定义和扩展；

CAS client部署在客户端，负责处理对本地web应用（客户端）受保护资源的访问请求，并且当需要对请求方进行身份认证是，重定向到CAS server进行认证；

CAS client负责部署在客户端，原则上CAS client的部署意味着：当有对本地web应用的受保护资源的访问请求，并且需要对请求方进行身份认证，web应用不在接受任何的用户名密码等类似的凭证，而是重定向到CAS server进行认证；

1.cas client与受保护的客户端应用部署在一起，以Filter方式保护收保护的资源。对于访问受保护资源的每个web请求，Cas client会分析该请求的http请求中是否包含service ticket和ticket granting tieckt，如果没有，说明当前用户尚未登录，于是将请求重定向到指定的csa server登录地址，并传递service，以便登录成功过后转回改地址。用户在第三步中输入认证信息，如果登录成功，csa server随机产生一个相当长度、唯一、不可伪造的service ticket，并缓存以待将来验证，之后系统自动重定向到service所在地址，并为客户端浏览器设置一个ticket granter cookie，cas client在拿到service和新产生的ticket过后，在第5.6步中与cas server进行身份核实，以确保service ticket的合法性。

2.在该协议中，所有与 CAS 的交互均采用 SSL 协议确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。

3.CAS 如何实现 SSO 当用户访问另一服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：

1.用户浏览受系统保护的url

2.Csa client服务端收到请求，filter拦截该请求，在filter中判断该用户是否已经登录，如果已经登录，就直接进入系统，否则，将请求转发到cas server服务端的login__URL。

3.在login_URL中会获取到用户的cookie，检验用户是否已经在其他相关使用sso的系统登录成功。如果已经在其他的系统登录，则将请求转回cas client，并且带回一个ticket，cas client再次发送请求到validateURL，否则系统提示用户输入ID和passwd。

4.提交后请求到validateURL，cas server验证ticket的有效性。然后返回结果给cas client。如果ticket有效，则cas client应该让用户浏览受保护的资源。否则，重定向到登录页面，提示用户输入ID和Password。

5.校验ID和passwd是否匹配，如果不匹配，再次要求用户输入id和passwd。否则，cas server记录用户登录成功。并向浏览器回送cookie，记录用户已经登录成功。如果浏览器不支持cookie，则无法实现单点登录。

Cas： Github地址：https://apereo.github.io/cas/ Overlay版：https://github.com/apereo/cas-overlay-template 使用版本：5.x

将代码clone本地

打开 pom.xml 文件，找到下面的部分

将注释的部分替换需要的模块

上面添加了openLDAP、oauth2.0、mysql的依赖 添加mysql需要指定connector-java连接器的版本

编辑好pom文件后，执行下面的命令开始编译

编译完成后，会在此目录下生成一个target目录，需要的war包就在里面

下载Tomcat 将war包保存到tomcat的webapps目录下，然后运行tomcat即可

运行完成后，打开http://localhost:8080/cas 默认用户名密码为：casuser/Mellon

修改/usr/local/tomcat/webapps/cas/WEB-INF/class/application.properties文件

重启完成后，进行测试，浏览器打开:http://localhost:8080/cas/oauth2.0/authorize?response_type=code&client_id=20181124&redirect_uri=https://www.baidu.com

登录成功后后，点击Allow即可成功授权跳转至url，并且uri会携带一个code。

注释掉默认的cas.authn.accept.users认证方式并添加与LDAP server连接的配置

前提条件：gitlab首先集成openLDAP

Cas服务器，在配置文件中添加

1.Gitlab集成openLDAP

修改配置文件/etc/gitlab/gitltb.rb

其中参数的说明： CAS_PATH：更改为CAS实例的根。

1.配置注销登录的接口

有的版本，存在注销登录时，gitlab不会自动调用配置的cas的注销接口。可以采用登录root账号，然后配置AFTER sign out path为cas的注销接口来解决

登录root账号，进入admin area，选择settings，选择general，选择sign-in retrictions

配置After sign out path为cas服务的注销接口。然后点击save changes保存修改。

After sign out path中的url必须带service参数，该servie参数是cas注销登录后的重定向地址，所以service的值为gitlab的登录url。（根据实际情况而定）。

2.gitlab账号与cas账号之间的关系

Gitlab自身维护一套用户系统，csa服务也有一套用户系统，gitlab可以将两者关联起来，然后用户可以选择其中一种方式进行登录就可以。

根据用户是否有gitlab账号，可以分为两种情况：

1）已有gitlab账号的，用户可按原来的登录方式进行登录，然后在用户设置里关联cas账号，也可以有root账号进行统一的关联。

2）没有gitlab账号的，在直接使用cas服务登录的时候，根据参数的配置，分为以下几种情况：

3.使用root账号将普通gitlab账号和cas账号关联和解除关联

除了用户自己可以进行gitlab账号和cas账号的关联外，root账号可以为所有gitlab 账号关联cas账号。

选择一个provider，也就是前面配置的cas服务，输入identity，点击save changes，即可完成gitlab账号与cas账号的绑定。

PS：这里的identifier，是gitlab向cas服务器端发送验证请求的时候，验证成功后，cas服务器返回给gitlab的值。Cas服务器返回的是用户的用户名，因此identifier需要填用户名。

普通gitlab账号和cas账号的关联的解除和修改

与上面关联账号的步骤一样，登录root账号，进入admin area，选择users，点解需要解除关联cas账号的用户，选择identities。Delete相应的identifier，即可解除关联，选择edit进行identifier的编辑修改。