V3 api authentication method chaining

Definitely weird and undesirable! This doesn't seem to be a viable attack vector, though; can this be fixed publicly?

Obviously the caller already have the credentials of the two users so we are not compromising anything. Keystone basically pick and choose the user based on the order in this case. Keystone's auth protocol was designed to handle multi-factor and multi-roundtrip authentications and there was no expectation that all auth methods will yield a user_id. It is up to the plugins themselves to agree on a user_id.

i can think of an attack scenario in which an organisation decided that all authentication must go through a chain e.g., external auth (say one time code) and user/passwd. This provides two factor authentication . Now, with the current setup, any attacker with the possession of one factor can assume the role of the victim user. For example, an attacker gets the possession of one time code of the target victim by some means, can create an own account with username/password and combine the both to assume the role of the victim user. This effectively reduce the authentication strength to one factor i.e., knowing the one time code.

 The attack, most commonly, can be performed by one tenant user against another tenant user.

I think the attack scenario is a bit far-stretched. Chaining tokens was never documented as a way to securely perform 2-factor auth (and IMHO should never be used for it, this bug being fixed or not). This should definitely be fixed but I don't think we should consider it an exploitable vulnerability.

Unless someone complains we shall open this bug and fix it quickly in public.

Neither password or token auth plugins are considered 2-factor. There are a number of ways to implement multi-factor authentication and the V3 auth methods does not dictate one way or the other. For example, you can implement 2-factor auth in a single auth method payload where the password is the combination of one time passcode and a static pin. It is up to the plug-in implementations to reconcile the attributes of an identity (or user_context). The identity attributes are conveyed in the user_context, which is shared among the plugins.

Having said that, I agree we need to fix the password and token auth plugins to agree on the user_id. But I don't think they pose a security problem right now.

patch attached

OK, time is up. Making this public so we can issue a quick fix.

Guang: can you propose your patch against master via gerrit now?

Fix proposed to branch: master
Review: https://review.openstack.org/84945

Is there any possibility to leverage this to offset accountability for certain actions etc?

I don't fully understand the impact because I've never looked at chaining before.

Related fix proposed to branch: master
Review: https://review.openstack.org/97852

@Robert Clark, not sure if I understand your question. Comment #3 suggested if one does not properly setup their authorization policy, this could be problematic. For example,

"some_api": "auth_method: token and auth_method: password and user_id:%(user_id)s",

where token and password methods are obtained using the combined credentials. But this is not something we support in OpenStack right now. We don't populate the auth method in auth_context which used for policy check.

Reviewed: https://review.openstack.org/84945
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=33fd4cf8b308fd078e632eed9f398b91ed77b35b
Submitter: Jenkins
Branch: master

commit 33fd4cf8b308fd078e632eed9f398b91ed77b35b
Author: guang-yee <email address hidden>
Date: Wed Apr 2 21:41:11 2014 -0700

    Make sure all the auth plugins agree on the shared identity attributes.

    Note: this patch also corrected some of the external auth tests where an
    auth request consists of two methods with two different identities.

    Closes-Bug: #1299012

    Change-Id: I5d7dd42d373879322823b16b215f11a015b734f8

Reviewed: https://review.openstack.org/97852
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=7f5e120ab8e73fc77360a4adb2f73f2516bae8a0
Submitter: Jenkins
Branch: master

commit 7f5e120ab8e73fc77360a4adb2f73f2516bae8a0
Author: Morgan Fainberg <email address hidden>
Date: Wed Jun 4 09:37:12 2014 -0700

    Use translation hints

    Use the _LI() function instead of _() for new LOG.info messages.

    Change-Id: I6af25a33018e76b321488cacea65885fa597abbf
    Related-Bug: #1299012