[Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page.

[Simo Sorce]

On Fri, 2009-10-30 at 15:43 -0400, Dmitri Pal wrote:
> Ok I buy this.
> Just have questions below...
> 
> Simo Sorce wrote:
> > Ok now on a more serious note ...
> >
> > On Fri, 2009-10-30 at 14:28 -0400, Dmitri Pal wrote:
> >   
> >> Why we can't call kinit (or equivalent) on their behalf as soon as we
> >> migrated them right away ourselves and then redirect then to the right
> >> place - self service page?
> >>     
> >
> > We could call kinit and store the credentials in the server cache for
> > the time the user is connected like we do with forwarded credentials,
> > but we want to go toward S4U to avoid forwarding TGTs in the first
> > place.
> >   
> So if we have the user TGT on server haw we can use it to improve user
> experience?

The user will be able to access the other UI pages w/o having to pass a
kerberos ticket for the duration of the session (will have to get a
ticket once it timeouts).

> >   
> >> Why make them fail? 
> >> I assume that things like cfengine or puppet can be used to already
> >> precofigure browsers to know about IPA.
> >>     
> >
> > In general the browser configuration is kept in the user home directory,
> > and is not something puppet or cfengine should touch (they may have no
> > access to the user home directory until the user is logged in anyway).
> >
> >   
> We already have the RFE to make FF to be able to configure kerberos more
> friendly.

I think we already had a page where all you need to do is press a few
buttons although that (correctly) shows some warnings and a request to
authorize the remote website to set the configuration.

> We can add specifics to it and make this configuration be stored outside
> of the user home directory
> so that it can be centrally configured.
> https://bugzilla.redhat.com/show_bug.cgi?id=526824
> 
> Upsteam
> https://bugzilla.mozilla.org/show_bug.cgi?id=520668
> 
> May be we should add it to the bug.

I don't see much care for that bug from upstream :-)

> But back to the point of user.
> What is that the browser carries that allows it to access the pages?

It depends, in freeipa v1 it would send krb credentials for each http
connection. In freeipa v2 we should be using a cookie (also sent for
each http request) generated after the first kerberos authentication
against a special auth page.

> Is it a cookie of some kind that is created as a result of the
> authentication using ticket or what?

yes.

> Can we create such cookie on behalf of the user.

yes, that's what I meant above.

> I understand that it will solve the problem of only this session and if
> user closes browser
> he will have to do kinit so may be it is not worth it.

It should be easy to do, although I wouldn't rate it as a priority, for
me it is fine to ask the user to logoff/login, it is a one-time thing
anyway.

> I guess asking user to log out and log in will only work if the system
> is configured to use same IPA with kerberos via SSSD or directly.
> Is this something that can be checked?

Not from the browser of course, but if the system is not set up for that
then the only way is to use kinit manually every time.

> If the user's machine is not configured for kerberos with the same
> domain asking user to log off and log on will not help.

Neither anything else :)
I guess the best thing is to allow each site to put up a customize
message with instructions on what to do next and by default set a
message valid for a fully kerberized machine.

Simo.

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