Centralized authentication and authorization for multiple web services

Question

There are several different web services: various technologies such as Java, .NET, Python, Perl, and possibly more in the future, belonging to different organizations, and access to these web services should be limited.

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

I am looking for a single sign-on system in which a user authenticates once with an auth server and accesses web services for a limited time.

Security requirements are high, so the username / password is not enough.

In a quick search, I found many different solutions and approaches to the problem, but I do not know the best in this case - technology-independent, safe and reliable solution.

Answer 1

We did a lot of research on this issue and could not find a suitable solution. (One of the best solutions, but not so much for web services, but http://www.atlassian.com/software/crowd/ )

So, we developed sso and a central user management system for our WS applications (also third-party applications), but not for sale.

If you are testing solutions, you should check the performance of systems under load. At first, our systems were 30 times slower. Usually you will find a slowdown in parsing xml and the number of requests you need to make (usually when you had one request, in the future you will have at least 4). (We use jmeter to test it.) And you must configure fault tolerant systems because you will create a single point failure using sso.

Answer 2

This issue has been largely resolved by WS-Trust, at least for SOAP-based web services. WS-Trust is a well-defined protocol for verifying and exchanging "authentication tokens" and can be used in scenarios between enterprises with protocols such as WS-Federation that are built on it.

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

Good WS-Trust client support - WCF has support out of the box, and different vendors have J2EE interceptors for the JAX-RPC and JAX-WS web services.

While WS-Trust focuses on authentication, you can do coarse-grained authentication using the logic about when to issue or confirm a received token. Do not give out / check the token, and access is actually denied. Fine-grained authorization for web services typically requires some user-specific interceptors, which are vendor-specific.

I work for IBM Tivoli Security and we have several products in this space. The first is Tivoli Federated Identity Manager (TFIM). One colleague and I wrote this article about integrating TFIM with WSE-based web services and include 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 versions of the same protocols, which is the advantage of using a standard solution. I believe that JBoss and WSO have options that may be useful.

Answer 3

Isn't that what OpenID is for?

Correct me by all means if I am wrong.