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.
--
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
