[Freeipa-devel] Community Portal Milestone

[Alexander Bokovoy]

On Wed, 10 Jun 2015, Adam Young wrote:
>On 06/09/2015 04:44 PM, Alexander Bokovoy wrote:
>>On Tue, 09 Jun 2015, 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?
>>Sounds good. For external application like your portal to be able to
>>call IPA CLI (or JSON) with Kerberos on behalf of an admin, you need to
>>support S4U2Proxy configuration. See
>>https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/
>>for details how to make it working. This would allow you to have an
>>application running on a separate IPA client and still be able to re-use
>>admin Kerberos credentials to perform the work after admin granted the
>>permission to create a user or to reset a password.
>I don't think so;  S4U2Proxy would only make sense if the user does 
>not have direct access.  I think that, with proper CORS support,  we 
>could have the admin users authenticate the new users directly. Should 
>be a simpler set up.
??? You would need admin to login into the community portal to approve
users. And you would then want to use admin credentials to connect to
IPA to actually create users/set passwords/etc. This is what S4U2Proxy
is for, not for the users themselves.

The users would not have direct access as the idea of the community
portal is to allow reset passwords and create additional users.

If you want to make it all accessible under a different account, you'd
need to add a number of permissions and it would quickly become
unmanageable. I see very little use in that.
-- 
/ Alexander Bokovoy