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.h
tml>
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
smime.p7s
Description: S/MIME cryptographic signature
