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.chadw...@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.chadw...@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.chadw...@kent.ac.uk
>>>> <mailto:d.w.chadw...@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
>>>>     <adri...@catalyst.net.nz <mailto: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://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://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://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://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://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

__________________________________________________________________________
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

Reply via email to