[Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

[Simo Sorce]

Sent the wrong patch, attached the one that actually compiles.

----- Original Message -----
> From: "Simo Sorce" <simo at redhat.com>
> To: "Alexander Bokovoy" <abokovoy at redhat.com>
> Cc: "Simo Sorce" <simo at redhat.com>, "Jan Cholasta" <jcholast at redhat.com>, "freeipa-devel" <freeipa-devel at redhat.com>
> Sent: Wednesday, December 9, 2015 2:18:23 PM
> Subject: Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user
> 
> ----- Original Message -----
> > From: "Alexander Bokovoy" <abokovoy at redhat.com>
> > To: "Simo Sorce" <simo at redhat.com>
> > Cc: "Jan Cholasta" <jcholast at redhat.com>, "freeipa-devel"
> > <freeipa-devel at redhat.com>
> > Sent: Tuesday, December 1, 2015 3:07:32 AM
> > Subject: Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz
> > data type per user
> > 
> > On Wed, 25 Nov 2015, Simo Sorce wrote:
> > >On Wed, 2015-11-25 at 08:09 +0100, Jan Cholasta wrote:
> > >> On 25.11.2015 00:09, Simo Sorce wrote:
> > >> > This patch is untested and mostly an RFC.
> > >> >
> > >> > I think it is all we need to allow to specify authz data types per
> > >> > user
> > >> > and by setting the attribute to NONE preventing a user from getting
> > >> > MS-PAC data in their ticket.
> > >> >
> > >> > Alexander you changed quite a bit the code around here so I'd like to
> > >> > know if you think the change I made in the KDC will cause any issue
> > >> > with
> > >> > the special PACs we generate for master's principals. As far as I can
> > >> > tell it shouldn't.
> > >> >
> > >> > Any opinion is welcome.
> > >>
> > >> Before your change, the server entry was checked for AS requests, now
> > >> only the client entry is checked for AS requests. I'm not very familiar
> > >> with ipa-kdb, but shouldn't the server entry still be checked as a
> > >> fallback when there is no authorization data in the client entry?
> > >
> > >This is partly why I CCed Alexander, the way the get function works is
> > >that it will get policy on the entry itself and if nothing is there it
> > >will try with the global policy, so in both cases the global policy is
> > >sourced as fallback.
> > >
> > >For AS requests though you are generally asking for a TGT so the
> > >"server" is the krbtgt entry that has no policy. It is through though
> > >that a client *can* ask for a ticket directly via an AS request, that is
> > >uncommon and it is unclear to me what we should do in that case if
> > >client and server have incompatible options.
> > >
> > >Well this is why it is a RFC after all :)
> > Can we source global policy for the direct AS request as well?
> 
> I think I would do this in a separate patch.
> 
> > >> The attribute is exposed in the service plugin, shouldn't it be exposed
> > >> in the user plugin as well?
> > >
> > >I didn't do it on purpose yet but eventually we may want to expose it,
> > >indeed. The reason I didn't is that we may want to use something like
> > >CoS to populate the attribute based on group membership and I am not
> > >sure we want to expose it per user, up top debate.
> > I don't want to expose it in the config too.
> 
> Agreed.
> 
> attached find an updated patch as I found a crash bug with the older one in
> some situations.
> 
> Simo.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-simo-560-3-Allow-to-specify-Kerberos-authz-data-type-per-user.patch
Type: text/x-patch
Size: 4485 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20151209/8eed998b/attachment.bin>