The VO code exists already, as does a public demo (see my original email
for details). I gave demos to the Keystone core in Paris last November.
How soon this gets incorporated into core depends upon public/user
demand. So far, it seems that few people have recognised the value of
this service, probably because they are not using federated Keystone
seriously. Once they do, I believe that the need for user self
registration to roles and privileges will become immediately apparent



On 15/01/2015 23:28, Adrian Turjak wrote:
> 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 <> 
>>>>> 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:
>>>>> 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 Development Mailing List (not for usage questions)
>>> Unsubscribe:
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

OpenStack Development Mailing List (not for usage questions)

Reply via email to