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 ?
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 ?
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
