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

[Alexander Bokovoy]

On ke, 01 maalis 2017, Jan Cholasta wrote:
>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".
I'm not arguing with "no value is set in configuration -> use built-in
default". I do argue on having empty but present attribute because it
does not add anything useful for SSSD to decide on. And as it is not
adding anything useful, why there should be such difference at all?

This is the only question open I see in this design.

-- 
/ Alexander Bokovoy