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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://tp.its.yale.edu/mailman/listinfo/cas _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
