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.