Open Stack

Hi Adrian

Morgan is right in saying that an external IdP would solve many of your
user management problems, but then of course, you will be using
federated keystone  which you seem reluctant to do :-) However, if you
have an IdP under your full control then you can allow users to self
register and reset their passwords.

The next problem you will then face, is user authorisation - as opposed
to user authentication. The VO roles blueprint that we have worked on
addresses the authorisation problem. So when you are ready for this, let
me know

regards

David

On 15/01/2015 00:42, Morgan Fainberg wrote:
>>
>> On Jan 13, 2015, at 9:06 PM, Adrian Turjak <adriant at catalyst.net.nz> wrote:
>>
>> Hello openstack-dev,
>>
>> I'm wondering if there is any interest or need for an open-source user
>> registration and management service for people using OpenStack.
>>
>> We're currently at a point where we need a way for users to sign up
>> themselves, choose their own password, and request new users to be added
>> to their project. There doesn't seem to be anything out there, and most
>> vendors seem to have built their own systems to handle this or even
>> their own dashboard systems that do.
>>
>> Horizon is built around the client tools, and your own personal token,
>> so it can't handle creating new users. Plus Keystone doesn't really have
>> any good way of handling temporary (unapproved) users and projects.
>>
>> The suggested approach seems to be to build a service to sit along
>> Keystone, have it's own admin creds so it can create new users, and also
>> store temp user data locally until the user is approved.
>>
>> Unless we can find a suitable solution for us quickly, we're likely to
>> be developing such a service. It would ideally have a pluggable approval
>> workflow, allowing new user requests, new project requests, creation of
>> clients in external client database/ERP systems. Plus it would have a
>> password reset-token system for having new users supply their password
>> once they are approved, which would also allow existing users to request
>> password resets.
>>
>> Part of our requirements are easy to integrate into Horizon, fitting
>> neatly into the OpenStack ecosystem along other services, and being easy
>> to update/alter once we have hierarchical multi-tenancy and if it makes
>> some things easier.
>>
>> I've written up a proposal to help us define our requirements, and a
>> copy of that is attached, and on etherpad:
>> https://etherpad.openstack.org/p/User_Management_Service
>>
>> Plus I've attached a couple of diagrams, which are sadly not UML, but
>> should give you some idea of two of the primary use cases.
>>
>> Is this useful to anyone? Is this entirely the wrong approach? If it is
>> a useful service is there any interest in collaboration?
>>
>> Thanks for any feedback.
>>
>> Cheers,
>> -Adrian Turjak
> 
> I have an alternative recommendation (rather than using Keystone’s API and user-management). Keystone’s user management is lacking a lot of features a full fledged IDP (identity provider) would have. “Password reset”, “password complexity”, “password reuse”, failed login locking, etc. I would recommend that you implement this service to write to a full featured IDP (LDAP, FreeIPA, Active Directory, etc) and have Keystone hook into that more-full featured IDP. You might even find that the IDP selected has a lot of these features built-in (and/or could be fronted in a horizon panel).
> 
> This recommendation comes from past experience implementing almost exactly this feature (and having it go through a number of incarnations). The benefits of using a full-fledged IDP outweigh the ease of using the Keystone API to manage users, especially since there is non-trivial engineering that will go into the project.
> 
> You could also utilize an IDP that can issue SAML assertions and go with a Federated Identity setup for Keystone. Again your tool could work with an IDP that has a better set of features that Keystone’s current build-in identity (user/group) store does.
> 
> Cheers,
> Morgan
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>