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

[Alexander Bokovoy]

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?

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

-- 
/ Alexander Bokovoy