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
