At work we're currently looking at related use cases, and access keys are useful without keystone actually managing passwords. The only issue with https://blueprints.launchpad.net/keystone/+spec/access-key-authentication is that it requires client side code changes, which is a non-starter in many cases. HP cloud has a similar API (http://docs.hpcloud.com/api/identity) in their public cloud - but it too requires client code changes.
Cheers Subbu On Jan 16, 2014, at 2:48 AM, Tristan Cacqueray <tristan.cacque...@enovance.com> wrote: > Hi, > > I'd like to check in on this authentication mechanism. > Keystone should have some kind of apiKey in order to prevent developer > from storing their credential (username/password) in clear text > configuration file. > > There are two blueprints that can tackle this feature, yet they > are both in needs of approval > > https://blueprints.launchpad.net/keystone/+spec/access-key-authentication > https://blueprints.launchpad.net/keystone/+spec/password-rotation > > > I believe the access-key-authentication have been superseded by the > password-rotation. Meaning: > * The user create a secondary password. > * He can use this new password to authenticate API request > with the credential_id + password. > * He won't be able to login to Horizon as it will try to authenticate > with the user_id + password (Keystone will match those against the > "default_credential_id".) > * API request like password change should be denied if the user didn't > used his "default_credential_id". > > Did I get this right ? > > > Best regards, > Tristan > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
