Hi all, I'm working in a European project that uses OpenStack and I am using horizon and keystone for our users and organization management solution. We have some requirements similar to yours Adrian: we need to allow users to sign up themselves (with all the common functionality of email activation, forgot password) plus support authentication using OAuth2.0.
We are interested in having a standard open-source solution for these problems, therefore we are really interested in participating in this discussion to see other solutions for the problem, discuss them and collaborate in making such a service. I think this kind of requirements are common to anyone wanting to use OpenStack to build a public cloud system where there is no admin to create users. In the meantime, we have developed our open-source system for them using keystone extensions and django apps which satisfy our requirements. If there is interest in them I can share and explain in more detail our approach to both problems, and help build a well-integrated solution for everyone. Cheers, Enrique Garcia Navalon 2015-01-14 13:14 GMT+01:00 David Chadwick <[email protected]>: > Hi Adrian > > You might be glad to know that we have already produced a blueprint and > implementation for this, based on federated keystone and Horizon. You > can read the specs here > > https://blueprints.launchpad.net/keystone/+spec/vo-management > > and see a demo here > http://icehouse.sec.cs.kent.ac.uk/ > > (However you will not be able to perform federated login without a > Facebook or Google account, and you will also need the name of the VO > role that you are to join, plus a secret/PIN - Contact me if you want one) > > Briefly, the administrator (could be keystone or domain admin) sets up a > VO role, sends the details to the users who are to become members of it, > along with a secret, and the user then logs in via his IdP (you can use > Facebook or Google), quoting the secret and VO role. He is then enrolled > in Keystone, either automatically, or pending admin approval (as a > config option). The user can resign from the VO role anytime he wishes. > > I have updated your etherpad giving my comments > > regards > > David > > > > On 14/01/2015 05:06, 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: > > 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 > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
