On Tue, 09 Jun 2015, Adam Young wrote:
On 06/09/2015 06:34 PM, Simo Sorce wrote:
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.
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
3.) Admin gets a notification email with a link to approve/deny
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.
You could avoid using an external database by using the new USer
Lifecycle management feature . 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.
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.
So now you have two apps instead of one. How would you do password
resets in this scheme? Password resets is what Drew is doing in first
/ Alexander Bokovoy
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code