[Freeipa-devel] session authentication URI issues

[Simo Sorce]

On Thu, 2011-12-22 at 10:29 -0500, Stephen Gallagher wrote:
> On Wed, 2011-12-21 at 14:07 -0500, John Dennis wrote:
> > For your holiday reading pleasure :-) Happy holidays to all.
> > 
> 
> Ok, I want to try to restate the problem so that I'm sure I understand
> it.
> 
> The way the session management is going to work is that the Apache
> server/FreeIPA application is going to kinit and get credentials on our
> behalf and store them in a session cache and provide us with a secure
> cookie.

No.
What you describe is the fallback mode used exclusively if you do not
already have credentials and are redirected to a form based
authentication page.
In the normal case we use s4u2proxy to get a ticket on your behalf to
the ldap server. We then store the whole credential cache in the
session.

>  As long as we have that cookie, we have an access-key to the
> credential cache and apache can then use that to perform RPC requests in
> our name.

Yes.

> When we connect via the CLI, we already have valid kerberos credentials,
> and we want to simply delegate those instead, so the Apache server
> doesn't need to maintain a session.

No.

We want to use the same methods in the long term with the trick of
storing the session cookie in the local cred cache so that CLI utils
know where to find them. (We can also use a .ipa-cli file or the kernel
keyring or something similar, we'll choose the most convenient
compromise between reliability or security).
However in the first implementation we can skip handling this for the
CLI.

> What if we were to mandate that the FreeIPA server always allows issuing
> a TGT with a renewal time of no less than the TGT time? Then it would be
> possible to initiate a session by presenting our existing TGT to perform
> a renewal request on the apache server, which could then be cached into
> the session. We could then just use the session interface from then on,
> even in the CLI/libcurl.

We do not want to give a TGT to the framwork.

> Is this doable?

Yes but undesirable, and also unnecessary.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York