Question

At work we are developing multiple systems that are highly modular and should not have hard dependencies on each other. Now we need these systems to share a common mechanism for authentication and security – or in other words – SSO (Single Sign-On). It is obvious that we will have to make another module that deals with managing authorization, authentication and security – a SSO module. The point is to have it properly integrated with our other systems.

The two approaches I can think of are:

1) Expose a RESTful service(s) from the SSO that allow the authentication and authorization operations to be performed by the the other two systems.

2) Expose a common API for authentication and authorization that will wrap our SSO functionality and have the two systems reference the API and use it directly.

At the moment we are not considering using any third-party solutions in this area, and we have already done some work on the would be SSO module, so we would prefer to stick to a simple solution that would best utilize the existing efforts.

Which approach should we choose and why? What are the significant benefits of each one over the other? Is there a better alternative?

Answer 1

“should I expose it to REST or have it wrapped in an API?”

Go for the best of both worlds.

1. Expose the authentication & authorization module as a RESTful service to allow the greatest interoperability regardless of the language, framework, or platform chosen for each of the modules. Anything that can communicate over HTTP could use it.
2. Then develop a library in your language(s) of choice that communicate with your RESTful service; this will make it easier for multiple modules to use a centralized auth mechanism. So you’ll have small clients written in ruby, java, etc. depending on the languages you use for your modules.

This sort of code reuse is one of the key tenants of a service-oriented architecture, and is the way to go in my opinion. A few colleagues and I described this in more depth in a recent presentation based on our experiences at BrightTag and other companies.

Many “enterprise” SSO systems like CAS use a very similar approach (though the CAS protocol isn’t RESTful). If you want more advanced features, I would definitely give CAS a look.