Generally speaking, once a "CAS Client" validates an ST, the CAS client is responsible for maintain the session state with both the principal (username) and the associated attributes. When you use the Java CAS Client, it will store those values in the HttpSession object and the session identifier comes back to the browser/client in the JSESSIONID cookie. mod_auth_cas creates its own file based store and cookie for this.
So the reason that your browser needs to get an ST only once for the proxy, while the proxy needs to get an ST every time it accesses the service, is because your browser is storing and replaying the cookies in order to reuse the session that has been established at the proxy, but the proxy is not storing the cookies that are needed to maintain a session with the service. If you want to avoid having to get an ST for each call from the proxy to the service, then the proxy will need to maintain a cookie store for each logged in client that it reuses every time it makes a call on behalf of the client. If you are in the java enterprise servlet world, you would keep this cookie store in the HttpSession as described in something like this page: http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/Servlet-Tutorial-Session-Tracking.html. David Ohsie ASD Arch. and Advanced Dev. 410-929-2092 From: W.Alphonse HAROUNY [mailto:[email protected]] Sent: Thursday, February 28, 2013 7:30 AM To: [email protected] Subject: [cas-user] Unexpected CAS-Proxy behavior Hello, I have an application composed of 2 web modules (war): A first module acting as a service provider, it contains all the business aspects A second module having the responsibility to display all kinds of data a graphics provided by the first one. It does not contain any business logic. I have to integrate CAS SSO into this application. So after a self educating period, it seemed to me that I have to implement the CAS Proxy mode: The first module as the “service”, the second module as a “proxy”. Finally I succeeded to let this configuration work correctly. After a while, I noticed the following: Even if the user was authentified by the Proxy, each application request going from the Proxy towards the Service is being redirect and inducing technical sso request among the Proxy, the CAS server and the Service in order to regenerate a PT and then validate it. 1/ Why regenerate and revalidate a PT for each Proxy Request ? Knowing that the Proxy had been authentified earlier. Is there a mean to avoid this ? and how ? 2/ Even worst: As I’m using CAS capabilities to retrieve attributes from datastores (LDAP, RDBMS) , this process happens just after authentication validation (which is great), But it is also happening also for each application request going from the Proxy towards the Service. Is there a mean to avoid this ? and how ? Thank you Alf. _____ View this message in context: Unexpected CAS-Proxy behavior <http://jasig.275507.n4.nabble.com/Unexpected-CAS-Proxy-behavior-tp4658352.html> Sent from the CAS Users mailing list archive <http://jasig.275507.n4.nabble.com/CAS-Users-f255676.html> at Nabble.com. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
smime.p7s
Description: S/MIME cryptographic signature
