Can you please describe the full workflow? What kind of use cases (applications/systems) you are trying to cover with this functionality?

Replying to [comment:1 dpal]:

Can you please describe the full workflow? What kind of use cases (applications/systems) you are trying to cover with this functionality?

Imagine you are a service provider. You want users to join your services. FreeIPA acts as the users DB.
Then, you need a place where a new user can ask for an account (see https://accounts.google.com/SignUp).
So FreeIPA can have a basic, common, public web interface to sign up. When the user fill a basic (again, see google's one) form, the account is created (with the FreeIPA admin supervision or not, configurable).

The account is created now. The user can now edit his own account. Currently FreeIPA allows this, no need to worry about this stage.

Later, the user wants his account to be deleted.

So, we have covered the complete lifecycle of an account:

• Request an account.
• Reset password, edit other personal data of own account.
• Delete own account.

The last two are almost possible or completely possible in the FreeIPA version we have, but the first request of an account.
By now, users have to contact us in order to create a new account and the admin have to create it by hand. Imagine how annoying this could be in environments with lot of new accounts per day.

Also, other good thing is the case when the user forgets the password and want it to be refreshed. AFAIK, FreeIPA doesn't cover this case either.

FreeIPA was build with the internal (company) users in mind. We expect you to use a pure DS (389 or OpenLDAP) in case described above. What is the value of FreeIPA in such environment? Users do not use kerberos, there is no systems management. While we are glad that you are using FreeIPA it seems that you are using it for the use cases it is not intended for.[[br]]
This is not the first time people ask about these workflows. They can be easily solved outside IPA in your web portal. User comes in to a page, fills a form and submits. Data goes into in interim part of the tree or just into a database, an email is sent to the user, user confirms his identity and DB or interim tree is updated. Now you need user data to be moved to the main tree. You can do it manually after admin's review or let your portal do it for you as a privileged user calling ipa API or shell command.[[BR]]
We are working on the provisioning so that there are convenient commands and consistent ways to create interim users http://www.freeipa.org/page/V3/User_Life-Cycle_Management but the whole registration and validation seems to be out of scope of FreeIPA and belongs to your portal. But I am open to your arguments.

I understand your arguments.

You already have a WebUI in FreeIPA, I don't see any drawback on having that public interface. Is just a basic form. I think it can be integrated quite well with the v3 provisioning approach: http://www.freeipa.org/page/V3/User_Life-Cycle_Management

Also, note that while FreeIPA incorporates Kerberos, the main component is the LDAP users DB.
BTW, we are using FreeIPA without kerberos right now, the to-kerberos migration is being done quite slowly.
I don't see the point of using a bare DS. For me, the value of FreeIPA in such environment is clear: avoid the complexity of maintaining two users DB.

In addition, FreeIPA will gain in flexibility. And flexibility is a real value here. If you have something that your competitors don't have, you get +10 points.
If others have asked for this before, other +10 points.

So:
- Let the v3 provisioning approach be a strong option.
- Let the public interface come to reality.

Please let me know your thoughts on this.

Making it critical because it is related to #3911

We now have a special milestone for having FreeIPA as a part of community infrastructure.