单点登录 - CAS【六】renew、gateway

一、Renew: Opting out of SSO

    看下官方网站上的描述 

There is a feature of the CAS protocol that allows clients to opt out of single sign on. This feature is called renew. It allows a client to advise the CAS server login to always authenticate a user regardless of whether a single sign on session already exists.

This is a useful feature for when there are certain services that would like to use CAS as the authentication mechanism but allow access to sensitive material. They can force CAS to reauthenticate a user to ensure that they are signing in the correct user (and its not a pre-existing SSO session that wasn't terminated.

To tell CAS to renew the credentials, the client application should redirect the user with a URL similar to the following:

https://server/cas/login?service=serviceUrl&renew=true

When requesting validation of a ticket, a client can ask it to ensure that the ticket is from a new authentication request.

大意如下吧：

CAS协议允许客户端选择是否跳出单点登录（强制重新登录），这就是renew。它允许一个客户端通知CAS服务器总是验证一个用户，不管一个单点登录的session是否存在。这是一个非常有用的属性，当一个特定的使用CAS认证机制的服务允许访问敏感资料时，它能强迫CAS重新认证一个用户，确保登录的是一个正确的用户。这时，那个应经存在的单点登录session应该是被终止的。使用这个属性通知CAS重新验证凭证时，客户端应用应该重定向用户到以下的URL上：https://server/cas/login?service=serviceUrl&renew=true。当请求验证这个票据时，客户端可以要求CAS确保这个票据是来自一个新的认证请求。

 

二、Gateway

   

This page documents the Gateway feature of the CAS protocol and the protocol-implementing CAS Server.

What is the Gateway feature?

CAS Server includes a feature whereby you can set the request parameter "gateway" to "true" on the request for CAS login. If "gateway" is "true", then CAS will not paint the user login screen. If it can accomplish authentication by single sign on - that is, by detecting the CAS ticket granting cookie - then it will redirect to the URL specified by the "service" parameter with a valid service ticket. If it cannot accomplish single sign on, then it will redirect to the "service" URL without painting any login screen.

This allows your application to detect and take advantage of user single sign on without bothering the user with a login screen in the case where he or she is not yet logged on. This is useful for main pages and is probably a "best practice", since it allows the user to learn about the service to which he might authenticate before being abruptly presented with the CAS login screen out of context.

What is required of a CAS Client to support this feature?

A gateway-supporting CAS client should:

1. provide a mechanism for the application developer/deployer/htaccess writer to elect the gateway behavior
2. when gateway is elected:
   1. set the request parameter "gateway" to be "true" on the CAS login request
   2. provide a way to indentify the request when it is redirected back from CAS as one that has already been gatewayed (e.g., a special parameter on the URL-encoded "service", setting a cookie, using already-present session support from your environment, etc.)
3. receive requests redirected back from CAS. These may have the "ticket" parameter set, in which case validate the ticket, etc. If gatewaying failed to pick up a single sign on session, the request will be for the URL specified as the "service" parameter "bare" - the "ticket" parameter will not be set, and CAS does not set any other parameter to indicate that it had gatewayed. The client needs to recognize the request as having already come through gateway. The client should not redirect already-gatewayed requests back to CAS for more gatewaying, because this will lead to an infinite loop of redirecting back and forth between server and client.

CAS is authentication, not authorization. The standard use case for CAS is that the client application wants to consume the authenticated username. Under gateway, when there is no authenticated username because we came back from CAS ticketless, the client should do something like returning "null" when the client application asks for the authenticated username, or fail to set the remote user header, or put null into the session where the application expected to lookup the authenticated user, etc., as applicable to the CAS client implementation.

In the case where one is using CAS for authorization (probably a bad idea in the first place) - users able to authenticate are authorized to access the resource, and users unable to authenticate are not authorized - then GATEWAY should not be used.

 

    如果设定这个参数，CAS将不会向客户端索要凭据。 

• 如果客户端有一个已存在的CAS单点登录的session，或者如果单点登录session可以通过非交互方式（i.e. trust authentication，信托认证）建立，CAS可以将客户端请求重定向到“service”参数指定的URL，而且还加上有效的服务票据（Service Ticket，ST）。 （CAS还可以插入一个通知页面，通知客户端一个CAS认证已经发生了。）
• 如果客户端没有CAS单点登录的session，并且也不可能通过非交互方式建立认证，CAS必须将客户端重定向到“service”参数指定的URL，并且不在URL后面附加“ticket”。
• 如果“service”参数未指定但设置了“gateway”参数，CAS将认为这种行为未定义。在这种情况下推荐：CAS应要求客户端凭据就好像两个参数都没有指定。
• 同样这个参数与“renew”参数不兼容。如果要设置“gateway”参数，推荐设置为“true”。
• 总结：“renew”参数的作用：在存在SSO session的情况下，当client请求访问资源，renew参数控制CAS认证服务器重新认证用户信息、还是不用认证放这个请求过去。
• 总结：“gateway”参数的作用：与“renew”参数相反，“gateway=true”时是指只要存在SSO session就不用重新认证了。
• 总结：Renew始终要求用户进行主认证，所谓主认证就是借助于/login进行的认证操作，此时IE用户必须手工提供自身的帐号信息。基于TGC、PT的登录都不属于主认证。
• 相比之下，gateway始终不会允许CAS服务器丢出/login登录页面给IE用户，从而不可能进行主认证。只要gateway=true则永远进不到/login登录页面，只有确认用户能从其他途径得到SSO session才可以设置true。

 

 

 

 

评论

1 楼 skying007 2015-07-13  

博主你好，我想用cas 实现，相同用户登录，后者把前者踢掉，这样的效果，有什么好的思路吗？还是可以配置就可以了。谢谢。