当前位置：文档之家 › 让CAS支持客户端自定义登陆页面——客户端篇

让CAS支持客户端自定义登陆页面——客户端篇

  • 格式：doc
  • 大小：46.50 KB
  • 文档页数：7

客户端实现目标客户端实现主要需要满足5个case：∙ 1. 用户未在中央认证服务器登陆，访问客户端受保护资源时，客户端重定向到中央认证服务器请求TGT认证，认证失败，转回客户端登陆页面，保证受保护资源URL信息不丢失∙ 2. 用户未在中央认证服务器登陆，访问客户端登陆页面时，客户端重定向到中央认证服务器请求TGT认证，认证失败，转回客户端登陆页面，此次登录页面不再受保护，允许访问∙ 3. 用户已在中央认证服务器登陆，访问客户端受保护资源时，客户端重定向到中央认证服务器请求TGT认证，认证成功，直接转回受保护资源∙ 4. 用户在客户端登陆页面提交用户名密码，客户端将用户名密码信息提交给服务器端，认证失败，转回客户端登陆页面，携带失败信息并保证转到登陆页面前受保护资源URL信息不丢失∙ 5. 用户在客户端登陆页面提交用户名密码，客户端将用户名密码信息提交给服务器端，认证成功，转回转到登陆页面前受保护资源对于case 1和case 3，普通的CAS客户端即可满足需求，但对于case 4和case 5，则需要我们定制自己的登陆页面。

对于case 2，主要是需要满足部分登陆页面希望在用户未登陆状态显示登陆框，在已登陆状态显示用户欢迎信息的需求，实现这个需求我们是通过让CAS客户端认证器满足一个排除约定，即当用户请求路径为登陆页面且带有validated=true的参数时，即不进行重定向TGT认证请求客户端修改方案远程客户端修改，对于任何一种客户端方案都可以实现，这里为了简单起见，我们给出的修改方案基于CAS官方提供的Java客户端3.1.3。

首先我们使用CAS Client 3.1.3搭建一个CAS客户端，具体搭建方法可以参考CAS官网：CAS Client for Java 3.1根据服务器流程修改方案，我们可以知道，所有的远程请求都必须携带有loginUrl参数信息以使得服务器端知道在认证失败后转向客户端登陆页面。

而在CAS客户端上，上一节的case 4和case 5，我们主要通过提交表单的方式传递loginUrl，而case 1, case 3则是依靠org.jasig.cas.client.authentication.AuthenticationFilter类进行的转向，但使用AuthenticationFilter转向时，是没有loginUrl信息的，因此我们首先需要重新实现一个自己的认证过滤器，以下是我们自己的认证过滤器的代码：/*** 远程认证过滤器.* 由于AuthenticationFilter的doFilter方法被声明为final，* 只好重新实现一个认证过滤器，支持localLoginUrl设置.** @author GuoLin**/public class RemoteAuthenticationFilter extends AbstractCasFilter {public static final String CONST_CAS_GATEWAY ="_const_cas_gateway_";/*** 本地登陆页面URL.*/private String localLoginUrl;/*** The URL to the CAS Server login.*/private String casServerLoginUrl;/*** Whether to send the renew request or not.*/private boolean renew = false;/*** Whether to send the gateway request or not.*/private boolean gateway = false;protected void initInternal(final FilterConfig filterConfig) throws ServletException {super.initInternal(filterConfig);setCasServerLoginUrl(getPropertyFromInitParams(filterConfig, "casServerLoginUrl", null));log.trace("Loaded CasServerLoginUrl parameter: " +this.casServerLoginUrl);setLocalLoginUrl(getPropertyFromInitParams(filterConfig, "localLoginUrl", null));log.trace("Loaded LocalLoginUrl parameter: " +this.localLoginUrl);setRenew(Boolean.parseBoolean(getPropertyFromInitParams(filte rConfig, "renew", "false")));log.trace("Loaded renew parameter: " + this.renew);setGateway(Boolean.parseBoolean(getPropertyFromInitParams(fil terConfig, "gateway", "false")));log.trace("Loaded gateway parameter: " + this.gateway);}public void init() {super.init();CommonUtils.assertNotNull(this.localLoginUrl, "localLoginUrl cannot be null.");CommonUtils.assertNotNull(this.casServerLoginUrl, "casServerLoginUrl cannot be null.");}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;final HttpSession session = request.getSession(false);final String ticket =request.getParameter(getArtifactParameterName());final Assertion assertion = session != null ? (Assertion) session .getAttribute(CONST_CAS_ASSERTION) : null;final boolean wasGatewayed = session != null&& session.getAttribute(CONST_CAS_GATEWAY) != null;// 如果访问路径为localLoginUrl且带有validated参数则跳过URL url = new URL(localLoginUrl);final boolean isValidatedLocalLoginUrl =request.getRequestURI().endsWith(url.getPath()) &&CommonUtils.isNotBlank(request.getParameter("validated"));if (!isValidatedLocalLoginUrl && CommonUtils.isBlank(ticket) && assertion == null && !wasGatewayed) {log.debug("no ticket and no assertion found");if (this.gateway) {log.debug("setting gateway attribute in session");request.getSession(true).setAttribute(CONST_CAS_GATEW AY, "yes");}final String serviceUrl = constructServiceUrl(request, response);if (log.isDebugEnabled()) {log.debug("Constructed service url: " + serviceUrl); }String urlToRedirectTo = CommonUtils.constructRedirectUrl( this.casServerLoginUrl, getServiceParameterName(), serviceUrl, this.renew, this.gateway);// 加入localLoginUrlurlToRedirectTo += (urlToRedirectTo.contains("?") ? "&" : "?") + "loginUrl=" + URLEncoder.encode(localLoginUrl, "utf-8");if (log.isDebugEnabled()) {log.debug("redirecting to \"" + urlToRedirectTo + "\""); }response.sendRedirect(urlToRedirectTo);return;}if (session != null) {log.debug("removing gateway attribute from session");session.setAttribute(CONST_CAS_GATEWAY, null);}filterChain.doFilter(request, response);}public final void setRenew(final boolean renew) {this.renew = renew;}public final void setGateway(final boolean gateway) {this.gateway = gateway;}public final void setCasServerLoginUrl(final String casServerLoginUrl) {this.casServerLoginUrl = casServerLoginUrl;}public final void setLocalLoginUrl(String localLoginUrl) {this.localLoginUrl = localLoginUrl;}}以上粗体代码为修改部分，其余代码均拷贝自org.jasig.cas.client.authentication.AuthenticationFilter，可以看到我们为原有的认证过滤器增加了一个参数localLoginUrl。

合集下载

让CAS支持客户端自定义登陆页面——客户端新篇

让CAS支持客户端自定义登陆页面——客户端新篇

</tr>
<tr>
<td colspan="2"><input type="submit" value="登陆" /></td>
</tr>
</table>
<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://xuhang-PC:8443/cas/serviceValidate</param-value>
</init-param>
else
document.getElementById("service").value = location.href;
}
</script>
</head>
<body>
<h1>远程CAS客户端登陆页面</h1>
<% if (request.getSession().getAttribute("er") == null) { %>
</listener>
<!-- CAS -->
<filter>
<filter-name>CAS Single Sign Out Filter</filter-name>
<filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
CAS-单点登陆配置-resin客户端

CAS-单点登陆配置-resin客户端

CAS 单点登陆配置-Resin客户端准备工作1、认证中心机器。

XXX192.168.0.177 域名 aabbb2、需要做认证的服务器 XXX 192.168.0.105 域名 修改 177 和105 机器的hosts (system32 搜索一下)177机器修改:hosts192.168.0.177 aabbb192.168.0.105 bbbbb105机器修改:hosts192.168.0.177 aabbb192.168.0.105 bbbbb下载 casbbb:///products/cas/本例使用的是cas-server-3.0.5.zipcas-client-java-2.1.1.zipssl 认证服务器 tocat5.5客户端resin-2.0.3认证中心修改与配置机器1771、生成keystore 文件命令行模式下:keytool -genkey -alias tomcat -vali dity 365 -keyalg RSA -keystore D:\tomcat.keystore 问姓名时输入:aabbb密码infosea2、配置tomcat5 的ssl 端口:conf\server.conf<Connector port="8443" maxbbbHeaderSize="8192"maxThreads="150" minSpareThreads="25" maxSpareThreads="75"enableLookups="false" disableUploadTimeout="true"acceptCount="100" scheme="bbbs" secure="true"clientAuth="false" sslProtocol="TLS"keystoreFile="d:/tomcat.keystore" keystorePass="infosea" />访问 localhost:8443 可以访问，说明tomcat5 ssl 配置成功。

CAS之自定义登录页实践

CAS之自定义登录页实践

CAS之自定义登录页实践1. 动机用过 CAS 的人都知道 CAS-Server端是单独部署的，作为一个纯粹的认证中心。

在用户每次登录时，都需要进入CAS-Server的登录页填写用户名和密码登录，但是如果存在多个子应用系统时，它们可能都有相应风格的登录页面，我们希望直接在子系统中登录成功，而不是每次都要跳转到CAS的登录页去登录。

2. 开始分析问题其实仔细想一想，为什么不能直接在子系统中将参数提交至 cas/login 进行登录呢？于是便找到了CAS在登录认证时主要参数说明：service [OPTIONAL] 登录成功后重定向的URL地址；username [REQUIRED] 登录用户名；password [REQUIRED] 登录密码；lt [REQUIRED] 登录令牌；主要有四个参数，其中的三个参数倒好说，最关键的就是 lt , 据官方说明该参数是login ticket id, 主要是在登录前产生的一个唯一的“登录门票”，然后提交登录后会先取得"门票"，确定其有效性后才进行用户名和密码的校验，否则直接重定向至 cas/login 页。

于是，便打开CAS-Server的登录页，发现其每次刷新都会产生一个 lt, 其实就是 Spring WebFlow 中的 flowExecutionKey值。

那么问题的关键就在于在子系统中如何获取 lt 也就是登录的ticket？3. 可能的解决方案一般对于获取登录ticket的解决方案可能大多数人都会提到两种方法：AJAX: 熟悉 Ajax 的可能都知道，它的请求方式是严格按照沙箱安全模型机制的，严格情况下会存在跨域安全问题。

IFrames: 这也是早期的 ajax 实现方式，在页面中嵌入一个隐藏的IFrame，然后通过表单提交到该iframe来实现不刷新提交，不过使用这种方式同样会带来两个问题：a. 登录成功之后如何摆脱登录后的IFrame呢？如果成功登录可能会导致整个页面重定向，当然你能在form中使用属性target="_parent"，使之弹出，那么你如何在父页面显示错误信息呢？b. 你可能会受到布局的限止(不允许或不支持iframe)对于以上两种方案，并非说不能实现，只是说对于一个灵活的登录系统来说仍然还是会存在一定的局限性的，我们坚信能有更好的方案来解决这个问题。

CAS客户端服务器端配置步骤

CAS客户端服务器端配置步骤

CAS客户端服务器端配置步骤cas介绍：CAS 是Yale 大学发起的一个开源项目，旨在为Web 应用系统提供一种可靠的单点登录方法，CAS 在2004 年12 月正式成为JA-SIG 的一个项目。

CAS 具有以下特点：∙开源的企业级单点登录解决方案。

∙CAS Server 为需要独立部署的Web 应用。

∙支持非常多的客户端(这里指单点登录系统中的各个Web 应用)，包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

CAS 原理和协议从结构上看，CAS 包含两个部分：CAS Server 和CAS Client。

CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CAS Server。

图1 是CAS 最基本的协议过程：图 1. CAS 基础协议CAS Client 与受保护的客户端应用部署在一起，以Filter 方式保护受保护的资源。

对于访问受保护资源的每个Web 请求，CAS Client 会分析该请求的Http 请求中是否包含Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的CAS Server 登录地址，并传递Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。

用户在第3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的Service Ticket，并缓存以待将来验证，之后系统自动重定向到Service 所在地址，并为客户端浏览器设置一个Ticket Granted Cookie（TGC），CAS Client 在拿到Service 和新产生的Ticket 过后，在第5，6 步中与CAS Server 进行身份合适，以确保Service Ticket 的合法性。