The dangers of single sign-on

Monday, October 10. 2005

The dangers of single sign-on

Single sign-on systems (or identity management - IDM - as they now like to be called) are an important element of an SOA strategy. Some have even referred to them as the Holy Grail of SOA security.

While I agree that they serve an important role (especially from an end user perspective - avoiding multiple logins), it's very easy to take them too far and, as a result, end up with a horribly complex unmaintainable SOA.

An IDM can be used for two different purposes:

single sign-on (allowing users to login once and have access to every application)
credential delegation (the ability to pass a user's credentials through a service to a downstream service - chaining together multiple services).

The root of the problem is with the use of credential delegation. Delegating the credentials is actually good thing from an authentication perspective (it lets every service in the "chain" know who started the overall chain). Where you can run into trouble is if you try to use delegated credentials for authorization.

Using delegated credentials for authorization means that the user must be provisioned to have access to every link in the transaction chain. For example, let's say "enter order" involves a chain of 10 different connected services. This would mean that every user that is allowed to enter an order must be granted access to each of the 10 connected services. What began as a simple task to "provision user X to be able to enter orders" has ballooned into a task involving 10 independent configuration changes. Painful? Yes. But, this can be somewhat managed in a silo'd environment.

In contrast, in an SOA where every service may be owned by a different team, no one group has visibility into the entire set of services that might be involved in "enter order". If you don't even know what might happen when you enter and order, how can you properly provision access to each service? The answer is you can't. In a world of connected systems, provisioning access to every service fails.

Another "gotcha" with IDM is that a credential is tied to a session - that is, it has a finite lifetime, after which it is no longer valid. So, if your "enter order" business process is a long running process (taking hours, days, or weeks), the credential of the original user will not be valid by the time you get to the end of the process - long running processes are another reason you can't use delegated credentials for authorization.

So, if you can't use identity management for authorization in an SOA, what do you do instead? At the "edge", you can still use IDM for authorization. But, for calls among services you fall back to pair-wise trust relationships. Each service consumer needs a secure (trusted) relationship with each of its providers. When a service provider receives a call, it verifies the call is from a trusted consumer. If so, then it does what it was asked to do. The trusted consumer may also pass along the IDM credentials. This allows the service provider to audit the request and properly associate it with the originating user - but without the service provider having to be provisioned for each and every user.

Posted by Dan Foody at 14:30 | Comment (1) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

It would not do to have Dan Brown or any Holy Grail issues to complicate the already obfuscated question of SOA. Nor would it do to combine business and systems SOA services.

SOA services are, ad must be, divided into business services and systems services. Business SOA services are part of the application layer, and part of a ‘composite’ application. Systems services – security, messaging, transformation, business process choreography, etc., etc. – are the top layer of enterprise infrastructure. Collectively, some of these systems services might be known as ESB services.

SSO/IDM is a systems service which would be used by many business services. Users at the edge would access an initial business service which would authenticate them using the infrastructure provided SSO/IDM systems service. Other downstream SOA business services would, as required, authenticate on an individual pair-wise basis using infrastructure provided security services.

This approach makes SSO/IDM part of an infrastructure architecture and not part of a business SOA strategy. Seem from this standpoint, SSO/IDM is a user requirement for comprehensive infrastructure security strategy and architecture.

#1 JD Beckingham on 2005-10-31 16:43 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. E-Mail addresses will not be displayed and will only be used for E-Mail notifications To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry