[Freeipa-devel] Community Portal Milestone

[Drew Erny]

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. 
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?