cas登录username和passwo
- 作者: 烟花半夏
- 来源: 51数据库
- 2020-06-05
1.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， 主要是在登录前产生的一个唯一的“登录门票”，然e799bee5baa6e997aee7ad94e59b9ee7ad9431333431333965后提交登录后会先取得"门票"，确定其有效性后才进行用户名和密码的校验，否则直接重定向至 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）
对于以上两种方案，并非说不能实现，只是说对于一个灵活的登录系统来说仍然还是会存在一定的局限性的，我们坚信能有更好的方案来解决这个问题。
4. 通过JS重定向来获取login ticket (lt)
当第一次进入子系统的登录页时，通过 JS 进行redirect到cas/login?get-lt=true获取login ticket，然后在该login中的 flow 中检查是否包含get-lt=true的参数，如果是的话则跳转到lt生成页，生成后，并将lt作为该redirect url 中的参数连接，如 remote-login.html?lt=e1s1，然后子系统再通过JS解析当前URL并从参数中取得该lt的值放置登录表单中，即完成 lt 的获取工作。其中进行了两次 redirect 的操作。
5. 开始实践
首先，在我们的子系统中应该有一个登录页面，通过输入用户名和密码提交至cas认证中心。不过前提是先要获取到 login tickt id. 也就是说当用户第一次进入子系统的登录页面时，在该页面中会通过js跳转到 cas/login 中的获取login ticket. 在 cas/login 的 flow 中先会判断请求的参数中是否包含了 get-lt 的参数。
在cas的 login flow 中加入 ProvideLoginTicketAction 的流，主要用于判断该请求是否是来获取 lt，在cas-server端声明获取 login ticket action 类：
com.denger.sso.web.ProvideLoginTicketAction
2.有人知道 cas单点登录系统是怎么样取得proxyticket的
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 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。 准备工作 本文中的例子以 tomcat5.5 为例进行讲解，下载地址： = response.read()
print html
if __name__ == '__main__':
main()
6.cas单点登录怎么在服务器端获得用户信息
通过上述部署与配置，多个Web应用已经可以共用一个登录服务。
但是，上述过程中作为CAS Client端的Web应用只取得了用户登录名称信息，而在实际应用中，Web应用往往需要获得登录用户更多的信息，例如会员等级、性别、住址等。要达到此目的，只需对Server端稍做修改即可实现。
1. 服务端配置及修改假定上述存储用户信息的数据表userinfo中还包含一个名为address的用于存储用户地址的字段，而Web应用程序希望能够从CAS Server处获得当前登录用户的地址信息，则Server端需要按以下内容修改deployerConfigContext.xml。部分配置说明请参见注释。
<！--将原有attributerepository配置注释 --=""> <> 具体修改如下： <%@pageimport="org.jasig.cas.client.authentication.AttributePrincipal" %>。 转载请注明出处51数据库 » cas登录username和passwo
