[Freeipa-devel] Community Portal Prototype

[Petr Spacek]

On 18.6.2015 16:09, Drew Erny wrote:
> On 06/18/2015 03:53 AM, Petr Spacek wrote:
>> On 17.6.2015 21:21, Drew Erny wrote:
>> 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.

Okay then.

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

Let me clarify this:
It will not scale on the receiving side. Free-form e-mail is meant for humans.

If you are going to send XMLs (or some other structured data) in e-mails and
parse them on the receiving side then you actually need a message bus and
reliable transport and not unreliable e-mail as used today.

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

FreeIPA consist of several almost-independent services so I do not see a
reason why this should be different in any way.

Moreover, the hook should not be in the self-service portal but inside
stageuser-add code in FreeIPA framework so the hook can be called universally,
even if the command is called manually or from different implementation of the
Community Portal.

> 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

D-Bus serves as the separation layer.

FreeIPA should know *nothing* about any hook. FreeIPA code should only calls
proper D-Bus method with correct parameters and let hook implementation to use
the parameters in whatever way they want (and ignore the call if the hook does
not exist, probably).

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

Exactly - ease of configuration is the goal. D-Bus will provide separation so
we do not need to worry about users tweaking the code we ship (with the intent
to modify the behavior).

Let me give you an example:
1) Community portal: Call IPA.stageuser_add(params)
2) IPA framework: call D-Bus method freeipa.hook.stageuser.add(params)
3) D-Bus: Invoke whatever implementation is registered for
freeipa.hook.stageuser.add
4) freeipa.hook.stageuser.add implementation: Auto-approve the user and/or
generate an e-mail to the admin.

Please note that step (4) can be arbitrarily changed by user just by modifying
service file for Systemd. User will simply bind own script as implementation
of freeipa.hook.stageuser.add interface and that is it. No change to FreeIPA
code is necessary.

Does it make sense?

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

Not now but 'before we release it' :-)

-- 
Petr^2 Spacek