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

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.


Please ask Simo for further details.

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

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

Petr^2 Spacek

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to