[Freeipa-devel] Community Portal Prototype

[Drew Erny]

On 06/18/2015 03:53 AM, Petr Spacek wrote:
> On 17.6.2015 21:21, Drew Erny wrote:
>> Hello, all,
>>
>> I've built a prototype of the community portal, and I'd like a quick sanity
>> check on it. If someone would look over the architecture of this code and make
>> sure that the design is sensible before I proceed any further, that would be
>> very helpful. The source code can be found here:
>> https://github.com/dperny/freeipa-communityportal
>>
>> This code should run on your machine, and you should be able to add users to
>> the staging tree. It might not, howver; the point is to have the code looked
>> at before I spend anymore time on it.
>>
>> The Community Portal prototype is a Python Flask web-application that acts as
>> a client to a FreeIPA server. It collects input from the unwashed masses (in
>> the form of a user sign-up page) and then sends it to the FreeIPA server. This
>> way, the Community Portal acts like a gateway between the FreeIPA server and
>> the anonymous community users, restricting the commands they can send to the
>> server.
>>
>> Right now, the server imports FreeIPA's Python ipalib module, which allows it
>> to act like a client. It uses api.Command.stageuser_add(...) to add new users
>> to the staging area of the FreeIPA database. It then sends an email to the
>> admin (or, rather, it logs an email to the console instead of sending one, in
>> the prototype) to alert them to the fact that a user has signed up.
>>
>> All feedback is welcome.
> It seems reasonable except for two things:
>
> a) Most importantly, obtaining credentials for authentication to the FreeIPA
> server is completely missing.
>
> You need to 'somehow' fill in Kerberos credential cache with a valid ticket (~
> equivalent of kinit <user>) and use this ticket for authentication to the
> FreeIPA server.
>
> Ugly and hacky way to do that can be seen in
> https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/dnssec/ipa-ods-exporter?id=4dfa23256dc2e35480843beef92e03b1bafd578b#n395
>
>
> Maybe you should use GSS-Proxy so your code does not have to deal with
> authentication at all and let GSS-Proxy to do that for you behind the scenes.
>
> https://fedoraproject.org/wiki/Features/gss-proxy
> https://fedorahosted.org/gss-proxy/
>
> Please ask Simo for further details.
This is definitely something I was keeping in mind, but I wasn't too 
worried about it in the short term, because I always assumed that the 
user would configure the Community Portal to run as a special user, and 
I know there is a way for machine users to get Kerberos tickets. I 
figured I'd work out the details of that once the design was approved, 
because the Community Portal will have a configuration script to deploy 
it, and setting up that authentication will be part of the configuration 
script.
>
>
> b) I understand that this is a first prototype but we should replace the
> e-mailing thingy before we release it. Direct generation of e-mails goes
> against the spirit of (envisioned) notification system and has it's inherent
> problems.
>
> - It is not going to scale if you have a lot of requests.
> - Does not allow additional logic (auto-approval/denial based on some criteria
> etc.) built on top of that.
>
> Also, e.g. public website using FreeIPA behind the scenes for user management
> might want to auto-approve accounts and put them to some pre-defined group
> with lowest possible privileges.
>
> D-Bus hooks makes this auto-approval possible and does not depend on a cron
> job, i.e. eliminates the delay. The hook can of course do anything, use your
> imagination :-)
>
>
> I hope this helps to clarify why I insist on proper hook.
>
With some tweaking emailing from the web application would scale fine if 
we use some sort of non-blocking call to send the emails. I think, 
because the Community Portal is an exterior fixture (it's a client to 
the FreeIPA server, not part of the server itself), it's outside of the 
purview of the planned message system. The Community Portal might live 
on a completely different server.

Furthermore, If we wanted to build additional logic on approve/deny a 
user, that would have to be done on the client side anyway, to enforce 
the separation of concerns I have here (where the FreeIPA main 
application doesn't even have to be aware that there is a self service 
portal). So, to auto-approve/deny, we would just add additional logic to 
the User.save() method. I do not know how this would be easily 
user-configurable, and I think it's probably a bit out of scope for now 
anyway.

So, basically, it's not clear to me why we need to be worrying about a 
proper D-Bus hook at this stage in the process.