Multiple Credentials (Claims)

Two approaches for implementing these across N authentication backends:

A) Backends register their supported 'types', and the keystone server matches the type to the appropriate backend. The potential complexity is that either two backends may collide for a single 'type', or the keystone server must pass the credientials to all backends with matching types... and you might as well implement a many-to-many relationship here, which is quite convoluted and increases the maintenance cost for both keystone and authentication extensions.

B) Keystone simply passes each set of credentials to each backend successively in a user-configured priority order until either the credentials are either validated or the list of configured backends is exhausted. This offers the flexibility of allowing the backend to both validate the credential's signature and authenticate the credentials, as well as leaving the authentication performance largely up to the service owner and/or backend implementations. The core keystone implementation would be nearly trivial in this case.

1, 2 and 4 lend themselves to implementation A, while 3 lends itself to implementation B.

Given that backends will be pluggable, I'm in favor of implementation B and credential proposal 3.

[ziad-sawalha] Valid analysis IF we were supporting multiple backends running simultaneously for a specific object in our model. This has not been proposed yet (the only support in place today is having a different backend per object - ex. storing Tokens in memcache but Users in SQLITE). What you are addressing is how to route authentication to different backends. I'm going to create a different blueprint for that and move this discussion to it: here https://blueprints.launchpad.net/keystone/+spec/routing-multiple-identity-backends

Addressed by: https://review.openstack.org/1221