Bug 1041941

Summary:	[RFE][keystone]: Password Rotation and Credential Lifecycle
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	openstack-keystone	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED NOTABUG	QA Contact:	yeylon <yeylon>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	ayoung, markmc, nbarcet, srevivo, yeylon
Target Milestone:	---	Keywords:	FutureFeature, Tracking, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/keystone/+spec/password-rotation
Whiteboard:	upstream_milestone_none upstream_status_good-progress upstream_definition_obsolete
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-09 03:27:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description RHOS Integration 2013-12-12 20:11:45 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/password-rotation.

Description:

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.

Specification URL (additional information):

None

Comment 3 Adam Young 2016-01-09 03:27:06 UTC

As discussed upstream, this is pushing Keystone toward being a full Identity provider, which it is ill suited to become.  Instead, we are working to integrate other methods for identifying users into the Federation approach that will then tie to external IdPs.  These IdPs should be full features ones that provide features like password rotation.