On 06/10/2015 04:09 PM, Drew Erny wrote: > On 06/10/2015 02:52 AM, Martin Kosek wrote: >> On 06/10/2015 05:11 AM, Adam Young wrote: >>> On 06/09/2015 06:34 PM, Simo Sorce wrote: >>>> On Tue, 2015-06-09 at 16:15 -0400, Drew Erny wrote: >>>>> Hey, Freeipa, same thread new subtopic. >>>>> >>>>> So, I was bouncing some ideas around with another developer (ayoung) and >>>>> I think I have a pretty good idea for self-service user registration. >>>>> >>>>> The idea is that I put self-service user registration into its own >>>>> application that calls out to ipa user-add after getting admin approval. >>>>> >>>>> Workflow goes like this: >>>>> >>>>> 1.) User goes to registration page, inputs details into form. >>>>> Registration page and application are not part of FreeIPA. >>>>> 2.) User's registration goes into a non-FreeIPA database, something like >>>>> SQLite. >>>>> 3.) Admin gets a notification email with a link to approve/deny >>>>> registration. >>>>> A.) Admin clicks approval link, registration application (which has >>>>> limited privileges) makes call out to ipa user-add command, adding the >>>>> new user to FreeIPA. >>>>> B.) Admin click deny link, user is not added. >>>>> 4.) User's registration information, approved or denied, is deleted from >>>>> the external database. >>>>> >>>>> This has a couple of advantages. For starters, it provides a layer of >>>>> protection against the creation of spam accounts. Accounts do not add >>>>> directly to LDAP (inserting to LDAP is a slow operation), instead sit in >>>>> intermediate area waiting approval. Second, we don't have to write a big >>>>> extension to ipa user-add or staginguser-add that allows anonymous >>>>> access to that command. Third, it can be bundled into its own package >>>>> and given to the community separate from FreeIPA proper. Finally, it >>>>> would allow me to gracefully defer becoming buried up to my neck in >>>>> D-Bus notifications and whatever other fanciness we want to send email, >>>>> because FreeIPA won't be sending the email. >>>>> >>>>> Opinions? >>>> You could avoid using an external database by using the new USer >>>> Lifecycle management feature [1]. This will allow you to do a simple >>>> ldapadd, but the user will not be enabled until an admin logs into the >>>> FreeIPA interface to enable the user. >>>> This manes your app never needs to see the admin's credentials or use >>>> s4u2proxy and will pose a lower risk to the system. >>> The big issue was having an unauthentiucated user add o the datastore; I >>> don't >>> think you want to push new values directly into LDAP. A separate Databse >>> makes >>> a lot of sense, and using SQLite for a proof of concept allows us to >>> migrate up >>> to MySQL for a live deployment. >> The separate database does not make lot of sense to me, why not using the >> Stage >> User tree when it's there, ready for you? I would like to know what is the >> motivation and reasoning for using completely separate DB. Besides others, I >> think Stage Users area for example checks for login name or UID/GID >> collisions. >> >> The Selfservice just needs to operate under an identity that has a Stage User >> Administrator privilege or we can create more contained privilege that could >> just add the staged users and not modify/remove them. >> > Well, I'm led to believe that LDAP modifications are a slow operation.
Yes. With LDAP, reads are quick, writes are slow. > My > concern is that if a site got hit with a load of spam, it could slow down a > lot. Enforcing a separation between verified users (who are in the LDAP > database) and the unwashed masses (who sit isolated in a small relational > database, good performance) might be a good thing in a public environment. > We're not talking about much of a database, either; it should top out at a > couple dozen entries on a massive site if the admins are diligent in clearing > it out. If the possible performance hit isn't a concern (and LDAP databases > are > not as slow as I'd guessed) then I'll just the user staging area. Is > performance a concern? I do not see that the performance should be the main decision point for this work. Maybe we would get there later, right now this may be just premature optimization. LDAP database should not be *that* slow. My naive guess is that if the user registration portal contains some decent Captcha or other mechanism, the number of wrong new user entries should be low. AFAIK, this work would form some standalone page utilizing the FreeIPA Web UI framework we have already, to get the same look and feel. Using FreeIPA API to store/manipulate user entries should be thus much easier, then taking care of separate database. Also, if Stage user tree is used, the admins doing the validation of user entries may also have other responsibilities in FreeIPA, so they may welcome having these entries in Stage User in the FreeIPA Web UI without going to special application. Just my thoughts, I would welcome other feedback. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
