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
regards David 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 <adri...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev