<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>I am new to the community, but hope what we currently done can give you some ideas. We re-do the whole front end (called it UI later) instead of Horizon as it lack of some functions (well, we lack of Python programmers as well)</div><div><br></div><div>In our UI, we have a self registration component to handle the new user registration request. </div><div><br></div><div>As a cloud admin, they can:</div><div><ul class="MailOutline"><li>define the registration form (email, name, apartment, telephone, etc.)</li><li>view and approve the registration</li><li>allocate the resources to user (project)</li></ul><div><br></div></div><div>New user can fill up the registration form, the UI will store these data in the DB, admin can login to the UI and see all the registration request (data-table), once admin has approved the registration and allocate the resource (view —> allocate —> approve) , UI will sent new user data to keystone to complete the registration. Else, if the admin declined the registration, the user will receive am email or mobile txt about it.</div><div><br></div><div>@Dolph</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>In our case, admin need to assigned a project to user with resources allocation, the new user doesn’t need to care about domain, project, the admin need to handle it all</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>We don’t have billing/payment functions now</div><div><br></div><div>If keystone doesn’t provide the functions that Horizon needs? Why don’t we let the Horizon to handle some business logic rather to heavily rely on keystone? In my opinions, keystone should only take care of identity, token and policy, etc..</div><div><br></div><div>Garry </div><div><br></div><br><div><div>On Nov 11, 2013, at 11:07 PM, Walls, Jeffrey Joel (Cloud OS R&D) <<a href="mailto:jeff.walls@hp.com">jeff.walls@hp.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">David's questions are good ones. I do like the idea of self-registration, but the admin will almost certainly want some controls over their initial placement in the system (domain, project, roles, etc). I think part of this blueprint should include the specification / editing of these defaults in a new page on Horizon.<br><br>Jeff<br><br>-----Original Message-----<br>From: Lyle, David <br>Sent: Sunday, November 10, 2013 11:31 PM<br>To: OpenStack Development Mailing List (not for usage questions)<br>Subject: Re: [openstack-dev] [horizon] User registrations<br><br>I think there is certainly interest. I do think it will need to be highly configurable to be useful. The problem, as Dolph points out, is that each deployment has its own workflow. <br><br>Points of configuration:<br>-Does the local keystone deployment policy support self-registration? The default is no. So, at that point access to self-registration should be hidden.<br><br>-How many steps are required in the registration process?<br><br>-Is payment information required? Address? <br><br>-How is the registration confirmed, email, text, ?<br><br>-CAPTCHA? <br><br>I think the two main reasons such a facility is not present in Horizon are:<br>1. Until recently determining keystone's access policy was not possible.<br>2. The actual implementation is highly deployment dependent.<br><br>-David <br><br>From: Dolph Mathews [<a href="mailto:dolph.mathews@gmail.com">mailto:dolph.mathews@gmail.com</a>]<br>Sent: Monday, November 11, 2013 8:57 AM<br>To: OpenStack Development Mailing List (not for usage questions)<br>Subject: Re: [openstack-dev] [horizon] User registrations<br><br>So, there's a bunch of use case questions here where I suspect there are no correct answers (so preferences will vary per deployment). The first ones that come to mind-<br><br>Are the users accessing this web form trusted or untrusted?<br><br>Do they need to be verified, somehow? Are they going to be billed for their resource consumption?<br><br>After registration, should they own their own domain in keystone? Or be assigned their own project in an existing domain? Or simply be added to an existing group with limited authorization?<br><br>On Sun, Nov 10, 2013 at 6:26 PM, Paul Belanger <<a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a>> wrote:<br>Greeting,<br><br>In a previous thread I talked about building an application atop of horizon and keystone. So far things are working out pretty well. One thing I have been trying to figure out is how to move forward with user registration for the horizon application. A few moons ago, IIRC, horizon actually use django-registration however the move to Keystone removed that functionality.<br><br>For me, I'd like to expose some functionality within my web application allow users to register vs having an admin provisioning accounts.<br><br>So, I'm curious if there is anything interest in having such a module back in horizon but leveraging keystone this time around. I'm actually curious to hear how people see this working since this is the next thing I need to deal with.<br><br>--<br>Paul Belanger | PolyBeacon, Inc.<br>Jabber: <a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a> | IRC: pabelanger (Freenode)<br>Github: <a href="https://github.com/pabelanger">https://github.com/pabelanger</a> | Twitter: <a href="https://twitter.com/pabelanger">https://twitter.com/pabelanger</a><br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br><br><br>-- <br><br>-Dolph<br>_______________________________________________<br>OpenStack-dev mailing list<br>OpenStack-dev@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>_______________________________________________<br>OpenStack-dev mailing list<br>OpenStack-dev@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>