RE: subjects in LDAP ACMs

["Cutler, James R" <james.cutler@eds.com>]

Kurt,

Rather than "identified", it should be "authenticated", since this is, in
fact, what is indicated.  Authorization happens outside of the simpleSubject
definition.
-
James R. Cutler - EDS
800 Tower Drive, Troy, MI 48098
1 248 265 7514
james.cutler@eds.com
-----Original Message-----
From: robert byrne [mailto:robert.byrne@Sun.COM]
Sent: Monday, April 23, 2001 10:55 AM
To: Kurt D. Zeilenga
Cc: ietf-ldapext@netscape.com
Subject: Re: subjects in LDAP ACMs



Kurt,

Your list of proposed non-factor subjects seems fine to me and I take
your point that you may want to specify a factor or factors as well as
any one of these subjects.

If we jiggle the current BNF in 4.1.1 a bit in order to group the
factors together (authnLevel, ipaddress and dns) and add your
"authorized" and "anonymous" labels then I think it does give something
that's better structured:

subject =               [factor] simpleSubject       
            		
simpleSubject = 	( "authzID-" authzID ) /
                         ( "role:" dn ) /
                         ( "group:" dn ) /
                         ( "subtree:" dn ) /
                       "this:" /
			"public:" /
			"authorized:" / ; authenticated and authorized
			"anonymous:"	; unauthenticated
	
factor = [ "authnLevel:" authnLevel ":" ]
	[ "ipAddress:" ipAddress ]
        [ "dns:" [ "*." ] domainname ) ]

I think using "authorized" is confusing as it's often used to refer to
the end result of access control the user is authorized to do the
LDAP operation.  How about rather "identified" ?

As for making the factors extensible...that sounds fine but it might be
more pragmatic to focus on the factors we have already identified
(authnLevel, ipaddress/dns names) to try to get agreement on how to
handle those.

Rob.

"Kurt D. Zeilenga" wrote:
> 
> At 05:15 PM 4/12/01 +0200, robert byrne wrote:
> 
> >Kurt,
> >
> >Conceptually it's certainly helpful to seperate the authzid type
> >subjects from factors like authnLevel, ipaddress/dns name etc.  However,
> >in so far as a factor is typically an extra refinement on authzID's (eg.
> >grant the access if it's cn=rob,o=sun.com AND he's authenticated using
> >SASL-DIGEST-MD5) I think factors are still very "subjecty" things.  Is
> >the trend of your thought to move factors into a say "factor" keyword
> >and then require that the subject AND factor keywords are satisfied ?
> 
> No.  My thought is to come up with an extensible set of orthogonal
> factors which then are expressed in the syntax as such.  What
> authorization identity some user has independent of the mechanism
> used to authenticate the user.  What host that user appears to
> on is orthogonal to the mechanism used.
> 
> >What do you mean by "authorized" below ?
> 
> Meaning that the user was "authorized" to assume an identity.
> That is, the user has been authenticated and some authorization
> identity has been associated with the session (this might be
> an authorization identity derived from the user's authentication
> identity or another authorization identity which the user is
> allowed to assert).
> 
> >BTW, do you think it would be interesting to allow boolean combinations
> >of subjects in the same aci ?
> 
> Interesting, yes, but too complex.  I suggest that factors be
> AND'ed together and or's created by multiple values.  We use
> this logic in our ACM, it's simple and effective.
> 
> >Rob.
> >
> >"Kurt D. Zeilenga" wrote:
> >>
> >> I note that the LDAP ACI syntax only allows a single
> >> subject per value though it is likely quite desirable
> >> to treat certain kinds of subjects as orthogonal factors
> >> in the ACM.  For example, it might be useful to say
> >> "authzId X via Y method gets Z permission".
> >>
> >> However, adding additional, independent factors to
> >> the ACM adds to the complexity of specification so
> >> we must tread lightly.
> >>
> >> My first suggestion would be remove subjects based
> >> upon orthogonal factors from the ACM, then to discuss
> >> support for orthogonal factors such as authnLevel.
> >>
> >> I suggest Subjects be based solely upon presence, absence,
> >> or value of the authorization identity.  Hence, I suggest
> >> (provided in suggested precedence order):
> >>
> >>   subject = this          ; self
> >>   subject /= "authzID-" authzID)
> >>   subject /= ("role:" dn)
> >>   subject /= ("group:" dn)
> >>   subject /= ("subtree:" dn)
> >>   subject /= authorized   ; authenticated and authorized
> >>   subject /= anonymous    ; unauthenticated
> >>   subject /= public       ; any user
> >>
> >> Kurt