Re: [Freeipa-devel] Community Portal Milestone
Hey, all, What fields, exactly, should a self-service user be able to enter? Thanks, Drew Erny -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
On 06/12/2015 03:34 PM, Drew Erny wrote: Hey, all, What fields, exactly, should a self-service user be able to enter? Thanks, Drew Erny Start with the minimum: First and Last name, email address. The userid is automatically assigned based on their name, and their is a high likelyhood of clash, but I don't know if we want to let them pick juyst anything...let's say yes to that for now, within acceptable values for the Schema. Not too many of the other values make much sense for all orgs. Since the account needs to be activated, I would expressly not have them enter in a password. Instead, it should be an uuid -r type random which they will get in an email link, and then enter in their own password. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
On 06/10/2015 02:52 AM, Martin Kosek wrote: 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. Well, I'm led to believe that LDAP modifications are a slow operation. My concern is that if a site got hit with a load of spam, it could slow down a lot. Enforcing a separation between verified users (who are in the LDAP database) and the unwashed masses (who sit isolated in a small relational database, good performance) might be a good thing in a public environment. We're not talking about much of a database, either; it should top out at a couple dozen entries on a massive site if the admins are diligent in clearing it out. If the possible performance hit isn't a concern (and LDAP databases are not as slow as I'd guessed) then I'll just the user staging area. Is performance a concern? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
On 06/10/2015 04:09 PM, Drew Erny wrote: On 06/10/2015 02:52 AM, Martin Kosek wrote: 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. Well, I'm led to believe that LDAP modifications are a slow operation. Yes. With LDAP, reads are quick, writes are slow. My concern is that if a site got hit with a load of spam, it could slow down a lot. Enforcing a separation between verified users (who are in the LDAP database) and the unwashed masses (who sit isolated in a small relational database, good performance) might be a good thing in a public environment. We're not talking about much of a database, either; it should top out at a couple dozen entries on a massive site if the admins are diligent in clearing it out. If the possible performance hit isn't a concern (and LDAP databases are not as slow as I'd guessed) then I'll just the user staging area. Is performance a concern? I do not see that the performance should be the main decision point for this work. Maybe we would get there later, right now this may be just premature optimization. LDAP database should not be *that* slow. My naive guess is that if the user registration portal contains some decent Captcha or other mechanism, the number of wrong new user entries should be low. AFAIK, this work would form some standalone page utilizing the FreeIPA Web UI framework we have already, to get the same look and feel. Using FreeIPA API to store/manipulate user entries should be thus much easier, then taking care of separate database. Also, if Stage user tree is used, the admins doing the validation of user entries may also have other responsibilities in FreeIPA, so they may welcome having these entries in Stage User in the FreeIPA Web UI without going to special application. Just my thoughts, I would welcome other feedback. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
On 06/10/2015 10:16 AM, Martin Kosek wrote: AFAIK, this work would form some standalone page utilizing the FreeIPA Web UI framework we have already, to get the same look and feel. Using FreeIPA API to store/manipulate user entries should be thus much easier, then taking care of separate database. Also, if Stage user tree is used, the admins doing the validation of user entries may also have other responsibilities in FreeIPA, so they may welcome having these entries in Stage User in the FreeIPA Web UI without going to special application. Just my thoughts, I would welcome other feedback. I'm worried if I try to fit this into the existing WebUI framework, I'm gonna end up wrangling with the fact that the WebUI expects to have an authenticated LDAP user, but we need anonymous access for both self-service registration and (eventually) for password reset. I'm not sure what kind of changes would be needed to make this work. I'll use the stageuser tree either way, though; your argument on that is definitely correct. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
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. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
On 06/10/2015 04:55 PM, Drew Erny wrote: On 06/10/2015 10:16 AM, Martin Kosek wrote: AFAIK, this work would form some standalone page utilizing the FreeIPA Web UI framework we have already, to get the same look and feel. Using FreeIPA API to store/manipulate user entries should be thus much easier, then taking care of separate database. Also, if Stage user tree is used, the admins doing the validation of user entries may also have other responsibilities in FreeIPA, so they may welcome having these entries in Stage User in the FreeIPA Web UI without going to special application. Just my thoughts, I would welcome other feedback. I'm worried if I try to fit this into the existing WebUI framework, I'm gonna end up wrangling with the fact that the WebUI expects to have an authenticated LDAP user, but we need anonymous access for both self-service registration and (eventually) for password reset. I'm not sure what kind of changes would be needed to make this work. I'll use the stageuser tree either way, though; your argument on that is definitely correct. https://ipa.demo1.freeipa.org/ipa/ui/sync_otp.html is an example of such standalone page. Web UI framework doesn't need authentication until it talks to IPA API. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
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? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
On 9.6.2015 12:30, Petr Spacek wrote: On 8.6.2015 21:37, Drew Erny wrote: Hi, all, I'm going to start working on the Community Portal milestone this week. The first thing I'm noticing is that for almost all of the community portal, there has to be some way for the IPA server to send email, which right now isn't possible. It has been brought to my attention, however, that there is an existing ticket (https://fedorahosted.org/freeipa/ticket/1593) that includes email under its purview. I don't want to write a bunch of code that'll get tossed when work starts on the notification system if I don't have to, but I will if I must. I need a little bit of guidance. Is working on code to let the IPA server send email to users a good place to start chipping at this? Hello! I would recommend you to base your implementation on the generic principle sketched in https://fedorahosted.org/freeipa/ticket/1593 . Let's take https://fedorahosted.org/freeipa/ticket/3613 as an example: [RFE] Provide a self service enrollment capability with admin approval and notification workflow 1. User fills-in a web form for account registration. 2. A new user object in staging area is created. 3. FreeIPA framework calls a D-Bus method com.redhat.ipa.hook_user_self_registration (or something like that) This method/service/how is it called can be then provided by arbitrary script which can be connected to D-Bus using Oddjob. http://people.redhat.com/nalin/oddjob/ This will lift the burden of e-mail processing from you and will allow users to do anything with the data passed to hooks. I hope this helps. Speaking about D-Bus, interns in Brno successfully used this tutorial a month ago: http://excid3.com/blog/an-actually-decent-python-dbus-tutorial/ I do not remember why but we slightly modified the code for consumer to use Interface() constructor instead of get_dbus_method(): infopipe_obj = bus.get_object(org.freedesktop.sssd.infopipe, /org/freedesktop/sssd/infopipe) ifp = dbus.Interface(infopipe_obj, dbus_interface='org.freedesktop.sssd.infopipe') # call the method remotely result = ifp.GetUserAttr(username, [ipaSshPubKey]) So, if you encounter a mysterious failure you might want to try this variant :-) FreeIPA framework should act as 'consumeservice.py' and oddjob will implement most of 'myservice.py' for you. Let us know if you have any questions! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
On Tue, 09 Jun 2015, 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. 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 place. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
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. See also https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ how to communicate to IPA with JSON directly, without any dependency to IPA client tools. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Community Portal Milestone
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
