Super !! Actually, was the problem was as you analysed it. So by forcing the Proxy to tunnel the sessionId when calling the Server, the excessive calls between the Proxy and CAS didn't happen anymore.
Thank you for the advice. Best regards. Alf. On Thu, Feb 28, 2013 at 6:56 PM, Ohsie, David <[email protected]> wrote: > Thank you for the answer.**** > > ** ** > > >>>>>** ** > > *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.***** > > <<<<<** ** > > ** ** > > 1/ In order to avoid having to get the PT for each call, should I have to > maintain the PGT or the PT ?**** > > ** ** > > Neither one for this purpose.**** > > ** ** > > To simplify this discussion, I'll assume that you are using the java cas > client in conjuction with a servlet container for your "proxy".**** > > ** ** > > The PGT is maintained automatically by the java cas client and is used > when you ask for a PT. But that is not what you need here.**** > > ** ** > > The PT is "one time use", so maintaining it is not useful.**** > > ** ** > > What you need to maintain is the cookie store that used by your http > client inside your proxy to talk to your service. When you make the first > call with the PT, the CAS client running in the "service" will issue some > kind of cookie (if java, probably a JSESSIONID) to form the session between > the proxy and the service. That needs to be maintained so that on the next > call into the proxy from the same browser, the same session will be used to > talk to the service from the proxy on behalf of the logged in user.**** > > ** ** > > 2/ If I maintain this ticket (PT or PGT) in a cookie store, then how the > CAS process will be informed that the required ticket is already maintained > in a store and it should use it ?**** > > Is it by storing the ticket in an implementation class > of ProxyGrantingTicketStorage ?**** > > ** ** > > No, your http client inside the proxy needs to reuse the cookie store that > was generated on the first call. The "CAS Client" inside your "service" > will recognized the cookie and know that it is the same user as last time, > so it will no require a new PT.**** > > ** ** > > Regards,**** > > Alf.**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > On Thu, Feb 28, 2013 at 2:58 PM, Ohsie, David <[email protected]> wrote: > **** > > 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**** > > ** ** > > -- > 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**** > > -- 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
