[Freeipa-devel] Please review: V4/AD user short names design draft

[Jan Cholasta]

On 1.3.2017 14:05, Alexander Bokovoy wrote:
> On ke, 01 maalis 2017, Jan Cholasta wrote:
>> On 1.3.2017 13:39, Martin Babinsky wrote:
>>> Alexander,
>>>
>>> thank you for your comments. Replies inline:
>>>
>>> On 02/28/2017 01:48 PM, Alexander Bokovoy wrote:
>>>> On ti, 28 helmi 2017, Martin Babinsky wrote:
>>>>> Hello list,
>>>>>
>>>>> I have put together a draft of design page describing server-side
>>>>> implementation of user short name -> fully-qualified name
>>>>> resolution.[1]
>>>>>
>>>>> In the end I have taken the liberty to change a few aspects of the
>>>>> design we have agreed on before and I will be grad if we can discuss
>>>>> them further.
>>>>>
>>>>> Me and Honza have discussed the object that should hold the domain
>>>>> resolution order and given the fact that IPA domain can also be a part
>>>>> of this list, we have decided that this information is no longer bound
>>>>> to trust configuration and should be a part of the global config
>>>>> instead.
>>>>>
>>>>> Also we have purposefully cut down the API only to a raw manipulation
>>>>> of the attribute using an option of `ipa config-mod`. The reasons for
>>>>> this are twofold:
>>>>>
>>>>> * the developer resources are quite scarce and it may be good to
>>>>> follow YAGNI[2] principle to implement the dumbest API now and not to
>>>>> invest into more high-level interface unless there is a demand for it
>>>>>
>>>>> * we can imagine that the manipulation of the domain resolution order
>>>>> is a rare operation (ideally only once all trusts are established), so
>>>>> I am not convinced that it is worth investing into designing
>>>>> higher-level API
>>>>>
>>>>> I propose we first develop the "dumber" parts first to unblock the
>>>>> SSSD part. If we have spare cycle afterwards then we can design and
>>>>> implement more bells-and-whistles afterwards.
>>>> Looks mostly OK, but there are few comments I have:
>>>>
>>>> - I do not see you mention how validation of the
>>>> ipaDomainResolutionOrder is done. This is important to avoid hard to
>>>> debug issues because SSSD will ignore domains it doesn't know about.
>>>>
>>>
>>> The validation is described in a Design section as follows:
>>>
>>> """
>>> Finally, any modification of the domain resolution order must ensure
>>> that each of the specified domain names corresponds either to that of
>>> FreeIPA domain or to one of the trusted AD domains stored in LDAP
>>> backend. In the case of trusted domains, the domain must not be marked
>>> as disabled.
>>> """
>>>
>>> Is this sufficient or is a more thorough validation required? Shall I
>>> split the whole section into sub-sections for easier navigation?
>>>
>>>> - Space separator initially caused me to look up DNS RFCs as strictly
>>>> speaking domain names can contain any 8-bit octet (while host names
>>>> should follow LDH rule). But then [1] does explicitly say space is not
>>>> allowed in AD domain names.
>>>>
>>>
>>> I have discussed this with Jan and consulted the same document that you
>>> cited, that's why I have arrived to the conclusion to use whitespace as
>>> separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain
>>> names or should we consider other options to avoid breakage with more
>>> exotic domain names?
>>
>> Actually I would prefer something else than whitespace as a separator.
>> A ':' maybe?
> or ',' or ';'. Any would work.
>
>>> I have considered a empty attribute value to be a distinct state from
>>> the missing attribute and assigned a different semantic meaning to it.
>>>
>>> The reasoning is as follows: if the attribute is not set, SSSD will not
>>> retrieve it and this signals that it should continue operate in usual
>>> way.
>>>
>>> If the attribute is present but is empty, the semantics change slightly
>>> as now we consider *no* domains during short name resolution (extension
>>> of the missing domain behavior to the case of all domains are missing
>>> from list).
>>
>> It doesn't have to be literally empty (LDAP character string syntaxes
>> don't allow it anyway IIRC), there can be a value which denotes an
>> empty list of domain (e.g. the separator alone).
> I don't see *why* there should be this distinction. The deciding party
> is SSSD. Whether this attirbute exists and empty or does not exist at
> all does not change anything. Changing how SSSD interprets own defaults
> depending on absense or emptiness of certain attribute in IPA config
> object is not user friendly at all.
>
> SSSD default behavior should stay the same whether it finds missing or
> empty attribute because the attribute will not be known to older SSSD
> anyway. Missing or empty attribute should, in my opinion, be equal to
> older SSSD behavior.
>

"No value is set in configuration => use built-in default / some value 
is set configuration => use the value" is perfectly user friendly and 
pretty much common virtually everywhere I believe, much more so than 
"empty value is set in configuration => ignore the value even if the 
user deliberately set it empty and use the default value instead".

-- 
Jan Cholasta