[Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute

[Ludwig Krispenz]

On 09/18/2014 08:27 PM, Simo Sorce wrote:
> On Thu, 18 Sep 2014 14:22:07 -0400
> Nathaniel McCallum <npmccallum at redhat.com> wrote:
>
>> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote:
>>> On Thu, 18 Sep 2014 13:56:44 -0400
>>> Nathaniel McCallum <npmccallum at redhat.com> wrote:
>>>
>>>> -objectClasses:  (2.16.840.1.113730.3.8.16.2.2  NAME
>>>> 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type'
>>>> MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $
>>>> ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) MAY
>>>> (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') +objectClasses:
>>>> (2.16.840.1.113730.3.8.16.2.2  NAME 'ipatokenTOTP' SUP ipaToken
>>>> STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $
>>>> ipatokenOTPalgorithm $ ipatokenOTPdigits $
>>>> ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep $
>>>> ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP')
>>> NACK, you cannot move from MAY to MUST.
>> This is precisely what we have been discussing on IRC today. The
>> consensus was that this was acceptable because of the update plugin
>> and the rarity of the state in which a token would not have
>> ipatokenTOTPwatermark set (the token has to be created an never used).
> Sorry I was not around, but it is never acceptable, as it may cause
> replication failures.
I agree that this shouldn't be done, although  replication should not 
be  a problem, the consumer relies on the schema checking of the server 
where the operation was originally applied.
But problems may show up for existing entries, if you have an an entry 
without attr A, which now becomes MUST and then do any modification on 
this entry, after the mod the entry will be schema checked, the missing 
attribute detected and the mod rejected
>
> This has been a long (albeit perhaps unspoken) rule in changing schema
> in FreeIPA.
if you want to define the rules for schema change somewhere, you should 
add this as well: never make a multivalued attribute singlevalued
>
> Existing objectlasses can *never* gain new MUST attributes. This rule
> is rigid and is non-negotiable.

If you want to ensure that every entry has a specific attribute, but 
connot enforce this by the schema, an option would be to define a CoS 
rule for this attr which defines a default and gives the real attr 
precedence
>
> Sorry.
> Simo.
>