On 09/18/2014 08:27 PM, Simo Sorce wrote:
On Thu, 18 Sep 2014 14:22:07 -0400
Nathaniel McCallum <[email protected]> wrote:
On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote:
On Thu, 18 Sep 2014 13:56:44 -0400
Nathaniel McCallum <[email protected]> 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.
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
