Hi David
I have finished the implementation now according to
https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough
and it works all fine now, but I noticed that also proxy tickets can be
used by 'proxyValidate' only once,
whereas IIUC a proxy ticket is just another service ticket, e.g.
"ST-2-engWXn1eVnPY62s0ZBda-cas01.example.org"
I have learned that one can increase the parameters "numberOfUses" and
"timeToKillInSeconds" inside
webapps/cas-server-webapp-3.5.2/WEB-INF/spring-configuration/ticketExpirationPolicies.xml
as a workaround, but it seems to me that this is not intention of these
parameters.
The reason for my setup is that the proxied webapp I have to deal with
would like to handle the proxy ticket similar to basic authentication,
which means with every request the proxy ticket is sent along and the
proxied webapp would like to call for every request proxyValidate.
Unfortunately I am not the product owner of the proxied webapp and hence
cannot introduce a session based authorization for the proxied webapp.
Thanks
Michael
Am 09.07.13 04:18, schrieb Ohsie, David:
Subject: [cas-user] Why is proxying so complicated?
Why isn't it possible to forward the service ticket to another application
and
allow this other application to validate this service ticket a second (or
third or
...) time?
[DO] I can answer this part of it. If I allow that, then any service that
get itself an ST forwarded to it is now also trusted to act on behalf of the
user. There has to be a system for authenticating the service that is
going to access other services on behalf of the user. The CAS https
callback to the service to hand it the PGT is the method for identifying the
service, since the cert validation can be used to authenticate the service.
The chaining of proxy services used to get the Proxy Ticket is then
available any service that wants to decide which proxies to trust. The fact
that a callback is used to authenticate the proxy service is one of the most
complicate aspects of proxy ticketing.
There have been suggestions to allow the service present a client cert when
validating the ST and then getting the PGT back in the serviceValidate
payload. This would simplify acquisition of the PGT.
Also, ST's are bearer tokens. Whoever possesses the ST can use it. There
is no validation of who is holding the token. This is generally dangerous.
The only reason that ST's can be used in a secure way is that they have an
"audience restriction": they can only be used for access to a specific
service. They are also only usable once. If you can use them as many time
as you want by anyone , then they don't provide any real authentication.
David Ohsie
Software Architect
EMC Corporation
I assume that there must be some security reason, but what exactly is the
security reason?
Thanks for your help
Michael
--
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
