Re: [cas-user] How does CAS manage ajax/flex requests?

[Joachim Fritschi]

Am 26.07.2010 18:48, schrieb Daniel Earwicker:

Another option is to aquire a Proxy Ticket for the service
you are trying to access and use the session you recieve for
further request.
You could use a new PT for every request but that would defeat
the lightweight ajax solution ;). The initial PT allows you to
to access a service without any previous connection to the
service.

Cheers,

Joachim

I considered that. As we need to make repeated requests on behalf of the user, 
a tempting thought is to consider the JS code as a kind of proxy service (or 
playing a similar role). It is sitting between the user and the ultimate 
backend service(s). So it needs to fire off many requests from a single login.

But I think there are problems with this (aside from the overhead of validating 
again on every call).

To get a fresh PT for each AJAX call, you need a PGT. CAS never likes to return 
a PGT in the response of an HTTP(S) transaction. Instead it insists on making 
its own GET call to push the PGT out when it is asked to, over HTTPS (logically 
that should be a POST call?)

So to become a proxy that can get a fresh PT whenever you need to, you have to 
be able to accept an incoming call on HTTPS. So that rules browsers out of 
literally being a proxy.

Now, in theory you could split these responsibilities. Receive the pushed PGT 
at the server side, store it (keyed by the PGTIOU?), and allow browsers to call 
in and ask for a PT whenever they want to - the browser keeps the PGTIOU merely 
as a key to use in such requests.

But wouldn't that just turn the PGTIOU into something of equivalent capability 
to the PGT? And hence not something that should have been returned in the 
response of an HTTP(S) transaction, just like how a PGT is not returned in that 
way? It would seem to defeat the effort made by CAS to protect access to PGTs.

As the end result is the same as using a session ID (certainly doesn't seem any 
more secure), and ordinary webapps just use their own session ID after an 
initial sign-in, I wonder what the advantage/purpose would be to diverge from 
this in AJAX.

Cheers,

Joachim

You are right i should have given it more thought. ;) I still see a possible PT usage for accessing "outside" resources with ajax for the first time (later sessionid). Like some embedded "frame" pointing to another service. I think UPortal is doing a lot of these proxy applications inside the portal but i'm not sure if they use ajax.

smime.p7s
Description: S/MIME Cryptographic Signature