Password Rotation and Credential Lifecycle
Problem Statement
In the current Keystone implementation Users only have the ability of expressing one password. This eliminates the possibility of storing more than one password associated with the user as well as have a record of the last N passwords used. The rotation mechanism and history can simplify access without service interruption as well as make the system more secure preventing users to always use the same password which will never expire.
Supported Scenarios
1) Password Expiration
In this case, when a password is created, the system can specify the duration/validity of the password. For instance it could be valid for 1 day or 1 year.
2) Password rotation with no service interruption
A user can define at least two passwords allowing access to services using both the old and the new. Once all the services have migrated to use the new passwords the old one will be revoked and/or expired.
3) Prevent Usage of previous N passwords
The previous N passwords can be stored as indicated as "expired" or "disabled". When a user refreshes or create a new password it can be verified that it is not one of the N previously created and expired passwords.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Not
- Drafter:
- Fabio Giannetti
- Direction:
- Needs approval
- Assignee:
- David Stanek
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Good progress
- Milestone target:
- None
- Started by
- Dolph Mathews
- Completed by
- Morgan Fainberg
Related branches
Related bugs
Sprints
Whiteboard
Narrow the scope of this blueprint to just item #2. Use cases 1 and 3 can be solved in subsequent blueprints rather trivially. As discussed in #openstack-dev, none of this requires API modifications and can piggy back on dstanek's self-service change password call. With the above, I'd be happy to target this to m3 or sooner. -dolph
Solution
The solution is achieved changing the Users and Credential entities in this way:
1) The password field is removed from Users
2) A "password" type is defined for the Credentials entity
3) The password field content is placed in the blob field of the Credentials type="password"
4) A default_
5) The Credentials entity has a new status field with the following possible values: active, revoked, expired
6) The Credentials entity has a new expires_at field containing the timestamp (ISO 8601) when that credential will expire.
Credential Examples
Active Credential
{
"credential": {
"blob": "secrete",
"id": "80239a",
"links": {
"self": "http://
},
"status": "active"
"type": "password",
"user_id": "0ca8f6"
}
}
Expired Credential
{
"credential": {
"blob": "segreto",
"id": "80238a",
"links": {
"self": "http://
},
"status": "expired"
"type": "password",
"user_id": "0ca8f6"
}
}
User Examples
{
"user": {
"email": "<email address hidden>",
"enabled": true,
"id": "0ca8f6",
"links": {
"self": "http://
},
"name": "Joe"
}
}
Supported Authentication Variants
User ID and Password:
If the user passes the request just the user id and password:
{
"auth": {
"identity": {
],
}
}
}
}
}
Keystone will access the User using the user ID and the corresponding Credential using the default_
User Name, Domain ID and Password:
If the user passes in the request the user name, password and domain id:
{
"auth": {
"identity": {
],
}
}
}
}
}
Keystone will identify the Domain. Scan all the users until finds the user with the corresponding name and then use the default_
Credential ID and Password:
If the user passes the credential id and the password:
{
"auth": {
"identity": {
],
}
}
}
}
}
Keystone will immediately point to the Credential specified by the credential_id and to identify the corresponding password.
As discussed / designed at the keystone hackathon (dolphm, morganfainberg, dstanek, stevemar): https:/
Gerrit topic: https:/
Addressed by: https:/
Changing testcase name to match our terminology
Addressed by: https:/
Move identity logic from controller to manager
Addressed by: https:/
Adds table and model for storing rotated passwords
Addressed by: https:/
Adds model mixin for {to,from}_dict functionality
Addressed by: https:/
Identity authentication now uses rotated passwords
Addressed by: https:/
password rotation extension WIP
Addressed by: https:/
Moves test database setup/teardown into a fixture
There doesn't seem to be a push for this functionality. I'm marking this as 'Not' being implemented at this time and if there isn't any push back I'll mark it as closed next week.
