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

[Martin Basti]

bump for review

On 09.12.2015 21:00, Simo Sorce wrote:
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20160309/ef213deb/attachment.htm>