Open Stack

Typo fix, see below.

On 16/01/15 12:26, Adrian Turjak wrote:
> Hello David,
> 
> We are definitely assessing the option, although even switching Keystone
> to be backed by an LDAP service might also work, and not be a switch to
> a fully federated system. I believe Keystone has had LDAP support since
> Havana, and that was an option we had looked at. It also might be a
> terrible option, we don't know yet, and would still mean dealing with
> LDAP directly anyway for user management.
> 
> What seems weird though with a federated Keystone system though is that
> you still have to store role and group information in Keystone so that
> has to be propagate through somehow, or be automated in some way still
> via an external service.
> 
> We don't at present have any concrete plans, and until now a pressing
> need to do so hasn't come up, although there were always plans to.
> 
> As for the VO roles blueprint, how likely is that to be merged into
> master, and are there any implementations of it? I assume the VO
> entities mentioned in the proposal would be in Keystone, yes?
> 
> We need a solution in the next few months (ideally sooner), but while
> building a quick hack of a service along Keystone could likely be done
> quickly
, that wouldn't be a good long term solution.

> 
> Cheers,
> -Adrian
> 
> On 15/01/15 21:20, David Chadwick wrote:
>> 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
>>>
>>
>> __________________________________________________________________________
>> 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
>>
> 
> __________________________________________________________________________
> 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
>