headers
Jim Sermersheim | 4 Aug 2005 12:27
Picon
Favicon

Re: Splitting Password Policy

After talking this over, we've decided to try both. In other words, splitting the document into four different drafts like this:
 
1) LDAP authentication control for password policy
2) LDAP update control for password policy
3) LDAP password-based authentication policy
4) LDAP password update policy
 
#1 and #2 will essentially define the protocol elements and the various policy decisions to be made.
#3 and #4 will define the schema elements and how to use them to implement the policy decisions defined in #1 and #2.
 
We can probably find better names than the ones I've jotted down here.

>>> "Kurt D. Zeilenga" <Kurt <at> OpenLDAP.org> 10/26/04 6:21:25 PM >>>
Just a thought, but it might also be useful to split the
protocol elements from the schema elements. The protocol
controls could be genericized to support expiration of
other kinds of credentials.

At 09:00 AM 10/26/2004, Jim Sermersheim wrote:
>All,
>
>Speaking on behalf of some people on the CC list, it is seen as desirable to place password update policy in one specification, and place password use policy in another specification.
>
>This started as an act of associating password use policy (such as intruder detection policy) with login policy (such as allowable login times, addresses, etc).
>
>It then diverged from that and ended up being described as: Password policy is policy that applies only to simple bind passwords. Login policy involves policy that can be applied to *any* kind of credentials.
>
>My argument was that policy like password expiration (while enforced at authN time) is intimately tied to password updates. Thus, if we were to split this into two I-Ds, there would be some amount of cross referencing, and cross requirements (password expiration would require actions during password update).
>
>I know some people in the community have asked for more "login policy" type things to be added to the I-D, and we've pushed against adding those.
>
>What are other's feelings in this area? (Tammy, Duane, Hal, feel free to clarify these positions).
>
>Jim
>_______________________________________________
>Ldapext mailing list
> Ldapext <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
Permalink | Reply | 19 comments |
headers
Howard Chu | 27 Aug 2005 02:37
Favicon
Gravatar

Sorted attribute values

One of our customers requested an extension to sort the values in 
multi-valued attributes, which we have now implemented in OpenLDAP 2.3. 
Kurt suggested that we should also provide a (critical) control so that 
new clients can explicitly request this behavior (or disable it). I'm 
thinking we should publish the resulting work as an Informational or 
Experimental RFC.

The extension on the server can be configured to use one of 5 sort 
methods on a particular attributes in particular subtrees of the DIT. 
The first 4 methods are pretty straightforward - alpha ascending, alpha 
descending, and numeric ascending/descending. The 5th method is called 
"weighted" and while the previous 4 methods can be used without any 
special preparation, weighted sorting requires weights to be prefixed to 
the attribute values of interest. The weights are denoted by '{xx}' 
where 'xx' is an integer and are always sorted in ascending order. Also, 
the weights are not returned with the values in normal search results.

So, given an attribute
foo: {10}Animal
foo: {3}Vegetable
foo: {1}Mineral

a search response with weighted sorting would return
foo: Mineral
foo: Vegetable
foo: Animal

Currently the control is defined with a single boolean flag, which if 
set TRUE, disables sorting and causes attributes to be returned as-is.

If it weren't for this weighted sorting method, I would have preferred 
to have no server-side configuration, and just let the client choose its 
sorting parameters completely in the control. That strikes me as the 
most general solution. But this method was specified because they wanted 
  to get the sorting behavior without needing to update existing 
clients, and there's no way you could support weights without 
server-side state information. (And yes, even though there are no 
guarantees about the order of values returned in multi-valued 
attributes, they wrote their clients assuming there was a guaranteed 
order. sigh...)

--

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/
Permalink | Reply | 4 comments |
headers
Richard Megginson | 27 Aug 2005 03:05
Picon

Re: Sorted attribute values

Would it be possible to use attribute subtypes for the weights?  This 
could possibly solve a problem for many LDAP users - how to store a list 
of multiple values in order and have the server return them in the same 
order.

Howard Chu wrote:

> One of our customers requested an extension to sort the values in 
> multi-valued attributes, which we have now implemented in OpenLDAP 
> 2.3. Kurt suggested that we should also provide a (critical) control 
> so that new clients can explicitly request this behavior (or disable 
> it). I'm thinking we should publish the resulting work as an 
> Informational or Experimental RFC.
>
> The extension on the server can be configured to use one of 5 sort 
> methods on a particular attributes in particular subtrees of the DIT. 
> The first 4 methods are pretty straightforward - alpha ascending, 
> alpha descending, and numeric ascending/descending. The 5th method is 
> called "weighted" and while the previous 4 methods can be used without 
> any special preparation, weighted sorting requires weights to be 
> prefixed to the attribute values of interest. The weights are denoted 
> by '{xx}' where 'xx' is an integer and are always sorted in ascending 
> order. Also, the weights are not returned with the values in normal 
> search results.
>
> So, given an attribute
> foo: {10}Animal
> foo: {3}Vegetable
> foo: {1}Mineral
>
> a search response with weighted sorting would return
> foo: Mineral
> foo: Vegetable
> foo: Animal
>
> Currently the control is defined with a single boolean flag, which if 
> set TRUE, disables sorting and causes attributes to be returned as-is.
>
> If it weren't for this weighted sorting method, I would have preferred 
> to have no server-side configuration, and just let the client choose 
> its sorting parameters completely in the control. That strikes me as 
> the most general solution. But this method was specified because they 
> wanted  to get the sorting behavior without needing to update existing 
> clients, and there's no way you could support weights without 
> server-side state information. (And yes, even though there are no 
> guarantees about the order of values returned in multi-valued 
> attributes, they wrote their clients assuming there was a guaranteed 
> order. sigh...)
>
Permalink | Reply | 3 comments |
headers
Howard Chu | 27 Aug 2005 23:07
Favicon
Gravatar

Re: Sorted attribute values

Richard Megginson wrote:
> Would it be possible to use attribute subtypes for the weights?  This 
> could possibly solve a problem for many LDAP users - how to store a list 
> of multiple values in order and have the server return them in the same 
> order.

Hm, did you mean actual subtypes, or just attribute options? Something like

foo;x-weight-10: Animal
foo;x-weight-3: Vegetable
foo;x-weight-1: Mineral

That's an interesting idea, although it would still confuse older 
clients that only look for the attribute "foo" in the search responses.

Or did I misunderstand the suggestion?

>> So, given an attribute
>> foo: {10}Animal
>> foo: {3}Vegetable
>> foo: {1}Mineral
>>
>> a search response with weighted sorting would return
>> foo: Mineral
>> foo: Vegetable
>> foo: Animal

--

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/
Permalink | Reply | 1 comment |
headers
Hallvard B Furuseth | 27 Aug 2005 23:50
Picon
Picon
Favicon

Re: Sorted attribute values

Howard Chu writes:
>Richard Megginson wrote:
>> Would it be possible to use attribute subtypes for the weights?

Note that this has different semantics in the protocol: It will return
several attributes with one value each instead of one attribute with
several values.

> Hm, did you mean actual subtypes, or just attribute options? Something
> like
>
> foo;x-weight-10: Animal
> foo;x-weight-3: Vegetable
> foo;x-weight-1: Mineral
>
> That's an interesting idea, although it would still confuse older
> clients that only look for the attribute "foo" in the search responses.

Well, I the option could be defined with the semantics that it is not
returned in searches.  Maybe unless the user asks for it with a control
or in the attribute list.  Then the server would have to merge returned
attributes that otherwise have the same type, and update operations must
refuse to add values that match a value in another attribute which has
the same type when this option is ignored...

--

-- 
Hallvard
Permalink | Reply | 0 comments |
headers
Howard Chu | 28 Aug 2005 01:16
Favicon
Gravatar

Re: Sorted attribute values

Richard Megginson wrote:
> This 
> could possibly solve a problem for many LDAP users - how to store a list 
> of multiple values in order and have the server return them in the same 
> order.

This is a related but different problem, of course. In this case all you 
care about is that a static ordering is preserved. I.e., the client 
stores values in a fixed order and wants them returned in the same 
order. For the "sorted values" problem we're looking for a dynamic 
ordering - the client stores values in an arbitrary order and the server 
rearranges them into a desired order. Another aspect I forgot to mention 
is that for weighted sorting, it's possible for multiple values to have 
the same weight, and you can configure a secondary sort as well (where 
the secondary is one of the other 4 sort types) to handle this case.

Which reminds me, we already have a solution for the static ordering 
problem in OpenLDAP 2.3, adding an "X-ORDERED 'VALUES'" extension to the 
schema definition of the attributeTypes that need it. In this case, we 
also add a {xx} prefix to all of the values of the attribute, but this 
prefix is managed automatically by slapd, is always numbered 
consecutively starting from zero, and is always returned in search 
responses. Pretty sure I posted a full description to this list a few 
months back, but I may be misremembering. The other important aspect of 
this feature is that it allows equality matching of values by prefix. 
Matching by prefix is significant to us because it allows one to 
ldapmodify/Delete specific values by their ordinal position, instead of 
(or in addition to) their actual value. I mainly use this just to avoid 
having to specify long values for deletions, but this also means we can 
delete specific values of multivalued attributes even if they have no 
equality matching rule. Likewise we can provide prefixes on Add 
modifications to insert elements at the specified positions within an 
existing sequence of values. Another (mostly uninteresting) side effect 
of prefix matching is that one can search for e.g. "all attributes that 
have 5 values" by filtering on the prefix.

There is another possibility "X-ORDERED 'SIBLINGS'" that we use as well, 
to preserve the order of peer entries with the same naming attribute. 
This feature is not quite as well-defined; we only use it with 
single-valued RDNs and there are plenty of corner cases I haven't 
thought about.

--

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/
Permalink | Reply | 0 comments |

Gmane