Centralized Authentication and Authorization for several Web Services

Question

There are several different web services -- various technologies used, such as Java, .NET, Python, Perl, and possibly more in the future -- belonging to different organizations, and the access to those web services has to be restricted.

The idea is to have a central authentication and authorization server, only responsible for granting access to each WS.

I'm looking for a Single Sign On system in which the user authenticates once with the auth server and is granted access to the web services for a limited timespan.

The security requirements are high, so a username/password set isn't enough.

In a quick search I found many different solutions and approaches to the problem, but I don't know the best one for this case -- a technology independent, secure and reliable solution.

Answer 1

Isn't this exactly what OpenID is for?

By all means correct me if I'm wrong.

Answer 2

We did a big research on the subject and couldn't find a suitable solution too. (One nearly good solution, but not so much for webservices is http://www.atlassian.com/software/crowd/)

So we developed a sso and central user management system too for our WS applications (also third party apps) but it's not for sale.

If you test solutions, you should check the performance of the systems, special under load. In the beginning our systems were 30 times slower. Normally you'll find the slow down in the xml parsing and the number of request you have to do (normally where you had one request in the future you'll have at least 4). (We use jmeter to test it.) And you should setup fail over systems, because you'll create a single point failure with sso.

Answer 3

This problem has been largely solved by WS-Trust, at least for SOAP-based web services anyway. WS-Trust is a well-defined protocol for validating and exchanging "authentication tokens", and can be used in cross-enterprise scenarios with protocols such as WS-Federation that are built on it.

One example scenario is to have the clients request a token from the WS-Trust server, then include that token in the SOAP header to the web service host. The flip side is to include something simple like <UsernameToken> in the request to the host, and have the server-side delegate authentication to the WS-Trust server.

There's pretty good client support for WS-Trust -- WCF has support out of the box, and various vendors have J2EE interceptors for JAX-RPC and JAX-WS web services.

While WS-Trust's focus is on authentication, you can do coarse-grained authorization by using logic about when to issue or validate a received token. Don't issue/validate the token, and access is effectively denied. Fine-grained authorization for web services will usually require some custom interceptors, which are vendor-specific.

I work for IBM Tivoli Security, and we have a few products in this space. The first is Tivoli Federated Identity Manager (TFIM). A colleague and myself wrote this article on integrating TFIM with WSE-based web services, and includes an overview of the WS-Trust protocol itself. The second product is Tivoli Security Policy Manager (TSPM), which implements fine-grained authorization for web services.

There are open source implementations of these same protocols, which is the upside of using a standards-based solution. I believe JBoss and WSO have implementations that might be useful.