directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Directory Wiki] Update of "ACLsAuthorizations" by TonyBlanchard
Date Mon, 16 May 2005 09:50:02 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification.

The following page has been changed by TonyBlanchard:
http://wiki.apache.org/directory/ACLsAuthorizations

The comment on the change is:
Please, feel free to make remarks on this page for aspect or for exposed ideas.

New page:
#format wiki
#language fr
== Tony Blanchard ==

Adresse électronique : [[MailTo(bltony AT PASDEPOURRIELS wanadoo DOT fr)]]


This page has been made to think about possible ways to enable ACLs on ApacheDS or what granularity
to obtain to work fine whith sufficient security settings.

This first step is not a implementation détail but can help to figure out what could be done
in ACLs world for ApacheDS.
In fact, I looked at the '''''OpenLDAP''''' documentation to see what was proposed on this
subject.

Please take a look at those documentation pieces: [[BR]]
[http://www.openldap.org/doc/admin22/slapdconfig.html#Access%20Control][[BR]]
[http://www.openldap.org/software/man.cgi?query=slapd.access&apropos=0&sektion=5&manpath=OpenLDAP+2.2-Release&format=html]

As I am a user of ApacheDS, I found some functionnalities which are of some interest to me
and I found a subset of '''''openLDAP''''' ACLs functionnalities which should be enought to
work with a sufficient security precision with LDAP.
Here are a summary of some points which seem to me to be relevant for access control on an
LDAP Tree: [[BR]]
 *What access with exact DN or regexp matching
 *What access filter with LDAPFilter
 *What access for attribute granularity
 *What access scope definition (exact|one|sub|children)
 *Who is granted access via DN list or regexp matching. DN could be a group DN.
 *Who is granted access regarding to its peername, sockname, domain or sockurl.
 *Who is granted access depending of the security strength factor via some strength factor
definition ssf=<level>, transport_ssf=<level>, tls_ssf=<level>, sasl_ssf=<level>
 *Level of access for matching ldap users (none|auth|read|write)
 *Special level of access for matching ldap users (self: allows  special  operations  like
having a certain
                                                      access level or privilege only in case
the operation
                                                      involves the  name of  the    user 
that's  requesting
                                                      the access.)

I took away some capabilities which look very heavy to implement and not very easyly or frequently
used:
 *Access regarding somme attribute value
 *Use of the ordered ACLs definitions and use of the '''stop''', '''continue''' and '''break'''
controls. Not easy and maybe dangerous when a modification in ACLs occurs.

To complete that reflexion on the subject, I began to think on a way to parametrize ACLs.
This work is based on what already exists for the partition properties definition.[[BR]]
ACLs properties could be : [[BR]]
 *server.db.partitions.{id}.access.{whatid}=whatdn //Mandatory: Maybe a regexp or an exact
dn
 *server.db.partitions.{id}.access.{whatid}.filter=An LDAPFilter  //Optional:
 *server.db.partitions.{id}.access.{whatid}.scope={exact|one|sub|children} //Mandatory:
 *server.db.partitions.{id}.access.{whatid}.attributes=attr space separated list //Optional:
not valid for some scope types...
 *server.db.partitions.{id}.access.{whatid}.who=whodn //Maybe a regexp or a whodn space separated
list //Mandatory:
 *server.db.partitions.{id}.access.{whatid}.who.accepted-connections=URL regexp list
 *server.db.partitions.{id}.access.{whatid}.level={none|auth|read|write} //Mandatory:
 *server.db.partitions.{id}.access.{whatid}.special_level=self //Optional: allows  special
 operations  like having a certain
                                                          access level or privilege only in
case the operation
                                                          involves the  name of  the    user
 that's  requesting
                                                          the access.

For me these properties should be loaded at start time and attached to LDAPPrincipal.
When the AuthorizationService catch an access to ldap backend, it should confront the LDAPPrincipal
to ACLs.

To be continued ...








----
CategoryHomepage

Mime
View raw message