> I think you might be missing that a typical CAS client install will only
> redirect to CAS once at the point the user first requires authentication.
>
> The protocol and its various redirects and callbacks allow the CAS server
> to securely and authoritatively identify the user to the client
> application. Typically the client will store that identity in an
> HttpSession (or whatever local flavour of session management is available
> in the client) and won't bother the CAS server again.
>
> If you don't have a mechanism to maintain sessions between the browser and
> the CAS client application then you will have to redirect to CAS on every
> request - but those extra redirects are not CAS's fault.
Yes, it would appear this is very much the case. I was thinking
more along the lines of being tightly integrated to the server,
where it seems the design is more to simply use the CAS system as
a one time authentication, loosely coupled, which explains a great
deal.
In my system I also need pass access right info and maybe even
session data back and forth to a central location, which in a tightly
coupled system would be ideally handled along with SSO but which of
course it out of scope for CAS so would have to be a separate backend.
I hadn't really gotten that feel from the CAS documentation, but I
suppose it never really implied the other either. But seeing things like
the ability to add attributes and single log out were making me think in
the other direction.
--
www.suave.net - Anthony Ball - [email protected]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Conclusion: the place where you got tired of thinking.
--
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
