CAS authentication of a RESTful web service

user814425 picture user814425 · Nov 27, 2012 · Viewed 7.6k times · Source

My application needs to access a RESTful web service running on a different server. This web service uses CAS authentication, and when consuming it through the browser it will redirect to CAS login if the user isn't already authenticated. There is no method to actually login through CAS. My application also uses CAS so users will be authenticated

I'd like to access it through JQuery/Ajax, but the server doesn't seem to be configured for JSONP which I understand is essential because of the cross-domain issue.

Now, I could make the Ajax requests via my server instead, which leads to my question: with no CAS login method for my server to call, how can I 'tell' the web service that the user is authenticated?

So I suppose firstly I want to get clear on what's going on between the browser, CAS, and the RESTful service, and how authorisation is handled without any explict passing of credentials. Secondly, I want to see how/if I can replicate that when calling the service from my server- it wouldn't be the same session as a request from the browser so there'd be no CAS authorisation token, but I don't see how to get one or provide it.

Answer

6ton picture 6ton · Jul 16, 2013

For question 1 on how the authentication/single sign on works:
When you login the CAS server (say security.example.com) would set a cookie in your browser for the domain security.example.com. A typical flow when you access secured files through the browser on an application using standard CAS authentication and validation filters looks like:

  1. CAS Authentication filter configured for the application checks if user object is in session. If yes user is let through
  2. If not, CAS Authentication filter redirects browser to CAS login page. In a single sign on scenario, CAS server recognizes its own cookie, checks if the application is registered and participating in single sign on - if yes redirects browser back to the application with a service ticket.
  3. CAS validation filter configured on the application identifies the service ticket and contacts CAS Server for validating the ticket and creating assertion object

For this entire flow to work you need cookies and session handling to work.

For question 2 on how to handle authentication on the server side:
We had a similar problem in our application and use 2 different ways to get around it:

  1. Use an internal system user and do a server to server access passing the credentials of this user using basic authentication headers. Of course you need to have appropriate filters configured to handle a non-interactive login with basic authentication tokens. This is easy to implement however has obvious downsides like having this special system user, your application seeing the users password etc.
  2. Use proxy authentication. In this approach when your user is authenticated for application1, it also generates a proxy ticket to be used by application2 (server to server call). This proxy ticket can be passed in server to server communication so that application1 accesses application2 on behalf of the user