You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2005/05/18 04:41:24 UTC
[apacheds] ACL implementation options (was ACLs questions)
Hello,
I thought I'd start a new thread since some of these ideas transcend
what we were talking about. Also it helps to hit that reset button
sometimes :). Just to give you all some background I had a long
conversation with Noel about approaching ACLs in a fashion where any
approach could eventually be taken for representing and storing them.
By tossing around these ideas we came up with some implementation
possibilities. I'd like to summarize them here on this thread and open
our conclusions to some discussion.
First off, we both agreed that we need some optimized in memory data
structure to represent access control information. The ACL data
representation within this structure is the operational representation
for efficient AC evaluations. What this structure will be at the
present moment is irrelavent. We both agreed that something optimized
for evaluation is key for performance reasons. Now with this data
structure the implementation of the authorization subsystem is trivial.
An interceptor is used to reject, alter or allow various operations on
entries based on the evaluation of these access control instructions
within the optimized structure.
Noel stressed the point that an API should be exposed to add and remove
ACLs from this data structure. By exposing such an API ACLs can be
added to the structure at runtime or at initialization time using ACL
information stored anywhere in any format. Meaning the existance of
this API makes our authorization evaluation mechanism independent of the
way ACLs are stored or where and how they are represented
syntactically. This is very important because it makes our
conversations on the other thread moot. We can do ACLs any way we like
... via OpenLDAP compatible flat files or using subentries. Even the
syntax of ACL/ACI specification need not be the same. What ever the
format some code would parse it and add the ACI/ACL set to the authz
subsystem using this API which adds the respective ACL elements to the
data structure used for evaluation.
The question now is where this specialized structure should be and what
should expose this API. It's obvious the authorization subsystem should
manage the data structure since it must make the AC decisions to effect
directory operation within the interceptor chain. Also for this reason
the authz system should expose the API.
So how does this help Tony, Marc, and myself as well as others
interested in this thread? Well consider the two options put forth
already. One was to use OpenLDAP ACL syntax and file format. In this
case a parser would parse the file at startup and add the ACI/ACLs into
the authz subsystem using the exposed API. This would not be conducive
to replication but it would be the same as what OpenLDAP has. Plus it
is not dynamic.
In the case of using subentries to store ACLs, at startup, all ACLs in
subentries would be added to the data structure using the API's of the
authz subsystem. The interceptor for the authz subsystem would pay
special attention to any subentry changes to add, remove or modify
ACI/ACLs via the authz API. This would be dynamic. This way when
subentries replicate with a subtree they trigger ACL changes to the
authz subsystem of replicas. Meaning ACLs are replicated with the data
they control and evaluation is still optimized.
-Alex
Re: [apacheds] ACL implementation options (was ACLs questions)
Posted by David Boreham <da...@bozemanpass.com>.
> So how does this help Tony, Marc, and myself as well as others
> interested in this thread? Well consider the two options put forth
> already. One was to use OpenLDAP ACL syntax and file format. In
> this case a parser would parse the file at startup and add the
> ACI/ACLs into the authz subsystem using the exposed API. This would
> not be conducive to replication but it would be the same as what
> OpenLDAP has. Plus it is not dynamic.
If you are looking for examples to study, take a look at the
Netscape/AOL/Sun server.
It forked off from the same code line as OpenLDAP many years ago so
there are some
similarities, but also fundamental differences. The ACL metadata is
stored in entries,
not in a flat file. The entries are not subentries, but that may have
been due to subentries
not being implemented at the time the ACL mechanism was re-designed.
Subentry
support was added in DS 5.0 time, wheras the ACLs were done in DS 3.0.
Also, the Netscape ACL mechanism embodies a number of features that came
about at the request of customers (put another way, they weren't designed in
an ivory tower, but rather as a result of real [possibly crazy, but
nevertheless real]
folks requests).
YMMV as always.
Re: [apacheds] ACL implementation options (was ACLs questions)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
>Hi,
>
>2005/5/18, Tony Blanchard <bl...@wanadoo.fr>:
>
>
>>I think ACLs with OpenLDAP are too much complicated and the declaration
>>order notion of ACLs in OpenLDAP seems to me dangerous in some ways...
>>And the OpenLDAP file format is not realy java nor modern...
>>
>>
>
>Can't we use existing AAA frameworks like Directory AuthX?
>
>
For an API we can yes if it fits. I have no clue if it will suite our
purposes anymore. I have to reinvestigate. We might wanna start
looking here if we can. However Authx has nothing to do with the
representation we are going to use at this point.
-Alex
Re: [apacheds] ACL implementation options (was ACLs questions)
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
2005/5/18, Tony Blanchard <bl...@wanadoo.fr>:
> I think ACLs with OpenLDAP are too much complicated and the declaration
> order notion of ACLs in OpenLDAP seems to me dangerous in some ways...
> And the OpenLDAP file format is not realy java nor modern...
Can't we use existing AAA frameworks like Directory AuthX?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [apacheds] ACL implementation options (was ACLs questions)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Tony Blanchard wrote:
>> Noel stressed the point that an API should be exposed to add and
>> remove ACLs from this data structure. By exposing such an API ACLs
>> can be added to the structure at runtime or at initialization time
>> using ACL information stored anywhere in any format. Meaning the
>> existance of this API makes our authorization evaluation mechanism
>> independent of the way ACLs are stored or where and how they are
>> represented syntactically. This is very important because it makes
>> our conversations on the other thread moot. We can do ACLs any way
>> we like ... via OpenLDAP compatible flat files or using subentries.
>> Even the syntax of ACL/ACI specification need not be the same. What
>> ever the format some code would parse it and add the ACI/ACL set to
>> the authz subsystem using this API which adds the respective ACL
>> elements to the data structure used for evaluation.
>
>
> I think ACLs with OpenLDAP are too much complicated and the
> declaration order notion of ACLs in OpenLDAP seems to me dangerous in
> some ways...
> And the OpenLDAP file format is not realy java nor modern...
>
Hokay but the option of doing this is available and that may be
comforting. Personally I don't have enough knowledge at this point to
home in on a format myself :).
>> The question now is where this specialized structure should be and
>> what should expose this API. It's obvious the authorization
>> subsystem should manage the data structure since it must make the AC
>> decisions to effect directory operation within the interceptor
>> chain. Also for this reason the authz system should expose the API.
>
>
> I have a question about this. It may be naiv but what about
> computing ACLs from ACLs storage (subentries or other) at
> authentication time. Once authenticated, ACLs are computed from the
> point of view of the authenticated user and then attached to the
> principal ?
Not a bad idea at all. Basically we're computing ACLs on session
creation. Might be a cheaper route then to keep all ACLs in memory from
the start.
> This not needs to be a complete computation and can enlarge each time
> a new access is done to an entry by the user ? This way, we build a
> kind of cache about ACLs permissions and preffered paths in the tree
> for that user. So ACL has already made choice for what the user can do
> or not. If the user can not go under an entry, do not compute ACLs
> which are not relevant.
Yes thinking some more about this it makes what ever data structure we
faster since it prunes down the search space for evaluations. It will
make the server more performant when it comes to ACL evaluations.
<snip/>
> Note: There are some ACLs which are not relevant for user principal. I
> think about ACLs dependant on URLs... So I think there are different
> ACLs kinds and dynamic strategies should differ.
>
Makes sense +1.
>>
>> So how does this help Tony, Marc, and myself as well as others
>> interested in this thread? Well consider the two options put forth
>> already. One was to use OpenLDAP ACL syntax and file format. In
>> this case a parser would parse the file at startup and add the
>> ACI/ACLs into the authz subsystem using the exposed API. This would
>> not be conducive to replication but it would be the same as what
>> OpenLDAP has. Plus it is not dynamic.
>>
>>
>> In the case of using subentries to store ACLs, at startup, all ACLs
>> in subentries would be added to the data structure using the API's of
>> the authz subsystem. The interceptor for the authz subsystem would
>> pay special attention to any subentry changes to add, remove or
>> modify ACI/ACLs via the authz API. This would be dynamic. This way
>> when subentries replicate with a subtree they trigger ACL changes to
>> the authz subsystem of replicas. Meaning ACLs are replicated with
>> the data they control and evaluation is still optimized.
>
>
> Depend on what I said previously regarding the principal holding ACLs
> made decisions. But I agree this second option is better. And I agree
> there should be a observer for the changes on tree.
We think alike :). But no you have a very interesting point about
building the specialized ACL structure for the user when the session is
established. It might cost less I think actually.
> As we advance on this thema, should put some validated ideas expressed
> here on the wiki page for ACLs. Maybe we could make a first version at
> the end of the week to let a maximum of people to participate to this
> thread ? WDYT about it ? ;-)
Good idea let's just keep compiling the ideas. I want to carve up
serious time for this and start work on some implementation soon.
Regards,
Alex
Re: [apacheds] ACL implementation options (was ACLs questions)
Posted by Marc Boorshtein <mb...@yahoo.com>.
> I think ACLs with OpenLDAP are too much complicated
> and the declaration
> order notion of ACLs in OpenLDAP seems to me
> dangerous in some ways...
> And the OpenLDAP file format is not realy java nor
> modern...
>
I don't know much about the openldap acl model, but
here's the draft I was looking for. I don't think it
should be followed to a "T", but it should be a good
starting point.
http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-ldapext-acl-model-08.txt
One nice thing about this is it defines a way (albeit
pretty hard to read) to define an ACI on a single
line.
> >
>
> I have a question about this. It may be naiv but
> what about computing
> ACLs from ACLs storage (subentries or other) at
> authentication time.
> Once authenticated, ACLs are computed from the point
> of view of the
> authenticated user and then attached to the
> principal ?
1. This would probably be very "slow" as binds are one
of the most often used operations
2. What if the ACL changes while the user is bound?
Cacheing ACL information can be very dangerous
I also don't think keeping the acls in memory would
hurt replication. If the interceptor added the acl
informatin in the appropriate circumstances then it
wouldn't really matter as to where they are stored.
I think it boils down to the question of "Are ACLs
configuration or data?" If they are configuration,
then they should be treated as such (and in a multi
server environment there will allways be an issue of
configuration management). If it is data then it
should be included in replication. Outside of
debugging a directory deployment, how often do ACLs
change? Most deployments i've seen they really don't
change all that often.
marc
Re: [apacheds] ACL implementation options (was ACLs questions)
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Alex Karasulu a écrit :
> Hello,
>
>
> I thought I'd start a new thread since some of these ideas transcend
> what we were talking about. Also it helps to hit that reset button
> sometimes :). Just to give you all some background I had a long
> conversation with Noel about approaching ACLs in a fashion where any
> approach could eventually be taken for representing and storing
> them. By tossing around these ideas we came up with some
> implementation possibilities. I'd like to summarize them here on this
> thread and open our conclusions to some discussion.
>
> First off, we both agreed that we need some optimized in memory data
> structure to represent access control information. The ACL data
> representation within this structure is the operational representation
> for efficient AC evaluations. What this structure will be at the
> present moment is irrelavent. We both agreed that something optimized
> for evaluation is key for performance reasons. Now with this data
> structure the implementation of the authorization subsystem is
> trivial. An interceptor is used to reject, alter or allow various
> operations on entries based on the evaluation of these access control
> instructions within the optimized structure.
>
Agree with this.
>
> Noel stressed the point that an API should be exposed to add and
> remove ACLs from this data structure. By exposing such an API ACLs
> can be added to the structure at runtime or at initialization time
> using ACL information stored anywhere in any format. Meaning the
> existance of this API makes our authorization evaluation mechanism
> independent of the way ACLs are stored or where and how they are
> represented syntactically. This is very important because it makes
> our conversations on the other thread moot. We can do ACLs any way we
> like ... via OpenLDAP compatible flat files or using subentries. Even
> the syntax of ACL/ACI specification need not be the same. What ever
> the format some code would parse it and add the ACI/ACL set to the
> authz subsystem using this API which adds the respective ACL elements
> to the data structure used for evaluation.
I think ACLs with OpenLDAP are too much complicated and the declaration
order notion of ACLs in OpenLDAP seems to me dangerous in some ways...
And the OpenLDAP file format is not realy java nor modern...
>
>
> The question now is where this specialized structure should be and
> what should expose this API. It's obvious the authorization subsystem
> should manage the data structure since it must make the AC decisions
> to effect directory operation within the interceptor chain. Also for
> this reason the authz system should expose the API.
I have a question about this. It may be naiv but what about computing
ACLs from ACLs storage (subentries or other) at authentication time.
Once authenticated, ACLs are computed from the point of view of the
authenticated user and then attached to the principal ?
This not needs to be a complete computation and can enlarge each time a
new access is done to an entry by the user ? This way, we build a kind
of cache about ACLs permissions and preffered paths in the tree for that
user. So ACL has already made choice for what the user can do or not. If
the user can not go under an entry, do not compute ACLs which are not
relevant.
In fact, we do not need to compute ACLs for some entries which are never
used by a user..
There is some possible drawbacks for memory size but it saves some
computation time to compare ACL with a user.
Maybe also we could enable everyone to implement different strategies on
authorization, principals and ACLs in memory management.
Note: There are some ACLs which are not relevant for user principal. I
think about ACLs dependant on URLs... So I think there are different
ACLs kinds and dynamic strategies should differ.
>
> So how does this help Tony, Marc, and myself as well as others
> interested in this thread? Well consider the two options put forth
> already. One was to use OpenLDAP ACL syntax and file format. In
> this case a parser would parse the file at startup and add the
> ACI/ACLs into the authz subsystem using the exposed API. This would
> not be conducive to replication but it would be the same as what
> OpenLDAP has. Plus it is not dynamic.
>
>
> In the case of using subentries to store ACLs, at startup, all ACLs in
> subentries would be added to the data structure using the API's of the
> authz subsystem. The interceptor for the authz subsystem would pay
> special attention to any subentry changes to add, remove or modify
> ACI/ACLs via the authz API. This would be dynamic. This way when
> subentries replicate with a subtree they trigger ACL changes to the
> authz subsystem of replicas. Meaning ACLs are replicated with the
> data they control and evaluation is still optimized.
Depend on what I said previously regarding the principal holding ACLs
made decisions. But I agree this second option is better. And I agree
there should be a observer for the changes on tree.
>
>
> -Alex
As we advance on this thema, should put some validated ideas expressed
here on the wiki page for ACLs. Maybe we could make a first version at
the end of the week to let a maximum of people to participate to this
thread ? WDYT about it ? ;-)
Best regards,
Tony