Registered by Joe Savak

BigCo has a big OpenStack private cloud. BigCo has an R&D division with resources in a separate tenant from other BigCo resources. To gain access to BigCo R&D resources, an employee needs to provide more than just one set of credentials.R&D employees that only supply 1 set of credentials can still access BigCo non-R&D resources. The additional sets of credentials needed to access R&D resources could involve a hardware token, push-notification approval, SMS texts with pins, or even voice approval.

As an enterprise using OpenStack, I would expect Keystone support the notion of a half-token - a token that isn't fully authenticated but could still allow access to some services/resources that only require the credentials I supplied.

As an enterprise using OpenStack, I would expect Keystone to support APIs that allow me to configure how many (and what form) of authentication is required to access specific tenants with the ability to exclude some users from the tenant configuration so that I can manage MFA at a granular level without breaking service-like users.

As an implementer of OpenStack, I would expect the MFA backend in Keystone to be configurable - allowing me to substitute and code against a MFA vendor my choosing.

As a tester of Keystone, I would expect the test scripts to test as much as they can without needed the implementation of a full fledged MFA vendor.

Blueprint information

Dolph Mathews
Guang Yee
Series goal:
Accepted for grizzly
Milestone target:
milestone icon 2013.1
Started by
Thierry Carrez
Completed by
Thierry Carrez

Related branches



[11:37am] ayoung: so one decision that I think people will find interesting is from multi factor
[11:38am] ayoung: we will start encoding what form of authN was used to generate the token
[11:38am] ayoung: so to do multi factor, submit for one token, then use that token to get another, and the authN set grows
[11:39am] ayoung: I think it is an elegant solution, and then it puts the onus on the policy writers to consume that
[11:39am] heckj: ayoung: resolved to leaving it to end services to validate multi-factor based on the authN annotations?
[11:39am] heckj: Or is there an expected auth_token middleware update to count for 2+ assertions, etc.
[11:39am] ayoung: heckj, possibly, but could even be on the authenticate method in Keystone
[11:40am] heckj: (or variation on that theme)
[11:40am] ayoung: heckj, I think first step is getting the mechanism in
[11:40am] ayoung: second is figureing out how people want it enforced.
[11:40am] heckj: mechanism = adding assertions onto token with AuthN usage
[11:40am] heckj: sounds good - I'm with that
[11:40am] ayoung: I could see an argument that you don't want to hand out tenant-scoped tokens until all the multi-factor rules are met
[11:41am] ayoung: mechanism is probably going to be a swappable function, with the default being "get starting token with user Id an password, and use that to get tenant/endpoint scoped tokens."

Gerrit topic:,topic:bp/pluggable-identity-authentication-handlers,n,z

Addressed by:
    blueprint pluggable-identity-authentication-handlers blueprint multi-factor-authn (just the plumbing) v3 authentication and token APIs

Gerrit topic:,topic:bug/1126048,n,z


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.