directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Discussion on porting X.500 ACIItem to LDAP
Date Wed, 14 Sep 2005 20:09:15 GMT
Ersin Er wrote:

>Hi all,
>
>As you'll see we're doing some ACI stuff for ApacheDS and LDAP in general.
>ACIItem is the core component of ACI model of X.500 (x.501 in particular)
>and will be so for LDAP. However, we need to decide what features of
>ACIItem fit to LDAP model.
>
>You can find ASN.1 syntax for X.500 ACIItem here:
>http://docs.safehaus.org/display/APACHEDS/ASN.1+syntax+for+X.501+ACIItem
>Now I'll talk about some issues concerning it.
>
>* We need to determine what the ProtectedItems component can include
>concerning LDAP.
>
>As we talked with Alex, we can omit:
>  
>
Right you just corrected this as being the 'contexts' feild instead.

>* We need to decide if we can really have an optional UID part of an
>NameAndOptionalUID used in UserClasses component. I did not make the
>parser recognize this part and Trustin also did not include this field in
>the API. If we decide so that it can just be a name then I can change the
>spec and grammar to replace NameAndOptionalUID with a DistinguishedName.
>You can checn RFC 2252, section 6.21 for details.
>
>  
>
Hmm ok I need to look into the X.501 spec again and keep an eye on these 
details.

>* We need determine which fields of the AuthenticationLevel component is
>need for LDAP. Trustin has cut it so that it became only an enumeration of
>values none (0), simple (1) and strong (2). If you look at the ASN.1
>expression it has much more. If we'll change the spec for LDAP to only
>include this enumeration then I can update the spec like this:
>
>   AuthenticationLevel ::= ENUMERATED { none (0), simple (1), strong (2) }
>
>  
>
I think this is good since in LDAP land we have either none (anonymous), 
simple or sasl auth which basically translates to "almost" strong auth.

>I'm not sure about this ASN.1 syntax and correction is welcome.
>
>* We need to determine which bits in GrantsAndDenials fit to LDAP. Trustin
>and I currently include them all.
>  
>
Yah some can go.  Again let me nestle the X.501 spec tonight with a cup 
o' tea.

>* We need to determine the way we store a BIT STRING for GrantsAndDenials.
>I preferred to use bit-list syntax while it's really clear (but space
>consuming). You can check RFC 3641, section 3.5 for details.
>  
>
This is a string essentially of ascii 0's and 1's right?  If so this is 
ok for me too.  For the ACI representation remember this is just for the 
user to be able to tell the server what is toggled.  So this should be 
easy for the human to manipulate.  It *may* not be what is used for the 
runtime representation.  Meaning for the runtime representation we might 
prefer to use an int value with these bits at certain indices (perhaps 
the choices denoted by X.501).

>* Finally I'm not sure if we can surround NameAndOptionalUID,
>AttributeType, AttributeTypeAndValue, DistinguishedName and
>DirectoryString with double quotes. Adding them makes parsing easy and
>help readibility. RFCs do not all agree on this (or may be they just do
>not mention).
>
>  
>
Look there is not LDAP RFC defined for this.  Meaning no grammar in ABNF 
has yet been defined.  The guys writing the ietf draft would have to do 
what we are doing now.  They are going to try to use RFC 3641 to figure 
out an ABNF for the ACIItem in X.501. 

They are going to run into several problems because RFC 3641 and 3642 
are not perfect.  They are not designed to take parser technology 
intricacies into account so they often fall short.  In the end many 
protocol specifications wind up deviating from 3641/3642 
recommendations.  This is natural.

LDAP for example in 2251 deviates from BER encoding rules and states it 
does this for ease of implementation.  So its common for protocols to 
tweak but clarify why they tweak or deviate from recommendations like GSER.

So go ahead and add some delimiters that make life easier for 
implementing the parser.  Just make sure your delimiter choices do not 
prevent the correct parse of other grammar constructs.  For example do 
not use a comma to separate a list of DNs ;).

Also document what exceptions you have devised.  We really are going to 
need to have the ABNF grammar so users can add ACI Items to subentries.  
So they are going to need your grammar description.  Hopefully we can 
also show them some examples when we are done so users can see how to 
control access to entries in APacheDS.

Thanks Ersin,

Alex


Mime
View raw message