You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Tony Blanchard <bl...@wanadoo.fr> on 2005/05/14 11:56:25 UTC
ACLs questions
Hello,
I have two questions for the futur of ACLs with apacheds.
1 - I have noticed there was not user read access on the
uid=self,ou=users,ou=system and I think it should be.
I have modified the "isSearchable" operation on AuthorizationService to
enable read operation on the "self" entry and not for the others.
What do you think about this and is it possible to add this code to the
class :
" private boolean isSearchable( LdapContext ctx, SearchResult result )
throws NamingException
{
Name dn;
synchronized ( dnParser )
{
dn = dnParser.parse( result.getName() );
}
Name principalDn = ( ( ServerContext ) ctx ).getPrincipal().getDn();
if ( !principalDn.equals( ADMIN_DN ) )
{
//New code
if (principalDn.equals(dn))
{
return true;
}
//End of new code
if ( dn.size() > 2 ) [...]"
2 - What about having an "openLDAP like" simplified ACL mechanism ?
Here are the properties which should be used to register the ACLs to the
server :
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.whoid=whodn //Maybe a regexp or
a whodn space separated list //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.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.
Maybe The Authentication service should load ACLs at runtime (be
carefull of regexps for "whodn") and attach them to the
principal wich is accessible from the AuthorizationService.
Then, the authorization service should look for them each time an call
is made...
What do you think about it ?
Please take a look at the openLDAP documentation to compare this to an
existing ACLs implementation :
- http://www.openldap.org/doc/admin22/slapdconfig.html#Access%20Control
-
http://www.openldap.org/software/man.cgi?query=slapd.access&apropos=0&sektion=5&manpath=OpenLDAP+2.2-Release&format=html
Thanks,
Tony Blanchard
Re: ACLs questions
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Super, Health is better than everything else !
For the tests problems, here are my settings :
- Win XP SP2 (+ about 1500 update downloads ;-) )
- Netbeans 4.0 with JDK 1.5 (I am interested in SSL)
- Mevenide 0.5.1 for Netbeans.
Stack of a test suite which failed on doDelete(s).
"Testsuite: org.apache.ldap.server.authn.SimpleAuthenticationTest
Tests run: 8, Failures: 0, Errors: 3, Time elapsed: 6,453 sec
Testcase:
test3UseAkarasulu(org.apache.ldap.server.authn.SimpleAuthenticationTest):
Caused an ERROR
Unable to delete file: target\apacheds\master.lg
java.io.IOException: Unable to delete file: target\apacheds\master.lg
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:659)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:540)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:509)
at
org.apache.ldap.server.AbstractCoreTest.doDelete(AbstractCoreTest.java:144)
at
org.apache.ldap.server.AbstractCoreTest.setUp(AbstractCoreTest.java:128)
at
org.apache.ldap.server.authn.SimpleAuthenticationTest.setUp(SimpleAuthenticationTest.java:90)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
Testcase:
test8PassPrincAuthTypeSimple(org.apache.ldap.server.authn.SimpleAuthenticationTest):
Caused an ERROR
Unable to delete file: target\apacheds\apacheUpdn.lg
java.io.IOException: Unable to delete file: target\apacheds\apacheUpdn.lg
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:659)
[...]
Testcase:
test10TestNonAdminUser(org.apache.ldap.server.authn.SimpleAuthenticationTest):
Caused an ERROR
Unable to delete file: target\apacheds\apacheUpdn.lg
java.io.IOException: Unable to delete file: target\apacheds\apacheUpdn.lg
[...]"
Thanks for help,
Tony Blanchard
Alex Karasulu a écrit :
> Tony Blanchard wrote:
>
>> Hello Alex,
>>
>> First, hope your health is better.
>
>
> Thanks I'm definately back online :).
>
>> I have written a new page in the Wiki as you asked me for.
>
>
> Great this is a start to sharing our ideas on ACLs. I think if we do
> this we need to think about how we can represent the ACL within
> partition subentries and then build out the Authz interceptor service
> to use these ACLs.
>
>> Please tell me your opinion about this as the other users of this
>> list are encouraged to do. (My english is not very good too so feel
>> free to tell me about grammar or expression mistakes.)
>
>
> You're English is just fine ;).
>
>> I would like to implement this test case but I have a real problem
>> with them. I am using maven for netbeans (mevenide) and some of the
>> tests fails and I have to skeep them to build. My question is how to
>> pass argument to run test. It seems that the problem resides in the
>> path to the backend database directory (operation "doDelete" fails
>> all the time)
>
>
> Hmmmm interesting might be some locking issues ... are you on
> Windows? Your ide may be holding locks to the folder or something.
> Can you get me the stack trace for the doDelete() failure? All this
> function does is it deletes the working directory of the last test
> case if it exists before running a new test case. This way there is
> no cross reactivity between test cases.
>
>
> Let's keep at this problem ... I really want you to get past it. If
> need be let me know what your setup (Arch, OS, JVM, and Netbeans
> version) is and I can try to replicate.
>
> Cheers,
> Alex
>
>
>
>
Re: ACLs questions
Posted by Alex Karasulu <ao...@bellsouth.net>.
Tony Blanchard wrote:
> Hello Alex,
>
> First, hope your health is better.
Thanks I'm definately back online :).
> I have written a new page in the Wiki as you asked me for.
Great this is a start to sharing our ideas on ACLs. I think if we do
this we need to think about how we can represent the ACL within
partition subentries and then build out the Authz interceptor service to
use these ACLs.
> Please tell me your opinion about this as the other users of this list
> are encouraged to do. (My english is not very good too so feel free to
> tell me about grammar or expression mistakes.)
You're English is just fine ;).
> I would like to implement this test case but I have a real problem
> with them. I am using maven for netbeans (mevenide) and some of the
> tests fails and I have to skeep them to build. My question is how to
> pass argument to run test. It seems that the problem resides in the
> path to the backend database directory (operation "doDelete" fails all
> the time)
Hmmmm interesting might be some locking issues ... are you on Windows?
Your ide may be holding locks to the folder or something. Can you get
me the stack trace for the doDelete() failure? All this function does
is it deletes the working directory of the last test case if it exists
before running a new test case. This way there is no cross reactivity
between test cases.
Let's keep at this problem ... I really want you to get past it. If
need be let me know what your setup (Arch, OS, JVM, and Netbeans
version) is and I can try to replicate.
Cheers,
Alex
Re: ACLs questions
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Hello Alex,
First, hope your health is better.
I have written a new page in the Wiki as you asked me for.
http://wiki.apache.org/directory/ACLsAuthorizations#preview
Please tell me your opinion about this as the other users of this list
are encouraged to do. (My english is not very good too so feel free to
tell me about grammar or expression mistakes.)
I would like to implement this test case but I have a real problem with
them. I am using maven for netbeans (mevenide) and some of the tests
fails and I have to skeep them to build. My question is how to pass
argument to run test. It seems that the problem resides in the path to
the backend database directory (operation "doDelete" fails all the time)
I will create a JIRA issue after being able to pass tests and having
implemented the test case...
Thanks for help,
Tony Blanchard
Alex Karasulu a écrit :
> Tony Blanchard wrote:
>
>> Hello,
>> I have two questions for the futur of ACLs with apacheds.
>
>
> I have some too :).
>
>> 1 - I have noticed there was not user read access on the
>> uid=self,ou=users,ou=system and I think it should be.
>> I have modified the "isSearchable" operation on AuthorizationService
>> to enable read operation on the "self" entry and not for the others.
>> What do you think about this and is it possible to add this code to
>> the class :
>
>
> I thought we had full read access on self entries. Could you show the
> lack of this with a test case addition patch, then post this code to a
> JIRA issue? This way we don't forget about it and can confirm the fix
> easily. Nice to isolate the problem with a test case as well.
>
> <snip/>
>
>>
>> 2 - What about having an "openLDAP like" simplified ACL mechanism ?
>>
> I don't know I have not put enough thought to this because there are
> so many things standing in my way right now like implementing
> subentires so we can store ACLs ;). However going with their scheme
> might be a good idea. Can you take the time to research the strengths
> and weaknesses with this approach?
>
> Are there other options? What are the performance implications?
>
>
> We could certainly build authz into the directory very rapidly. I
> would however like to research how different directories do authz first.
>
>
>> Here are the properties which should be used to register the ACLs to
>> the server :
>>
>> 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.whoid=whodn //Maybe a regexp
>> or a whodn space separated list //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.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.
>>
>> Maybe The Authentication service should load ACLs at runtime (be
>> carefull of regexps for "whodn") and attach them to the
>> principal wich is accessible from the AuthorizationService.
>> Then, the authorization service should look for them each time an
>> call is made...
>>
>> What do you think about it ?
>
>
> Nothing yet. I'll try to free up some time to give this more
> traction. These links below help. Please feel free to put them up on
> our Wiki, create your own Authz page and add these links and other
> research to them.
>
>> Please take a look at the openLDAP documentation to compare this to
>> an existing ACLs implementation :
>> - http://www.openldap.org/doc/admin22/slapdconfig.html#Access%20Control
>> -
>> http://www.openldap.org/software/man.cgi?query=slapd.access&apropos=0&sektion=5&manpath=OpenLDAP+2.2-Release&format=html
>>
>
>
> Thanks Tony,
>
> Alex
>
>
>
RE: ACLs questions
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex,
I am off-line as I write this, so I cannot look at the Wiki or code, but I
am wondering why we might not implement ACL schemes with interceptors of
some sort, and make that whole functional area programmatically
configurable. With declarative security, such as OpenLDAP, something has to
implement the ACL anyway, so why not make that capability pluggable, and
expose a programming model?
It also seems to me that the way the system is coded, if there were no
security on some aspect(s), there wouldn't be security interceptors on that
path, and thus no overhead. Overhead would occur only when the
functionality would be required.
--- Noel
Re: ACLs questions
Posted by Alex Karasulu <ao...@bellsouth.net>.
Tony Blanchard wrote:
> Hello,
> I have two questions for the futur of ACLs with apacheds.
I have some too :).
> 1 - I have noticed there was not user read access on the
> uid=self,ou=users,ou=system and I think it should be.
> I have modified the "isSearchable" operation on AuthorizationService
> to enable read operation on the "self" entry and not for the others.
> What do you think about this and is it possible to add this code to
> the class :
I thought we had full read access on self entries. Could you show the
lack of this with a test case addition patch, then post this code to a
JIRA issue? This way we don't forget about it and can confirm the fix
easily. Nice to isolate the problem with a test case as well.
<snip/>
>
> 2 - What about having an "openLDAP like" simplified ACL mechanism ?
>
I don't know I have not put enough thought to this because there are so
many things standing in my way right now like implementing subentires so
we can store ACLs ;). However going with their scheme might be a good
idea. Can you take the time to research the strengths and weaknesses
with this approach?
Are there other options? What are the performance implications?
We could certainly build authz into the directory very rapidly. I would
however like to research how different directories do authz first.
> Here are the properties which should be used to register the ACLs to
> the server :
>
> 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.whoid=whodn //Maybe a regexp
> or a whodn space separated list //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.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.
>
> Maybe The Authentication service should load ACLs at runtime (be
> carefull of regexps for "whodn") and attach them to the
> principal wich is accessible from the AuthorizationService.
> Then, the authorization service should look for them each time an call
> is made...
>
> What do you think about it ?
Nothing yet. I'll try to free up some time to give this more traction.
These links below help. Please feel free to put them up on our Wiki,
create your own Authz page and add these links and other research to them.
> Please take a look at the openLDAP documentation to compare this to an
> existing ACLs implementation :
> - http://www.openldap.org/doc/admin22/slapdconfig.html#Access%20Control
> -
> http://www.openldap.org/software/man.cgi?query=slapd.access&apropos=0&sektion=5&manpath=OpenLDAP+2.2-Release&format=html
>
Thanks Tony,
Alex