[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

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

> So failing them and forcing them to use kinit manually sounds like a
> bad
> user experience approach to me.

We could simply tell them to log off and log on again as an alternative,
or to lock the screen and unlock it, if telling the user to run "kinit"
is too difficult.

> Do browsers support this?

No, browsers are built to prevent websites from being able to interact
with users files, certainly you can't do a behind the scenes
manipulation of users files. At most you can send the user a ccache file
and tell him to store it in some place. For some reason I don't think
this is any better then telling the user to log off and log in again.

> I understand that we would need to pass the
> ticket back so that the browser can store it in the key store on the
> client for future use?
> If it is not possible I would suggest filing an RFE so that the
> browser
> can get the ticket from the application and store it on the user's
> machine.

I don't think you want to give website access to the credential cache,
really, no.

> With kerberos now supporting S4U this might be a very valuable feature
> to have.

No, S4U is useful exactly to *avoid* having the browser forward around
(and therefore expose) user's TGTs ...


Simo Sorce * Red Hat, Inc * New York

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]