前后端分离的项目集成CAS
前后端分离的项目集成CAS
这里说的前后端分离,是指部署也分离的项目.
关于前后端分离的项目如何集成CAS,很少有资料博客来说如何做.
本文先给出一个解决流程思路,再从原理层面来进行一定的剖析.
采用环境:JDK1.8,Tomcat 8.5,cas 3.4.1.
实际本文内容和JDK、Tomcat版本无关,理论上和cas版本也无关.
主要涉及以下知识:
cas认证原理,及客户端的认证源码分析.session、cookie相关知识
主要解决如下两个问题:
- 前后端分离项目如何接入
cas. - 如何和项目原有的登录做集成.
问题一、前后端分离项目如何集成CAS
先说解决方案.
关键就是这两点:
- 登录成功后跳转的第一个地址必须是被后端
CAS Filter拦截的地址(主要用来重定向到前端,可以是一个接口,也可以是一个.jsp界面),保证cas可以把认证信息写入session. - 前端发起的后续请求必须和第一个请求(即前面的那个跳转后端的那个请求)是属于同一个
session.
只要能保证这两点,那就绝对没问题.下面这是我的解决思路:
假设:
cas服务端地址为192.168.0.90:8080/cas
后端服务地址为192.168.0.100:8080/api-server
前端界面地址为192.168.0.120
后端webapp根目录下增加一个cas.jsp来做重定向,这个jsp的访问地址为192.168.0.100:8080/api-server/cas.jsp
具体步骤:
1. 修改web.xml增加对cas.jsp的拦截
随手建一个cas.jsp,放到后端webapp的根目录下,里面暂时不用写什么代码,后面再加.
修改web.xml中的CAS Filter的配置,额外增加对cas.jsp的拦截.
CAS Filter
/cas.jsp
2.未登录时,前端重定向后端cas.jsp
调整下前端的js逻辑,在发现未登录时跳转cas.jsp(准确的说,最终目的是保证登录成功后第一个跳转的界面是cas.jsp).
// 没有登录,跳转后端cas.jsp
if(notLogin){
window.location.href='192.168.0.100:8080/api-server/cas.jsp';
}
cas.jsp被CAS Filter拦截,那么会再自动重定向到cas登录界面:192.168.0.90:8080/cas/login?service=192.168.0.100:8080/api-server/cas.jsp.
如果想节省一次重定向的开销,前端也可以直接重定向到登录界面,注意加上service参数即可
//和上面代码结果一样,但是节省一次重定向开销.参考代码如下
if(notLogin){
window.location.href=`192.168.0.90:8080/cas/login?service=192.168.0.100:8080/api-server/cas.jsp`;
}
如果一切顺利的话,这个时候登录成功,那么就会进入cas.jsp界面.这个进入cas.jsp的请求的session,是通过了cas认证的.
3. cas.jsp重定向到前端
修改cas.jsp,加入如下代码:
// 重定向到前端地址.
String url = "192.168.0.120";
response.sendRedirect(url);
那么此时,登录成功后最终会进入前端界面.下面我们只需要保证,后续前端发起的请求,和刚刚这个经过了cas.jsp的请求,是属于同一个session就行了,或者说,JSEESIONID这个cookie能正常写入前端的域下.
4. 保证将JSESSIONID写入前端cookie中
在创建一个新的session后,Tomcat的Session Manager在response中会加上Set-Cookie:JSESSIONID=123123这个头,来让浏览器写入名为JSESSIONID的cookie.但是这个是写在后端的域下面而不是前端的.而一般情况下,cookie是没法跨域读写的.
后果就是,登录成功了也跳转回了前端界面,但是后续的请求因为请求中没有JSESSIONID这个cookie(实际上也不是必须放在cookie里),导致后续的每个请求,对于Tomcat来说,都是一个新的请求,进而创建新的session–和第一个通过了认证的请求半毛钱关系都没,那CAS Filter自然也就不会放行.所以后续的请求依旧是调用不成功.
PS:如果这部分没看懂,那么建议还是看看后文中的CAS认证原理的章节.
那么这一步要解决的问题就是如何将JSESSIONID写入前端的域下的问题.
那大体上的方案,也就如下三种:
- 允许跨域写
cookie.大体上就是ajax请求加上{crossDomain: true, xhrFields: {withCredentials: true}},后端响应头加上response.addHeader("Access-Control-Allow-Credentials", "true"). - 让前后端"不跨域".具体方法就是,用
nginx将前后端反向代理到同一个域下,无论是访问前端界面还是调用后端接口亦或是后端CAS Filter中的配置都是用这个代理后的地址. - 前端手动写入
JSESSIONID.比如,cas.jsp在重定向回前端时,在url后面附带上JSESSIONID的值,前端js获取到地址栏里的值,再手动写入cookie中.
就以第三种–让前端手动写入JSESSIONID为例:
修改cas.jsp.
//获取sessionid
String jsessionid = session.getId();
// 前端地址.
String url = "192.168.0.120";
response.sendRedirect(url + "?jsessionid=" + jsessionid);
前端js:
// getJsessionIdFromUrl() 从地址栏里获取jseesionid参数的值,具体逻辑自行实现
var jsessionid = getJsessionIdFromUrl();
// setCookie() 写入cookie,具体逻辑自行实现
setCookie('jsessionid',jsessionid);
前端后续再发送的请求,带上JSESSIONID这个cookie,就没事了.
当然细节上还有很多可优化可完善的地方,但大致上就是这个流程思路.
方案流程
上述方案的总体的流程就是:
- 访问前端
192.168.0.120 - 前端判断没登录,跳转
192.168.0.100:8080/api-server/cas.jsp - 访问
192.168.0.100:8080/api-server/cas.jsp的请求到达Tomcat的Session Manager,发现没有session,创建新的session - 请求到达后端的
CAS Filter,CAS Filter发现session未认证且没有ST参数,302让浏览器重定向到cas服务端登录界面192.168.0.90:8080/cas/login?service=192.168.0.100:8080/api-server/cas.jsp - 请求到到达
cas服务端,服务端没有在自己的域(即192.168.0.90:8080)下找到名为TGC的cookie,那么认定是用户之前没有登录过,展示登录界面. - 在
cas服务端登录界面输入用户名密码,进行登录. - 登录成功,
cas服务端根据service参数,302让浏览器重定向到192.168.0.100:8080/api-server/cas.jsp?ticket=ST-ABC1234567,注意此时是附带上了ST参数,并且在服务端的域(192.168.0.90:8080)下写入名为TGC的cookie. - 访问
192.168.0.100:8080/api-server/cas.jsp?ticket=ST-ABC1234567到达Tomcat的Session Manager,发现没有session,创建新的session. - 请求进入后端
CAS Filter,发现session未认证但是有ST参数,予以放行 - 请求再进入后端的
CAS Validation Filter,向cas服务端校验ST,校验通过,将校验结果声明(内含用户信息)写入此session. - 请求到达
192.168.0.100:8080/api-server/cas.jsp界面 cas.jsp做一系列处理(比如二次登录)后,将JSESSIONID附带在url参数中,再重定向回前端- 前端从地址栏url中获取到
JSESSIONID参数,写入cookie中. - 后续请求,带上
JSESSIONID这个cookie.比如再去请求192.168.0.100:8080/api-server/a/b/c-api. - 请求到达
Tomcat的Session Manager,发现有JSESSIONID,并且存在,不再创建新的session. - 请求到达后端
CAS Filter,CAS Filter发现session中有认证信息.予以放行. - 请求到达
192.168.0.100:8080/api-server/a/b/c-api
问题二、CAS如何和原有的登录认证做对接
常见的一个问题就是,我这个项目本身已经有了一套登录体系,现在要集成cas,应当如何去做.
尤其是对接第三方的cas,cas服务端采用的用户库都和我们自己的不一样,这个该怎么去做.
大体思路依旧是通过前面我们增加的这个cas.jsp.在cas.jsp中根据cas返回的用户信息(一般都有用户名,但是不会有也不应当有密码),做二次登录,二次登录成功后再跳转前端.
参考代码如下:
// cas.jsp 内容
// cas会将用户信息写入session中. request.getAttribute("_const_cas_assertion_") 也可以拿到.
Object object = request.getSession().getAttribute("_const_cas_assertion_");
// org.jasig.cas.client.validation.Assertion
Assertion assertion = (Assertion) object;
// 获取到用户名
String userName = assertion.getPrincipal().getName()
/*
假设原有登录是调用的 loginService.login(userName,password);方法
那我们增加一个免密登录方法 loginService.loginWithOutPWD(userName),
里面的处理逻辑和返回值 同loginService.login(userName,password)基本一致,唯独不再需要密码.
*/
Object obj = loginService.loginWithOutPWD(userName);
// isLogin判断是否二次登录成功
if(isLogin(obj)){
// 二次登录成功,调整前端. 如果原有登录有其它参数需要给前端,也可以附带在url后面.
//获取sessionid
String jsessionid = session.getId();
// 前端地址.
String url = "192.168.0.120";
response.sendRedirect(url + "?jsessionid=" + jsessionid);
}else{
// 二次登录失败
//...
}
CAS认证原理
CAS基本概念
1.体系结构
从总体上看,CAS由两大部分组成:一个CAS Server 和多个CAS Client.
CAS Server(服务端)负责提供登录认证服务,单独部署,会给用户颁发两个核心票据:TGT(登录票据,服务端使用)和ST(服务票据,客户端使用).
CAS Client(客户端)负责处理对客户端受保护资源的访问请求.一般通过是在web.xml中配置了CAS过滤器,和应用系统部署在一起,可以有多个.
2. 核心票据
CAS的核心就是其Ticket,及其在Ticket之上的一系列处理操作.CAS的主要票据有TGT、ST、PGT、PGTIOU、PT,其中TGT、ST是CAS1.0(基础模式)协议中就有的票据,PGT、PGTIOU、PT是CAS2.0(代理模式)协议中有的票据.这里主要介绍CAS1.0—基础模式中的几种票据.
TGT(Ticket Grangting Ticket)
TGT是CAS为用户签发的登录票据,拥有了TGT,用户就可以证明自己在CAS成功登录过.TGT封装了Cookie值以及此Cookie值对应的用户信息.用户在CAS认证成功后,生成一个TGT对象,放入自己的session;同时,CAS生成TGC(一个cookie,官方文档说是叫TGC,但是我这边看到的名称是CASTGC,可能是我理解问题或者是版本差异,下文统称TGC),写入浏览器.
TGT对象的id就是TGC cookie的值,当HTTP再次请求到来时,如果传过来的有TGC这个cookie,并且CAS能找到对应的TGT,则说明用户之前登录过;如果没有,则用户需要重新登录.
TGC(Ticket-granting cookie)
上面提到,CAS Server会生成TGT,而TGC就是将TGT的id以cookie形式放到浏览器端,是CAS Server用来明确用户身份的凭证.
ST(ServiceTicket)
ST是CAS为用户签发的访问某一服务票据.在登录成功后重定向回客户端的时候,会给客户端颁发ST,客户端的CAS Validation Filter会根据ST去服务端再次做校验,获取用户信息.
为了保证ST的安全性:ST 是基于随机生成的,没有规律性.而且,CAS规定 ST 只能存活一定的时间,然后 CAS Server 会让它失效.而且,CAS 协议规定ST只能使用一次,无论 Service Ticket 验证是否成功, CASServer 都会清除服务端缓存中的该 Ticket ,从而可以确保一个 Service Ticket 不被使用两次.
概括下就是,ST是服务端提供给客户端的用来获取用户信息的只能用一次的凭证.
3. 核心过滤器
CAS Client使用的核心过滤器主要由两个:负责判断请求是否已认证的AuthenticationFilter和负责校验ST的TicketValidationFilter.
CAS认证原理
直接上官方提供的认证序列图(一定要看懂).
[外链图片转存中…(img-NJvC5iEI-1569813048856)]
其中的ST就是所谓的唯一令牌,用过即失效.这个令牌也可能是采用JWT来生成的.
如果ST采用的是JWT来进行生成,那么流程上稍微有些不同,序列图如下(这个了解就行):
[外链图片转存中…(img-OuyOnH3A-1569813048857)]
可以打开Chrome的控制台或者是直接采用Filder进行抓包,对照着进行分析确认.
CAS客户端核心过滤器
对着源码来看下cas客户端的是如何判断一个session是否已通过认证.
前面我们提到过,CAS客户端使用的核心过滤器主要有两个:负责判断请求是否已认证的AuthenticationFilter和负责校验ST的TicketValidationFilter.
这两个过滤器都有多种不同的实现,下文只以具体的某个实现类为例来说明.
AuthenticationFilter
这个过滤器就是用来负责校验每个请求是否是认证的请求,如果请求未通过认证且不包含ST,那么就重定向到服务端登录界面.
对应客户端web.xml中配置的CAS Filter,大致是这样的:
CAS Filter
org.jasig.cas.client.authentication.AuthenticationFilter
casServerLoginUrl
${cas.serverUrl}/login
serverName
${cas.clientUrl}
ignorePattern
.*/login|.*/unsafe|.*/api/app/token/*|.*\.ico|.*\.js(?!p)|.*\.css|
ignoreUrlPatternType
REGEX
...
CAS Filter
/cas.jsp
CAS Filter
/api/*
看下对应的实现.
public final void doFilter(final ServletRequest servletRequest, final ServletResponse servletResponse,
final FilterChain filterChain) throws IOException, ServletException {
final HttpServletRequest request = (HttpServletRequest) servletRequest;
final HttpServletResponse response = (HttpServletResponse) servletResponse;
// 判断请求是否不需要过滤
if (isRequestUrlExcluded(request)) {
logger.debug("Request is ignored.");
filterChain.doFilter(request, response);
return;
}
final HttpSession session = request.getSession(false);
// CONST_CAS_ASSERTION = "_const_cas_assertion_"
final Assertion assertion = session != null ? (Assertion) session.getAttribute(CONST_CAS_ASSERTION) : null;
// 存在assertion,即认为这是一个已通过认证的请求.予以放行
if (assertion != null) {
filterChain.doFilter(request, response);
return;
}
// 不存在 assertion,那么就来判断这个请求是否是用来校验ST的(校验通过后会将信息写入assertion)
final String serviceUrl = constructServiceUrl(request, response);
final String ticket = retrieveTicketFromRequest(request);
final boolean wasGatewayed = this.gateway && this.gatewayStorage.hasGatewayedAlready(request, serviceUrl);
// 是校验ST的请求,予以放行
if (CommonUtils.isNotBlank(ticket) || wasGatewayed) {
filterChain.doFilter(request, response);
return;
}
final String modifiedServiceUrl;
logger.debug("no ticket and no assertion found");
if (this.gateway) {
logger.debug("setting gateway attribute in session");
modifiedServiceUrl = this.gatewayStorage.storeGatewayInformation(request, serviceUrl);
} else {
modifiedServiceUrl = serviceUrl;
}
logger.debug("Constructed service url: {}", modifiedServiceUrl);
// 要重定向界面地址(cas服务端登录界面).
final String urlToRedirectTo = CommonUtils.constructRedirectUrl(this.casServerLoginUrl,
getProtocol().getServiceParameterName(), modifiedServiceUrl, this.renew, this.gateway);
logger.debug("redirecting to \"{}\"", urlToRedirectTo);
this.authenticationRedirectStrategy.redirect(request, response, urlToRedirectTo);
}
可以看到,cas正是通过session中是否有assertion的信息来判断一个请求是否合法.
而这个assertion信息,又是在客户端校验ST之后(登录成功后重定向回客户端的请求附带有ST参数)写入session中的.具体见下文TicketValidationFilter
TicketValidationFilter
这个过滤器用来校验ST,并在session中写入认证声明信息assertion.
对应客户端web.xml中配置的CAS Validation Filter,大致是这样的:
CAS Validation Filter
org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
查看Cas20ProxyReceivingTicketValidationFilter源码,可以在其父类AbstractTicketValidationFilter的doFilter()方法中找到对应的代码,如下:
final Assertion assertion = this.ticketValidator.validate(ticket,
constructServiceUrl(request, response));
logger.debug("Successfully authenticated user: {}", assertion.getPrincipal().getName());
// CONST_CAS_ASSERTION = "_const_cas_assertion_"
request.setAttribute(CONST_CAS_ASSERTION, assertion);
// useSession 对应配置项中的useSession参数,缺省值为true.但这个配置在3.4版本之后是弃用的,后续随时可能会被移除.
if (this.useSession) {
request.getSession().setAttribute(CONST_CAS_ASSERTION, assertion);
}
那么通过这两个过滤器的源码分析,可以证明这两点:
- cas客户端是根据
session中是否有assertion信息来判断是否已认证. assertion是在登录成功后重定向回后端的时候写入session的.
那么进而就会得出我们前文中提到的解决思路的关键性两点:
- 登录成功后跳转的第一个地址必须是被后端
CAS Filter拦截的地址(主要用来重定向到前端,可以是一个接口,也可以是一个.jsp界面),保证cas可以把认证声明信息assertion写入session. - 前端发起的后续请求必须和第一个请求(即前面的那个跳转后端的那个请求)是属于同一个
session(因为有assertion,一定可以通过认证).
关于第一点不再多说.
关于第二点,如何保证前端发起的后续请求和第一个请求是同一个session,答案就是保证JSEESIONID一致就行.
关于session、cookie及JSESSIONID在其中起到的作用
众所周知,Http协议是一种无状态协议,每次服务端接收到客户端的请求时,都是一个全新的请求,服务器并不知道客户端的历史请求记录；
为了弥补Http的无状态特性,session应运而生.服务器可以利用session存储客户端在同一个会话期间的一些操作记录,而服务端的这个session,对应到浏览器端,则是名为JSESSIONID的cookie,JSESSIONID的值就是session的id.
那么再看这两个问题:
- 服务器如何判断客户端发送过来的请求是属于同一个
seesion?
答:用session的id来进行区分,如果id相同,那就认为是同一个会话.在Tomcat中,session的id的默认名字是JSESSIONID.对应到前端就是名为JSESSIONID的cookie.
session的id是在什么时候创建,又是怎样在前后端传输的?
答:tomcat在第一次接收到一个请求时,会创建一个session对象,同时生成一个session id,并通过响应头的Set-Cookie:"JSESSIONID=XXXXXXX"命令,向客户端发送要求设置Cookie的响应.
前端在后续的每次请求时,会带上所有cookie信息,自然也就包含了JSESSIONID这个cookie.Tomcat据此来查找到对应的session.如果指定session不存在(比如我们随手编一个JSESSIONID,那对应的session肯定不存在),那么就会创建一个新的session,其id的值就是请求中的JSESSIONID的值.
这样我们在代码中就可以通过request.getSession()来获取到当前的会话信息.
PS:
实际上,JSESSIONID传给后端的方式,还可以直接在url后面加上;jsessionid=xxxx来传递.但是会被cookie中的JSESSIONID覆盖.
那么具体到cas对接上,第一次重定向回客户端的请求肯定是可以通过cas的认证的,那么只要后续的请求和第一个是同一个session,那就一定也能通过cas的过滤.
前面我们也说了,只要请求中的JSESSIONID是一致的,那就会被认定是同一个session.
前文中给出的解决思路,也正是基于此进行.
原理部分基本上就到这里.
如果觉得看懂了原理,那我最后提个问题:
如果通过nginx将前后端反向代理到同一个域下,登录成功后直接跳转前端地址,那是否可行?原因是什么?
以上.
参考文章:
cas官方文档 https://apereo.github.io/cas/6.0.x/
cas认证原理 https://blog.csdn.net/wang379275614/article/details/46337529