Alex Karasulu wrote:
Just some history. When we went from using JNDI interfaces in the core to
using our own well defined interfaces many things were a mess including this
area. At one point I revamped this area of the code cleaning up a lot of
the configuration which was still trying to use Properties a la the old JNDI
way.
I remember paying close attention to allow search operations to occur
without a previous bind on the RootDSE regardless of whether or not
anonymous binds were enabled or not. This was done specifically to allow
for client's to discover the various ways they could bind to the directory
by reading the RootDSE's contents.
I've always thought the RootDSE was something that should be world readable
but I may be wrong now with better clarification in the latest RFC revamp.
Plus life has been hard and I cannot say I've been on top of these matters
as I should.
It might be best to consolidate the behavior of anonymous access to the
server into a single configuration parameter which is an enumerated type
with the following values. Let's call it anonymousAccess:
o ANY - anonymous access to ANY entry is allowed
o ROOTDSE - anonymous access is only allowed on the RootDSE
o NONE - anonymous access is NOT allowed on any entry
All these modes are still subject to any ACI restrictions that may
additionally be configured by administrators. This parameter only governs
at a high level which operations the network protocol layer will allow to
occur on entries. Of course the lower layers also need to adhere to this
policy if for example calls are made directly to the core interfaces via
embedded server configurations where the API is used.
WDYT?
I think we can do a little bit simpler.
What about having the current flag (allowAnonymousAccess) which when set
to false forbid any access to any entry *except* for rootDSE (ie
anonymous search on rootDSE is allowed), plus an ACIItem to control the
rootDSE access if really needed ?
Doing so will not change a lot of things in the server, and will
leverage the ACI subsystem only if really necessary.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
