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 CKoppelt
Date Fri, 16 Feb 2007 00:16:43 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 CKoppelt:
http://wiki.apache.org/directory/ACLsAuthorizations

------------------------------------------------------------------------------
+ deleted
- #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}.security-level-required=(SSL|none|...)
-  *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