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
