[openstack-dev] [Keystone][Horizon] User self registration and management
Brad Pokorny
Brad_Pokorny at symantec.com
Wed Jan 21 20:19:09 UTC 2015
Thanks for the info, David.
Yes, it sounds like the VO roles code would be useful for us to authorize
the user to a project, which would simplify things for us to not have to
make an explicit call from a script to add the role for the user.
On 1/20/15, 10:54 AM, "David Chadwick" <d.w.chadwick at kent.ac.uk> wrote:
>Hi Brad
>
>in your scenario the users are already registered - in your corporate
>LDAP. So this is not too dissimilar to the federation case, where the
>users are already registered in a remote IDP.
>
>You get the user to present his LDAP credentials, which are validated by
>LDAP.
>Federation gets the user to enter his IDP credentials, which are
>validated by the IDP.
>
>Once either of these are done, you now have a valid authenticated user
>who you can give a keystone token to.
>
>So the next thing you need to decide, is what is this user authorised to
>do, which is what our VO roles code does. I therefore see that our VO
>roles code can work perfectly well with your LDAP authn code.
>
>regards
>
>David
>
>On 20/01/2015 17:43, Brad Pokorny wrote:
>> At Symantec, we provide a simple signup button on the Horizon login page
>> for self registration. Our goal is to not only make it easy for the
>>user
>> to register but to also set up some basic things to make it easy for
>>them
>> to start using OpenStack services. We don't use federated Keystone, so
>> users have to go through the registration to access OpenStack services,
>> but they can then manage their user accounts via existing corporate
>> management tools. Having the signup button on the Horizon login page
>> unifies the experience of working with OpenStack - to sign up, they go
>>to
>> Horizon, and then they log in to Horizon after signup.
>>
>> In our case the users are already in the corporate LDAP, so the user
>> clicks the signup button and is redirected to a page to enter their LDAP
>> credentials. A script behind the page validates the LDAP username and
>> password and sets up the user with their own project and a network for
>>the
>> project (with quota restrictions on the project).
>>
>> So we enable self registration and also set a few extra things up to
>>make
>> it easy for users to start doing real work.
>>
>> Regards,
>> Brad
>>
>>
>> On 1/19/15, 10:03 AM, "David Chadwick" <d.w.chadwick at kent.ac.uk> wrote:
>>
>>> Hi Enrique
>>>
>>> You are right in that we have been addressing different problems. There
>>> are three aspects to managing users: registration, assigning
>>> authentication credentials, and assigning authorisation credentials.
>>>You
>>> appear to be primarily concerned with the first two. I have only
>>> concentrated on the latter, assuming that the users have already been
>>> registered somewhere (with an identity provider) and already have their
>>> authn tokens. In a federated infrastructure the authn and authz are
>>> split between the IdP and SP, so I have only concentrated on the authz
>>> aspects, assuming the authn is already sorted out.
>>>
>>> If you are interested in a centralised Keystone system, there is no
>>>need
>>> to split the functionality up, as Keystone can register users, assigns
>>> their passwords and their roles. The only place our work would overlap
>>> with yours, is in the assignment of roles to users. Our solution,
>>>though
>>> designed for a federated keystone, can equally well be used with a
>>> centralised keystone, since once the user is authenticated, he can then
>>> request to join a VO role regardless of who authenticated him (and we
>>> have demonstrated that local login works just as well as federated
>>>login
>>> in our prototype). So you may wish to use our work, once you have
>>>sorted
>>> out user registration and the assignment of authn credentials
>>>
>>> regards
>>>
>>> David
>>>
>>>
>>> On 19/01/2015 15:15, Enrique Garcia wrote:
>>>> Hi everyone,
>>>>
>>>> Enrique, if you have a github repo or some project pages you can
>>>> point
>>>> me to that would be wonderful. I'm currently in the very early
>>>> stages of
>>>> our proof of concept/prototype, so it would be great to see some
>>>> work
>>>> others have done to solve similar issues. If I can find something
>>>> that
>>>> works for a few of our use cases it might be a better starting
>>>> point or
>>>> good to see what an approach others might find useful is.
>>>> I'd much rather not duplicate work, nor build something only
>>>>useful
>>>> for
>>>> our use cases, so collaboration towards a community variant would
>>>>be
>>>> ideal.
>>>>
>>>>
>>>> Adrian, first of all we are currently working in this functionality
>>>>so
>>>> we don't have a final version yet, that's why we are also interested
>>>>in
>>>> joining efforts and collaborate in a community variant. Anyway,
>>>> our first prototype was to do it all in Horizon, implementing a django
>>>> app similar to what you can find in django registration
>>>> <https://django-registration.readthedocs.org/en/latest/>. Currently
>>>> I am
>>>> working in moving all the backend logic to a keystone extension and
>>>> keeping the views and form handling in a django app to make something
>>>> similar to the current authentication system <
>>>> https://github.com/openstack/django_openstack_auth>
>>>> .
>>>>
>>>> You can check here
>>>>
>>>>
>>>><https://github.com/ging/keystone/tree/registration/keystone/contrib/us
>>>>er
>>>> _registration> our
>>>> current keystone extension if that helps you.
>>>>
>>>> Getting into the details, we went for a slightly different approach to
>>>> the one you propose. Our idea is to have a service in keystone that
>>>> exposes and API to register and activate users, as well as other
>>>>common
>>>> functionality like password reset, etc. This API is admin only, so
>>>> Horizon(or whoever wants to register users) needs to have its own
>>>>admin
>>>> credentials to use it. If I understand correctly, what you suggest is
>>>> that is the service the one that would have the credentials, so we
>>>> differ here. I see some benefits and disadvantages in both approaches,
>>>> we can discuss them if you want.
>>>>
>>>> Secondly, the way we handle temporary user data is setting the enabled
>>>> attribute to False until they get activated using a key provided
>>>>during
>>>> registration. In other words, our extension is a 'delayed user-create
>>>> API for admins' with some extra functionality like password reset.
>>>>What
>>>> do you think about this approach? How do you plan to store this
>>>>temporal
>>>> data?
>>>>
>>>> It would be great if you can provide any feedback on all of this, like
>>>> how well do you think it integrates with the current ecosystem and how
>>>> would you do things differently.
>>>>
>>>> David, is this approach somewhat redundant with the federated Keystone
>>>> code you are working on? I feel like they address different use cases
>>>> but I might be looking at it the wrong way.
>>>>
>>>> regards,
>>>> Enrique Garcia Navalon
>>>>
>>>>
>>>>
>>>> On 16 January 2015 at 15:12, David Chadwick <d.w.chadwick at kent.ac.uk
>>>> <mailto:d.w.chadwick at kent.ac.uk>> wrote:
>>>>
>>>> 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
>>>> <adriant at catalyst.net.nz <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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
>>
>>
>>_________________________________________________________________________
>>_
>> 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
More information about the OpenStack-dev
mailing list