Re: subjects in LDAP ACMs

[robert byrne <robert.byrne@Sun.COM>]

Kurt,

I would say that those policy things that belong in the authentication
subsystem are those things which are likely to be required to be a
function of the authorization id only.  For example, policy like "three
consecutive failed binds by the same requestor then lock the account" or
"time of day restriction on class X of users".  Policy which is likely
to be required to be a function of dn, attribute and permissions
naturally belongs in the ACM.  I think the factors we have identified
are in this class.  For example, there may be particular sensitive
subtrees, entries and attributes the modification of which requires
strong authentication.

Anyone else care to cast a vote for or against factors in the ACM--to
recall they currently look something like this:

factor = [ "authnLevel:" authnLevel ":" ]
        [ "ipAddress:" ipAddress ]
        [ "dns:" [ "*." ] domainname ) ]

Finally what we are discussing here are "factors" not "subjects" and so
I don't think they are ruled out by U2.

Rob.

"Kurt D. Zeilenga" wrote:
> 
> It's my personal opinion that ACMs should be based upon
> authorization identities and that controls based upon
> other factors (authentication method (or level), IP
> address, DNS name, etc) should be left to other administrative
> mechanisms (such as those upon within the authentication
> subsystem and those external to LDAP (topology enforcement
> systems)).
> 
> The primary reason is simplicity.  While an extensible
> ACM which supports multiple orthogonal access control factors
> would be more flexible, it is also quite complex (to design,
> implement, and use).
> 
> Hence, I think we should do as RFC 2820 suggests [with clarification]:
>    U1.  When in doubt, simpler is better, both at the interface and in
>    the implementation.
> 
>    U2.  Subjects MUST be drawn from the "natural" LDAP namespace; they
>    should be DNs [or RFC2829 authzIds].
> 
> The suggested "non-factor subjects" are not drawn from the "natural"
> LDAP name space.  They add unnecessary complexity to the interface
> and its implementations.
> 
> Kurt