让CAS支持客户端自定义登陆页面——客户端篇
让CAS支持客户端自定义登陆页面——客户端新篇
<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客户端准备工作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之自定义登录页实践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 是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 的合法性。
Cas自定义登录页面Ajax实现
Cas自定义登录页面Ajax实现本文是基于CAS 之自定义登录页实践及CAS 之跨域 Ajax 登录实践而实现的,主要是针对最新的Cas实现自定义登录页的Ajax跨域实现.环境:cas-server-3.5.1-releasecas地址: http://localhost:8080/cas/client地址: http://localhost/web从CAS服务端生成lt及execution,在cas的 login flow 中加入ProvideLoginTicketAction 的流,主要用于判断该请求是否是来获取lt,在cas-server端声明获取 login ticket action 类:org.jasig.cas.web.flow.ProvideLoginTicketAction1.import javax.servlet.http.HttpServletRequest;2.3.import org.jasig.cas.util.UniqueTicketIdGenerator;4.import org.jasig.cas.web.support.WebUtils;5.import org.springframework.webflow.action.AbstractActi on;6.import org.springframework.webflow.execution.Event;7.import org.springframework.webflow.execution.RequestC ontext;8.9./**10.* Opens up the CAS web flow to allow external retriev al of a login ticket.11.*12.* @author cydiay13.*/14.public class ProvideLoginTicketAction extends Abstrac tAction{15.16.private static final String PREFIX = "LT";17.18.@Override19.protected Event doExecute(RequestContext context) t hrows Exception {20.final HttpServletRequest request = WebUtils.getHttpS ervletRequest(context);21.if (request.getParameter("get-lt") != null && request.getParameter("get-lt").equalsIgnoreCase("true")) {22.final String loginTicket = this.ticketIdGenerator.getNe wTicketId(PREFIX);23.WebUtils.putLoginTicket(context, loginTicket);24.return result("loginTicketRequested");25.}26.return result("continue");27.}28.29.private UniqueTicketIdGenerator ticketIdGenerator;30.31.public void setTicketIdGenerator(final UniqueTicketId Generator generator) {32.this.ticketIdGenerator = generator;33.}34.}并且将该 action 声明在 cas-servlet.xml 中:查看文本打印?1.<bean id="provideLoginTicketAction" class="org.jasig.cas .web.flow.ProvideLoginTicketAction"2.p:ticketIdGenerator-ref="loginTicketUniqueIdGenerator"/>还需要定义loginTicket 的生成页也就是当返回loginTicketRequested 的 view:位置/WEB-INF/view/jsp/default/uiviewRedirectToRequestor.jsp查看文本打印?1.<%@ page contentType="text/html; charset=UTF-8"%>2.<%3.String ajax = request.getParameter("n");4.//当执行Ajax自<strong><strong>定义</strong></strong><strong><strong>页面</strong></strong>时执行以下操作5.if(ajax!=null && ajax.length()>0){6.response.getWriter().print(request.getAttribute("loginTick et")+"&"+request.getAttribute("flowExecutionKey"));7.} else {8.9.//正常cas执行10.%>11.<script>window.location.href = "/cas/login";</script>12.<%13.}14.%>并且需要将该 jsp 声明在 default._views.properites 中:casRedirectToRequestorView.(class)=org.springframework.w eb.servlet.view.JstlViewcasRedirectToRequestorView.url=/WEB-INF/view/jsp/default/ui/viewRedirectToRequestor.jsp接下来要做的就是将该action 的处理加入到 login-webflow.xml 请求流中:查看文本打印?1.<on-start>2.<evaluate expression="initialFlowSetupAction" />3.</on-start>4.5.<action-state id="provideLoginTicket">6.<evaluate expression="provideLoginTicketAction"/>7.<transition on="loginTicketRequested" to="viewRedirect ToRequestor" />8.<transition on="continue" to="ticketGrantingTicketExists Check" />9.</action-state>10.11.<view-state id="viewRedirectToRequestor" view="casRedirectT oReques torView" model="credentials">12.<binder>13.<binding property="username" />14.<binding property="password" />15.</binder>16.<on-entry>17.<set name="mandName" value="'cred entials'" />18.</on-entry>19.<transition on="submit" bind="true" validate="true" t o="realSubmit">20.<set name="flowScope.credentials" value="credential s" />21.<evaluate expression="authenticationViaFormAction. doBind(flowRequestContext, flowScope.credentials)" />22.</transition>23.</view-state>24.25.<decision-state id="ticketGrantingTicketExistsCheck">26.<if test="flowScope.ticketGrantingTicketId != null" the n="hasServiceCheck" else="gatewayRequestCheck" />27.</decision-state>调整 CAS Server端,使其适应 Iframe 方式登录,并使其支持回调。
让CAS支持客户端自定义登陆页面——服务器新篇
让CAS支持客户端自定义登陆页面——服务器新篇最近公司研发产品,将基于CAS的SSO列为了研究方向之一,统一登录统一认证还是比较简单的,因为领导指示,还要适应分散登录统一认证,所以还是要努力去实现。
在网上搜了搜,有一篇“让CAS支持客户端自定义登陆页面”的文章,分服务器篇和客户端篇两个部分,思路符合的,也提供了挺详细的代码,但问题是该文章是基于spring web flow 1.X的,现在的CAS服务是3.4.10版本,其内部流程用的是spring web flow 2.X版本。
spring web flow 2.X和spring web flow 1.X不是向下兼容的,基本上流程代码是不能用了。
我做了大量的修改,目前远程登录和远程退出都实现了,现在将符合spring web flow 2.X 的做法记录下来,和需要的朋友们共享。
接下来我们讲解服务器端修改的详细过程:1、修改/WEB-INF/web.xml,为cas增加一个/remoteLogin和//remoteLogout的映射,否则总是会转到login那个请求去了:<servlet-mapping><servlet-name>cas</servlet-name><url-pattern>/remoteLogin</url-pattern></servlet-mapping><servlet-mapping><servlet-name>cas</servlet-name><url-pattern>/remoteLogout</url-pattern></servlet-mapping>2、然后修改cas-servlet.xml文件,增加对/remoteLogin和/remoteLogout映射的处理,需要增加两个新流程:<!-- 增加远程控制者,允许以/remote请求启动remote控制流程 --><bean id="handlerMappingB" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"><property name="mappings"><props><prop key="/remoteLogin">remoteLoginController</prop><prop key="/remoteLogout">remoteLogoutController</prop></props></property><property name="interceptors"><list><ref bean="localeChangeInterceptor" /></list></property></bean><bean id="remoteLoginController" class="org.springframework.webflow.mvc.servlet.FlowController"><property name="flowExecutor" ref="remoteLoginFlowExecutor" /><property name="flowUrlHandler" ref="flowUrlHandler"/> </bean><webflow:flow-executor id="remoteLoginFlowExecutor" flow-registry="remoteLoginFlowRegistry"><webflow:flow-execution-attributes><webflow:always-redirect-on-pause value="false"/></webflow:flow-execution-attributes></webflow:flow-executor><webflow:flow-registry id="remoteLoginFlowRegistry" flow-builder-services="builder"><webflow:flow-location path="/WEB-INF/remoteLogin-webflow.xml" id="remoteLogin"/></webflow:flow-registry><webflow:flow-builder-services id="flowBuilderServices" view-factory-creator="viewFactoryCreator"/><bean id="remoteLoginAction" class="com.cas.web.flow.RemoteLoginAction"p:argumentExtractors-ref="argumentExtractors"p:warnCookieGenerator-ref="warnCookieGenerator"p:ticketGrantingTicketCookieGenerator-ref="ticketGrantingTicketCookieGenera tor" /><bean id="remoteLogoutController" class="org.springframework.webflow.mvc.servlet.FlowController"><property name="flowExecutor" ref="remoteLogoutFlowExecutor" /><property name="flowUrlHandler" ref="flowUrlHandler"/> </bean><webflow:flow-executor id="remoteLogoutFlowExecutor" flow-registry="remoteLogoutFlowRegistry"><webflow:flow-execution-attributes><webflow:always-redirect-on-pause value="false"/></webflow:flow-execution-attributes></webflow:flow-executor><webflow:flow-registry id="remoteLogoutFlowRegistry" flow-builder-services="builder"><webflow:flow-location path="/WEB-INF/remoteLogout-webflow.xml" id="remoteLogout"/></webflow:flow-registry><bean id="remoteLogoutAction" class="com.cas.web.flow.RemoteLogoutAction"p:argumentExtractors-ref="argumentExtractors"p:warnCookieGenerator-ref="warnCookieGenerator"p:ticketGrantingTicketCookieGenerator-ref="ticketGrantingTicketCookieGenera tor"p:centralAuthenticationService-ref="centralAuthenticationService"/>3、流程定义的xml文件:可以看到上面将请求指向了webflow配置文件/WEB-INF/remoteLogin-webflow.xml和/WEB-INF/remoteLogout-webflow.xml,我们需要创建此文件并配置其成为我们所需的流程。
让cas支持客户端自定义登陆页面----服务器篇-
让CAS支持客户端自定义登陆页面——服务器篇 - [Dev elopment]2009-03-23版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明上篇《让CAS支持客户端自定义登陆页面——原理篇》讲述了一些修改的理论基础,这篇讲解如何对CA S服务器端进行修改。
修改需要基于几个基本原则:1.不影响原有统一登陆界面功能2.客户端应尽量保持简单3.尽量保证原有功能的完整性和安全性对于第三点,必须事先说明:将登陆页面放到客户端本身就是降低了CAS安全性,这意味着作为服务向外发布的CAS服务器中的用户密码有可能由于客户端的不安全性而导致泄露,整个CAS系统成为了一个“水桶形态”,整个CAS体系的安全性将取决于所有客户端中安全性最低的一个。
这也是CAS官方一直不推荐的方式。
接下来我们讲解服务器端修改的详细过程:首先,修改/WEB-INF/,为cas增加一个/remoteLogin的映射:<servlet-mapping><servlet-name>cas</servlet-name><url-pattern>/remoteLogin</url-pattern></servlet-mapping>然后修改文件,增加我们对/remoteLogin映射的处理,需要增加一个新流程:<bean id="handlerMappingB" class=""><property name="mappings"><props><prop key="/login">loginController</prop><prop key="/remoteLogin">remoteController</prop> </props></property><property name="interceptors"><list><ref bean="localeChangeInterceptor" /></list></property></bean>然后在文件中添加我们上面所配置的remoteController的bean:<!-- 增加远程控制者,允许以/remote请求启动remote控制流程 --><bean id="remoteLoginController"class=""p:flowExecutor-ref="remoteLoginFlowExecutor"p:defaultFlowId="remoteLogin-webflow"><property name="argumentHandler"><beanclass=""p:flowExecutionKeyArgumentName="lt"p:defaultFlowId="remoteLogin-webflow" /></property></bean><flow:executor id="remoteLoginFlowExecutor" registry-ref="remoteLoginFlowRegistry"> <flow:execution-attributes><flow:alwaysRedirectOnPause value="false"/></flow:execution-attributes></flow:executor><flow:registry id="remoteLoginFlowRegistry"><flow:location path="/WEB-INF/"/></flow:registry>可以看到上面将请求指向了webflow配置文件/WEB-INF/文件,我们需要创建此文件并配置其成为我们所需的流程,以下是全文:<xml version="" encoding="UTF-8"><flow xmlns=""xmlns:xsi=""xsi:schemaLocation=""><start-state idref="remoteLogin"/><!-- 远程登陆主要Action --><action-state id="remoteLogin"><action bean="remoteLoginAction" /><transition on="error" to="remoteCallbackView" /><transition on="submit" to="bindAndValidate" /><transition on="checkTicketGrantingTicket" to="ticketGrantingTicketExistsCheck" /></action-state><!-- 远程回调页面,主要以JavaScript的方式回传一些参数用 --><end-state id="remoteCallbackView" view="remoteCallbackView" /><decision-state id="ticketGrantingTicketExistsCheck"><if test="${ != null}" then="hasServiceCheck"else="gatewayRequestCheck" /></decision-state><decision-state id="gatewayRequestCheck"><if test="${['gateway'] != '' && ['gateway'] != null && != nu ll}" then="redirect" else="remoteCallbackView" /></decision-state><decision-state id="hasServiceCheck"><if test="${ != null}" then="generateServiceTicket" else="remoteCallbackView" /></decision-state><!--The "warn" action makes the determination of whether to redirect directly to the requestedservice or display the "confirmation" page to go back to the server.--><decision-state id="warn"><if test="${}" then="showWarningView" else="redirect" /></decision-state><action-state id="bindAndValidate"><action bean="authenticationViaFormAction" /><transition on="success" to="submit" /><transition on="error" to="remoteCallbackView" /></action-state><action-state id="submit"><action bean="authenticationViaFormAction" method="submit" /><transition on="warn" to="warn" /><transition on="success" to="sendTicketGrantingTicket" /><transition on="error" to="remoteCallbackView" /> </action-state><action-state id="sendTicketGrantingTicket"><action bean="sendTicketGrantingTicketAction" /><transition on="success" to="serviceCheck" /> </action-state><decision-state id="serviceCheck"><if test="${ != null}" then="generateServiceTicket" else="remoteCallbackView" /></decision-state><action-state id="generateServiceTicket"><action bean="generateServiceTicketAction" /><transition on="success" to ="warn" /><transition on="error" to="remoteCallbackView" /><transition on="gateway" to="redirect" /></action-state><!--The "showWarningView" end state is the end state for when the user has requested privacy settings (to be "warned") to be turned on. It delegates to aview defines in that display the "Please click here to goto the service." message.--><end-state id="showWarningView" view="casLoginConfirmView" /><!--The "redirect" end state allows CAS to properly end the workflow while still redirectingthe user back to the service required.--><end-state id="redirect" view="bean:dynamicRedirectViewSelector" /><end-state id="viewServiceErrorView" view="viewServiceErrorView" /><end-state id="viewServiceSsoErrorView" view="viewServiceSsoErrorView" /><global-transitions><transition to="viewServiceErrorView" on-exception="" /><transition to="viewServiceSsoErrorView" on-exception="" /><transition to="viewServiceErrorView" on-exception="" /></global-transitions></flow>以上文件根据原文件修改,黄色背景为修改部分。
cas单点登录客户端说明文档
Java Web应用CAS Client端的配置详解配置环境:1. CAS Server 4.0已部署,跑在tomcat 7上。
部署在/cas上(本地hosts 文件配置域名)。
2. CAS Client web应用也跑在tomcat 7上,部署在/app(本地hosts文件配置域名)。
以下是各种web应用集成CAS的处理信息://=========没有使用特定安全框架如shiro的情况==========配置步骤:1).添加cas-client-core-3.1.10-sources.jar,如使用mvn,pom.xml中添加<dependency><groupId>org.jasig.cas</groupId><artifactId>cas-client-core</artifactId><version>3.1.10</version><exclusions><exclusion><artifactId>servlet-api</artifactId><groupId>javax.servlet</groupId></exclusion></exclusions></dependency>2). web.xml中添加:<!-- 与CAS Single Sign Out Filter配合,注销登录信息--><listener><listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class></listener><!-- CAS Server 通知CAS Client,删除session,注销登录信息--><filter><filter-name>CAS Single Sign Out Filter</filter-name><filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class></filter><filter-mapping><filter-name>CAS Single Sign Out Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping><!-- 登录认证,未登录用户导向CAS Server进行认证--><filter><filter-name>CAS Filter</filter-name><filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> <init-param><param-name>casServerLoginUrl</param-name><param-value>/cas/login</param-value> </init-param><init-param><param-name>serverName</param-name><param-value></param-value></init-param></filter><filter-mapping><filter-name>CAS Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping><!-- CAS Client向CAS Server进行ticket验证--><filter><filter-name>CAS Validation Filter</filter-name><filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class><init-param><param-name>casServerUrlPrefix</param-name><param-value>/cas</param-value> </init-param><init-param><param-name>serverName</param-name><param-value></param-value> </init-param></filter><filter-mapping><filter-name>CAS Validation Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping><!-- 封装request, 支持getUserPrincipal等方法--><filter><filter-name>CAS HttpServletRequest Wrapper Filter</filter-name><filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class> </filter><filter-mapping><filter-name>CAS HttpServletRequest Wrapper Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping><!-- 存放Assertion到ThreadLocal中--><filter><filter-name>CAS Assertion Thread Local Filter</filter-name><filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class></filter><filter-mapping><filter-name>CAS Assertion Thread Local Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping>3). 编写个简单的测试页面test.jsp进行测试。
cas单点登录自定义servicevalidate方法 -回复
cas单点登录自定义servicevalidate方法-回复CAS(Central Authentication Service)是一种常见的单点登录(Single Sign-On)解决方案,它通过集中验证用户身份,实现在不同的服务之间无需重复登录的便利。
虽然CAS已经提供了一套完善的验证流程,但有时我们可能需要根据特定的需求自定义`serviceValidate`方法。
本文将逐步介绍如何实现CAS单点登录自定义`serviceValidate`方法,并解释其作用,以及如何应用于实际项目中。
第一步:了解CAS验证流程在开始自定义`serviceValidate`方法之前,我们首先需要了解CAS的验证流程。
以下是一般情况下CAS的验证流程:1. 用户打开客户端应用程序,并尝试访问需要登录的资源。
2. 客户端应用程序将用户重定向到CAS服务器。
3. CAS服务器显示登录页面,用户在该页面输入用户名和密码。
4. CAS服务器验证凭证的正确性,并生成一个票据(ticket)。
5. CAS服务器将用户重定向回客户端应用程序,并将票据附加在URL中。
6. 客户端应用程序接收到票据后,将其发送给CAS服务器进行验证。
7. CAS服务器对票据进行验证,验证通过后返回用户信息给客户端应用程序。
8. 客户端应用程序使用返回的用户信息进行授权操作,允许用户访问资源。
在这个流程中,`serviceValidate`方法负责对票据进行验证,并返回用户信息。
第二步:CAS服务端配置要自定义`serviceValidate`方法,我们首先需要对CAS服务端进行配置。
假设我们已经搭建好了CAS服务端,并且熟悉CAS的基本配置。
首先,我们需要编辑`cas.properties`文件,该文件包含了CAS服务端的配置信息。
在该文件中,找到以下配置项:cas.service.ticket.registry.core.ticketCatalog=org.apereo.cas.ticket. DefaultTicketCatalog将上述配置项替换为:cas.service.ticket.registry.core.ticketCatalog=org.apereo.cas.ticket.r egistry.DefaultTicketRegistry这将启用默认的票据注册,以便我们在自定义`serviceValidate`方法中使用。
cas标准对接方式
cas标准对接方式
CAS标准的对接方式主要是通过CAS服务实现的。
CAS 服务是一种单点登录服务,可以提供统一的认证和授权管理,支持多种应用系统间的单点登录和统一认证。
对接CAS服务的方式通常包括以下步骤:
1. 搭建CAS服务:部署CAS服务器,配置认证和授权规则,以及其他相关参数。
2. 客户端集成:在需要对接的应用系统中集成CAS客户端库,以便能够与CAS服务器进行通信。
3. 配置认证和授权:在客户端配置认证和授权信息,包括用户名、密码、角色等。
4. 单点登录:用户在登录时,通过CAS客户端向CAS 服务器发送认证请求,如果认证成功,则返回一个会话令牌(session token)。
5. 访问控制:客户端使用会话令牌向CAS服务器请求访问受保护的资源,如果令牌有效且具有足够的权限,则允许访问资源。
6. 会话管理:客户端可以使用会话令牌来管理用户的会话状态,例如检查会话是否过期、获取当前用户的角色和信息等。
在对接过程中,需要注意以下几点:
1. 选择合适的CAS客户端库,根据应用系统的架构和需求选择适合的库进行集成。
2. 配置认证和授权规则时,需要考虑到不同应用系统的特点和需求,以及安全性和性能方面的要求。
3. 在客户端集成CAS客户端库时,需要注意与应用的其它部分(如登录页面、权限管理页面等)的协调和交互。
4. 在使用会话令牌时,需要注意令牌的生成、传递、验证等环节的安全性和正确性。
cas单点登录系统:客户端(client)详细配置
cas单点登录系统:客户端(client)详细配置最近⼀直在研究cas登录中⼼这⼀块的应⽤,分享⼀下记录的⼀些笔记和⼼得。
后⾯会把cas-server端的配置和重构,另外还有这⼏天再搞nginx+cas的https反向代理配置,以及cas的证书相关的知识分享出来。
Cas由两部分组成,Cas Server和Cas Client。
Cas Server是Cas⾃⼰的服务端,⽽Cas Client是Cas客户端,往往客户端需要和我们具体的业务系统进⾏集成,这⾥我们主要详述cas 客户端的配置以及实例第⼀步:我们得有⼀个现成的web项⽬,然后我们要加⼊cas-client-core-xxx.jar到classpath;maven项⽬⽤这个:<dependency><groupId>org.jasig.cas.client</groupId><artifactId>cas-client-core</artifactId><version>3.3.3</version></dependency>第⼆步:配置Filter我们需要在应⽤的web.xml⽂件中配置四个Filter,这四个Filter必须按照固定的顺序来进⾏配置,⽽且它们必须配置在应⽤的其它Filter之前。
它们的先后顺序要求如下:1、AuthenticationFilter2、TicketValidationFilter3、HttpServletRequestWrapperFilter4、AssertionThreadLocalFilter1.1、 配置AuthenticationFilter1.1.1、AuthenticationFilter有两个必须指定的参数:casServerLoginUrl⽤来指定Cas Server登录地址,serverName或service⽤来指定认证成功后需要跳转地址。
springboot项目使用cas进行单点登录-客户端实现
springboot项⽬使⽤cas进⾏单点登录-客户端实现说明:cas的服务器端已经配置完了,现在来编写客户端1:创建⼀个简单的springboot项⽬2:添加cas-client包<!--cas client --><dependency><groupId>net.unicon.cas</groupId><artifactId>cas-client-autoconfig-support</artifactId><version>2.1.0-GA</version></dependency>3:配置服务器server.port=8888#cas服务端地址cas.validation-type=cas34:开启cas//启动CAS @EnableCasClient@EnableCasClient@SpringBootApplicationpublic class DemoApplication {public static void main(String[] args) {SpringApplication.run(DemoApplication.class, args);System.out.println("success~");}}5:根据keystore⽣成证书,有使⽤到密码的,是在服务端设置的,默认的changeitkeytool -exportcert -alias cas -keystore D:/angiiiin.keystore -file D:/angiiiin.keystore.cer -storepass 1234566:把证书导⼊到jre的相应路径,这个证书是可以删除的keytool -import -alias cas -keystore D:/Java/jdk1.8.0_131/jre/lib/security/cacerts -file D:/angiiiin.keystore.cer7:写⼀个⼩测试@RestControllerpublic class Test1 {@RequestMapping("/test1")public String test1(){return "cas test1....";}}启动客户端登录就可以看到再创建⼀个项⽬,配置同⼀个cas服务器,就可以看到单点登录的效果了。
CAS的客户端与服务器配置
一.生成证书并配置服务器:(域名:)第一步:为服务器生成证书:(C:\Program Files\Java\jdk1.6.0_19\bin>)keytool -genkey -v -alias server -keyalg RSA -validity 365 -keystore D:\pccw.keystore -dname "CN=,OU=cn,O=cn,L=cn,ST=cn,C=cn" -storepass 111111 -keypass 111111 //其中CN的值为域名第二步:为客户端生成证书:(C:\Program Files\Java\jdk1.6.0_19\bin>)keytool -genkey -v -alias client -keyalg RSA -storetype PKCS12 -keystore D:\pccw.p12 -dname "CN=,OU=cn,L=cn,ST=cn,C=cn" -storepass 111111 -keypass 111111第三步:让服务器信任客户端证书:(C:\Program Files\Java\jdk1.6.0_19\bin>)keytool -export -alias client -keystore D:\pccw.p12 -storetype PKCS12 -storepass 111111 -rfc -file d:\pccw.cer第四步:将该文件导入到服务器的证书库,添加为一个信任证书:(C:\Program Files\Java\jdk1.6.0_19\bin>)keytool -import -v -file D:\pccw.cer -keystore D:\pccw.keystore -storepass 111111keytool -import -alias pccw -keystore cacerts -file D:\pccw.cer -trustcacerts第五步:通过list命令查看服务器的证书库,我们可以看到两个输入,一个是服务器证书,一个是受信任的客户端证书L:(C:\Program Files\Java\jdk1.6.0_19\bin>)keytool -list -keystore D:\pccw.keystore -storepass 111111完成后将生成的.keystore文件放到Tomcat中的conf目录下修改Tomcat中的srever.xml文件:这段代码本来是注释掉的,把注释去掉,并且加上两个属性之后,如下:<Connector port="8443" maxHttpHeaderSize="8192"maxThreads="150" minSpareThreads="25" maxSpareThreads="75"enableLookups="false" disableUploadTimeout="true"acceptCount="100" scheme="https" secure="true"keystoreFile="conf/odc.keystore" keystorePass="111111"clientAuth="false" sslProtocol="TLS"/>//keystoreFile="conf/server.keystore" 根据实际路径改写//keystorePass="111111" 设置密码将cas-server-3.4.8\modules中的cas-server-webapp-3.4.8.war复制到Tomcat中的webapps目录下,并改名为cas.war开启服务器并输入https://localhost:8443/cas查看是否显示页面P.S. 删除:keytool -delete -trustcacerts -alias tomcat -keystore D:/sdks/jdk1.5.0_11/jre/lib/security/cacerts -storepass changeit 、二.部署客户端:A为cas服务器B为其他电脑上的应用在B电脑中作如下操作:像前面一样生成证书文件下载InstallCert.java文件,javac编译,生成两个文件(InstallCert$SavingTrustManager.class 和InstallCert.class),运行"java InstallCert compA:8443"命令,并且在接下来出现的询问中输入1这样,就将A 添加到了B 的trust store 中。
cas方案
cas方案CAS方案1. 简介CAS(Central Authentication Service)是一个开源的单点登录协议,也是一种常用的认证解决方案。
它提供了一种安全的方式,使用户只需要登录一次就可以访问多个相互信任的应用系统。
2. CAS的特点CAS方案具有以下几个特点:- 单点登录:用户只需要登录一次,即可访问多个应用系统,无需多次输入用户名和密码。
- 安全性:CAS采用票据机制,用户的密码不直接传递给应用系统,提高了用户密码的安全性。
- 高可扩展性:CAS可以集成到各种应用系统中,无论是Java、.NET,还是其他编程语言,都可以使用CAS进行认证。
- 自定义登录页面:CAS提供了自定义登录页面的功能,可以根据实际需求进行定制。
- 集群支持:CAS支持集群部署,提供了高可用性和负载均衡的能力。
3. CAS方案的工作原理CAS方案的工作原理如下:1. 用户访问应用系统A,由于没有登录,应用系统A重定向用户到CAS服务器的登录页面。
2. 用户在CAS服务器的登录页面输入用户名和密码进行认证。
3. CAS服务器认证通过后,生成一个票据,并将该票据返回给用户的浏览器。
4. 用户浏览器将带有票据的请求发送到应用系统A。
5. 应用系统A拿到票据后,向CAS服务器发送验证请求,验证票据的有效性。
6. CAS服务器验证通过后,应用系统A将用户登录信息保存到会话中,并允许用户访问。
7. 用户访问其他应用系统B,在没有登录的情况下,应用系统B也会将用户重定向到CAS服务器进行认证。
8. CAS服务器验证通过后,将用户登录信息返回给应用系统B,允许用户访问。
9. 用户访问其他应用系统C,同样会进行CAS认证。
4. CAS的部署和配置以下是部署和配置CAS方案的简要步骤:1. 下载CAS服务器的安装包,并解压到指定目录。
2. 配置CAS服务器的认证方式,可以使用数据库、LDAP等进行认证。
3. 配置CAS服务器的票据存储方式,可以选择将票据存储在内存、数据库等位置。
cas 解决方案
CAS 解决方案简介CAS(Central Authentication Service)是一种企业级的单点登录(SSO)解决方案。
它提供了一种安全的方式,在多个应用程序之间实现单一的认证机制。
CAS 通过集中管理用户身份信息,将用户认证的责任从各个应用程序中解耦,提供了更高的安全性和便利性。
本文将介绍 CAS 的基本原理和部署方案,以及常见的问题和解决方案。
CAS 基本原理CAS 的基本原理是通过一个中央认证服务器进行用户认证,并颁发一个全局的认证票据(ticket)。
这个 ticket 可以被其他应用程序验证,从而实现用户在多个应用程序之间的无缝访问。
CAS 的工作流程如下:1.用户访问需要认证的应用程序,应用程序检测到用户未登录。
2.应用程序重定向用户到 CAS 服务器的登录页面。
3.用户在 CAS 服务器上输入用户名和密码进行认证。
4.CAS 认证成功后,将一个 ticket 返回给用户的浏览器。
5.用户浏览器重定向回原始应用程序,并带上 ticket。
6.应用程序收到 ticket 后,向 CAS 服务器验证 ticket 的有效性。
7.CAS 服务器返回 ticket 的验证结果。
8.应用程序根据验证结果,决定是否允许用户访问。
CAS 部署方案CAS 的部署可以分为以下几个步骤:1. 安装 CAS 服务器CAS 服务器可以使用官方提供的 war 包进行安装。
首先需要准备一个 servlet 容器,如 Tomcat。
然后将 war 包部署到容器中,并配置相应的参数。
2. 配置 CAS 服务器CAS 服务器的配置文件主要包括cas.properties和cas.serviceRegistry.json两个文件。
cas.properties文件用于配置 CAS 服务器的基本信息,如认证方式、认证源、票据有效期等。
cas.serviceRegistry.json文件用于配置应用程序的信息,包括应用程序的名称、访问地址等。
cas服务器端以及客户端部署
cas服务器端以及客户端部署一、服务器端部署(普通[http])使用该种配置,不需要再生成证书,而且访问的时候可以使用http,所以比https相比配置以及使用更加方便。
1.修改cas\WEB-INF\deployerConfigContext.xml修改dataSource标签,配置数据源。
注:本例中我们是以oracle为例,lib包有oracle、db2、sqlserver的驱动,如果想配置其他数据库,不但需要配置该数据源还需要把相应的驱动jar包放到lib中。
2.修改cas\WEB-INF\spring-configuration\ticketGrantingTicketCookieGenerator.xml<beanid="ticketGrantingTicketCookieGenerator"class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"p:cookieSecure="false"p:cookieMaxAge="-1"p:cookieName="CASTGC"p:cookiePath="/cas" />通过修改该项配置文件,cas即可支持http形式的访问。
1.1升级cas1.拷贝WEB-INF\classes\org\jasig\cas\servlet文件夹至升级后的环境。
2.在cas的web.xml中增加验证用户名密码的servlet<servlet><servlet-name>validateCode</servlet-name><servlet-class>org.jasig.cas.servlet.ValidatorServlet</servlet-class></servlet><servlet-mapping><servlet-name>validateCode</servlet-name><url-pattern>/servlet/validateCodeServlet</url-pattern></servlet-mapping>3.拷贝WEB-INF\view\jsp\default\ui\casLoginView.jsp至升级后的环境。
cas单点登录自定义servicevalidate方法 -回复
cas单点登录自定义servicevalidate方法-回复CAS (Central Authentication Service) 单点登录是一种用于实现跨应用系统的用户身份认证的开源技术。
在CAS 中,serviceValidate 方法是用于验证用户登录请求的重要方法。
本文将详细介绍CAS 单点登录的基本原理和serviceValidate 方法的自定义过程。
1. CAS 单点登录的基本原理CAS 单点登录基于用户认证的中心模型,其中包括以下几个角色和流程:- 用户:通过输入用户名和密码进行认证。
- CAS Server(认证服务器):负责处理用户的认证请求,验证用户身份,并生成用于标识用户身份的票据(Ticket)。
- CAS Client(客户端应用):在应用系统的登录页面中引入CAS 客户端,负责将用户的身份认证请求发送至CAS Server 进行认证,以及处理CAS Server 返回的票据。
- Ticket-Granting Ticket(TGT):CAS Server 生成的用于标识用户身份的票据,是用户在CAS Server 上进行认证成功后获取的。
- Service Ticket(ST):CAS Client 在CAS Server 上成功完成认证后,返回的用于标识用户身份的票据,用于访问其他应用系统。
单点登录流程:1) 用户访问客户端应用系统,并未登录,需要进行登录操作。
2) 客户端应用系统重定向至CAS Server 的登录页面,将用户请求重定向至CAS Server 进行认证。
3) 用户输入用户名和密码进行认证。
4) CAS Server 验证用户身份,生成TGT 并返回给客户端应用系统。
5) 客户端应用系统将TGT 存储在本地,以备后续使用。
6) 客户端应用系统向CAS Server 发送TGT,请求生成ST。
7) CAS Server 验证TGT 的有效性,生成ST 并返回给客户端应用系统。
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 的合法性。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
客户端实现目标客户端实现主要需要满足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。