[Freeipa-devel] Community Portal Milestone

Adam Young ayoung at redhat.com
Wed Jun 10 03:11:05 UTC 2015


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.

I don't think S4U2Proxy is necessary.  A client app with permission to 
read from the registration app could use the users own credentials to 
push to the IPA server.   This could be done in a a web app with CORS 
support as well.



>
> Simo.
>
> [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management
>
>




More information about the Freeipa-devel mailing list