Thanks Scott, After your suggestion about using WS-Security to CASifiy a web server I have set about creating a simple example. This should hopefully show how to use CAS proxy authentication, WS-Security with an XFire web service together. Currently it uses the CAS 2 client (as I a most familiar with that) but I expect it could be easily upgraded. I was thinking that other people might find some part of this useful.
<http://www.ja-sig.org/wiki/download/attachments/17223/XFireCASified.zip> Since it requires Maven 2 to build the actual distribution is only 11kb (the final war file is nearer 15Mb). Cheers, Mark On 10/18/07, Scott Battaglia <[EMAIL PROTECTED]> wrote: > Mark, > > In general when implementing web services, the authentication and > authorization concerns are separate from the API. > > In that scenario, a simple RESTful application might accept a CAS proxy > ticket over HTTP BASIC Auth while a SOAP web service might accept the proxy > ticket either via BASIC AUTH (if its SOAP over HTTP) or via WS-Security. > The stack used to implement the web service should have plug in points to > extract security information from the standard places. > > -Scott > > > On 10/18/07, Mark McLaren <[EMAIL PROTECTED]> wrote: > > I have been thinking about the best way to CASify a web service and I > > have come to some conclusions (I hope this is useful and not > > blindingly obvious). Let's say we have a web service that returns XYZ > > objects (implemented in XFire or whatever). We want to use CAS to > > restrict the usage of the web service to authenticated and authorized > > users. First we write the web service to work without any CAS > > authentication. So in the interface for the webservice we might have: > > > > XYZObject getXYZ(String xyzId); > > > > This method has a corresponding implementation class used on the > > webservice server. To add CAS authentication we need to slightly > > modify the non-CASified situation such that it now accepts proxy > > tickets. So our new CASified interface might be: > > > > XYZObject getXYZ(String xyzId, String proxyTicket) throws > > NotPermittedAccessException; > > > > In our new CASified implementation we can still make use of the > > previous non-CASified implementation so that it might look a bit like: > > > > XYZObject getXYZ(String xyzId, String proxyTicket){ > > if (isPermitted(proxyTicket)){ > > return oldImplementation.getXYZ(String xyzId); > > } else { > > throw new NotPermittedAccessException(); > > } > > > > } > > > > The CASification parts are essentially a wrapper around the existing > > web service functionality. Obtaining the userid happens by validating > > the proxyticket in the "isPermitted" method, this method would > > probably also contain any authorization checks. Adding CAS to a web > > service in this way means that the service is more flexible. We can > > still test the web service without the need for mocking up the CAS > > server functionality. Potentially we may want to reuse the original > > unCASified service in other situations. > > > > Hope this helps, > > > > Mark > > > > On 10/17/07, tedzo <[EMAIL PROTECTED]> wrote: > > > > > > Ok, that makes sense. Let me try that. > > > Thanks again for your time. > > > > > > > > > ----- Original Message ---- > > > From: Scott Battaglia <[EMAIL PROTECTED]> > > > To: Yale CAS mailing list < [email protected]> > > > Sent: Wednesday, October 17, 2007 6:35:43 AM > > > Subject: Re: Anyone have ideas?--Re: Authenticating web service calls > via > > > CAS.. > > > > > > You'll want to use CAS's proxying capabilities. It would allow > application > > > A to obtain a ticket on behalf of the logged in user. > > > > > > -Scott > > > > > > > > > On 10/17/07, tedzo < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > Scott, > > > > Thank you for taking the time to respond. > > > > > > > > I looked around and Acegi seemed to support what I am attempting > (atleast > > > the Acegi user guide suggested that its doable) and so I began > integrating > > > with Acegi. So, I am glad to see you mention it in your response. > Hopefully > > > I am on the right track. So, I now have CAS+Acegi+XFire :( > > > > > > > > Acegi with CAS is working fine for non-web service access (ie, via a > > > browser). > > > > > > > > Here is what has confused me- WHen the user tries to access the webapp > > > (say Webapp A), he is directed to CAS and he presents the password and > logs > > > in. Webapp A doesn't know what the password is (ofcourse). Now, all the > > > mthods in CentralAuthenticationService interface that allow for a ticket > to > > > be obtained ( getServiceTicket(), getTicketGrantingTicket() ), require > > > credentials to be presented (directly or indirectly). However, I don't > have > > > access to the credentials within Webapp A! (In my previous message, I > > > actually forgot that Webapp A doesn't have the credentials...). So, I > appear > > > to be stuck. What am I missing? > > > > > > > > FYI, if it is not clear, this is what I am trying- User logs into > WebappA > > > via CAS. He performs an action that requires a webservice in WebappB to > be > > > invoked. WebappB is also protected by CAS. I am looking to somehow > invoke > > > webservice in WebappB from WebappA without having to re-authenticate. At > > > present, WebappA is *not* protected by acegi (only CAS) while WebappB > has > > > Acegi with CAS behind it. I suspect I need to get WebappA also to be > > > protected by Acegi and thats fine. > > > > > > > > Your thoughts are much appreciated. > > > > > > > > Thanks. > > > > > > > > > > > > ----- Original Message ---- > > > > From: Scott Battaglia < [EMAIL PROTECTED]> > > > > To: Yale CAS mailing list < [email protected]> > > > > > > > > Sent: Monday, October 15, 2007 6:49:55 AM > > > > Subject: Re: Anyone have ideas?--Re: Authenticating web service calls > via > > > CAS.. > > > > > > > > Comments in-line. > > > > > > > > > > > > On 10/10/07, tedzo <[EMAIL PROTECTED] > wrote: > > > > > > > > > > > > > > > > > > > > I need to figure out a way to pass the session info to CAS when I > make a > > > remote method call using xFire. Someone has to have needed to do > > > this...Anyone? > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > From: tedzo < [EMAIL PROTECTED]> > > > > > To: Yale CAS mailing list <[email protected]> > > > > > Sent: Monday, October 8, 2007 3:03:52 PM > > > > > Subject: Re: Authenticating web service calls via CAS.. > > > > > > > > > > > > > > > > > > > > Ok, a bit of digging around- > > > > > I found the remoteCentralAuthenticationService and > > > xFireCentralAuthenticationService beans defined and > > > commented. The comment asked for the bean to be uncommented in order to > > > allow access as a web service (using xFire, which is good). Here is what > I > > > was thinking- > > > > > 1. From client stub (of my web service that is to be exposed), pass > > > credentials and query remoteCAS for a ticket. > > > > > 2. Pass the ticket to my web service. > > > > > 3. Validate the ticket from my web service (the actual > implementation of > > > the service to be exposed). If the ticket validates, then go ahead with > the > > > service. ELse fail. > > > > > > > > > > Does this seem to make sense? > > > > > > > > > > > > Yes, this makes sense. Though if your user has already authenticated > to > > > your application I recommend you just obtain a proxy ticket. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Questions- > > > > > 1. Once a ticket is used/validated, it is no longer recognized by > CAS. > > > So, this essentially means my web service stub needs to validate > everytime > > > the client accesses the web service. So, how do I obtain a ticket that > lasts > > > longer than 1 call? > > > > > > > > > > > > There are no service tickets that last longer than one call. You > either > > > need to get a new service ticket each time, or use a framework such as > Acegi > > > to secure the application. Acegi utilizes the existing ticket to > maintain a > > > session locally for a defined period of time. > > > > > > > > -Scott > > > > > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > > http://mail.yahoo.com > > > > _______________________________________________ > > > > Yale CAS mailing list > > > > [email protected] > > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > > > > > > > > > > > > > > -- > > > -Scott Battaglia > > > > > > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > http://mail.yahoo.com > > > _______________________________________________ > > > Yale CAS mailing list > > > [email protected] > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > > > > > > -- > > "Paradoxically, the more time saving abstractions you are using the > > more you actually have to know." - Simon Willison > > _______________________________________________ > > Yale CAS mailing list > > [email protected] > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > -- > -Scott Battaglia > > LinkedIn: http://www.linkedin.com/in/scottbattaglia > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > -- "Paradoxically, the more time saving abstractions you are using the more you actually have to know." - Simon Willison _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
