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
