[Freeipa-devel] Community Portal Milestone

[Martin Kosek]

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.