Programmatic CAS access

[Bill Bailey]

Ilya,

I'm not an expert, but this sounds a lot like a problem ACEGI security
already addresses. In ACEGI you can pass one of two usernames along with
service ticket, STATEFUL or STATELESS. If it is a stateless client,
ACEGI authenticates the ticket initially and then caches it so it can
remember on subsequent calls that the user has been authenticated
already. The client still passes the same service ticket on subsequent
calls, but ACEGI doesn't actually call CAS again. It authenticates
against its own cache.

In some ways, I suppose ACEGI implements a sort of pseudo-session with
the service ticket acting as a crude sort of JSESSIONID. I am planning
to use Spring Web Services which already integrates nicely with ACEGI
for this reason. You may not be able to do the same, but you might get
some good ideas by looking at how ACEGI (and Spring Web Services)
handled the same issue.

Others may have more to add, but I thought I'd offer my limited 2 cents
worth. :)

Bill Bailey
Senior Developer / DBA
Northland, A Church Distributed

-----Original Message-----
From: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu]
On Behalf Of Ilya Sterin
Sent: Monday, June 18, 2007 4:15 PM
To: Yale CAS mailing list
Subject: Programmatic CAS access

I'm trying to get more info on how I would use CAS SOAP APIs to
programmatically access authentication information...

What I'm trying to accomplish is a web service handler that will
programmatically check whether the current session is valid and if not
issue an exception SOAP or any other way that will notify the client
of the issue and allow them to handle the redirect to the CAS url.

The problem that I have is that though I can have the client store the
ticket on the client side and/or keep it within the stateful
serverside session, the ticket is only valid for one validation,
though what's a good pattern of handling such situations.

Should I issue a new ticket to the client on each response and though
each subsequent response would send it the ticket.  The problem with
this approach is the fact that service invocations can be done in a
clustered environment and also asynchronously and this drives the
complexity up.

I've read the lifecycle of validating sessions and have a good
understanding of how this would work, but can someone give me some
insight of accomplishing the task above.  How can each web service
request on the server side validate the client?  I'm having issues
finding programmatic implementation documentation on the site and
though some exists, it's not really detailed, as I'm sure most just
use cas with it's current servlet filter.

The basic idea is that I need to write my own plugin/filter
implementation and need some advice.

Thanks.

Ilya Sterin
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas