Open Stack

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/user
>>> _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
>