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

[Simo Sorce]

On Fri, 19 Sep 2014 09:08:46 +0200
Ludwig Krispenz <lkrispen at redhat.com> wrote:

> 
> 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

Ok I added this new page: http://www.freeipa.org/page/Schema_Handling

I would like to add a link to it in
http://www.freeipa.org/page/Contribute/Code if I get a review and an
ack for the page.

> >
> > 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

Yeah this is a good idea, should we add a section in that page with
advice on how to handle situations where you'd like to change an
objectclass/attribute but are not allowed by our rules ?

Simo.



-- 
Simo Sorce * Red Hat, Inc * New York