An interesting alternative is to use certificates to sign (and optionally encrypt) messages. For example, service A sends a message via some number of queues to service B. Service A has a private certificate which it uses to sign the message. Service B receives the message, and uses the corresponding public certificate to validate the message signature, and since this would only work with Service A's public key, service B knows the message originated from service A, and can authorise the request accordingly. This would work equally well for synchronous calls.
Of course, this means a lot of certificates deployed to a lot of places, but certificates could be obtained from a central service, and access control applied.
So service identity is sorted, but would about user identity?
I suggest that users and core services need to be separated by a gateway layer (application or service), which would be responsible for establishing user identity via some means (basic auth, OAuth, Kerberos, or whatever), and then sending a signed user identity assertion (along with any roles it might have) along with requests and messages, much like is done in SAML. Downstream services would trust the gateway to appropriately establish this identity, and trust would be ensured by means of the above certificate mechanism.
If you're looking for an identity & access management system, then check out OpenAM. ForgeRock are doing an excellent job of supporting it, and the major releases are open sourced and free to use. We use it at IG for SAML, OAuth, Windows SSO (Kerberos), LDAP authentication amongst other things. It is very easy to configure, either manually or scripted (e.g. via Puppet), and provides us a resilient, scaleable, standard authentication capability. It does also provide policy based access management, but we've not ventured there yet.
And there it is.