I agree that the behaviour of the JNDI/LDAP provider now needs to be modified.
We will update the provider to cease using the ManageDsaIT control as a means
to control when referrals are returned.
In the meantime, JNDI applications that wish to avoid sending the ManageDsaIT
control should set the java.naming.referral property to "follow".
In addition, applications that wish to avoid sending the ManageDsaIT control
but also wish to ignore (and not follow) referrals should set the property to
"throw" and then catch and ignore any ReferralException.
Jim Sermersheim wrote:
I completely agree with this Andrew. I suspect that the control was somewhat misunderstood back in the day (4 years prior to RFC 3296 I think) when the ldap service provider was written. Also, I think most servers at that time only applied manageDsaIT to objects resembling the named subodinate references in that RFC.
Vincent,
Are you still over the LDAP service provider development? If so (as Andrew's message illustrates), it seems like some action should be taken in order to avoid confusion and problems * especially since ignore is the default.
Jiim
Andrew Sciberras <andrew.sciberras@eB2Bcom.com> 9/27/04 7:44:55 PM >>>
Hi
There is a good chance that this may have been discussed in the past,
however I am currently seeing serious problems in which the manageDSAIT
control (RFC3296) is being used. My concerns are discussed below and it
would be greatly appreciated if I could get some feedback on whether
others also share my views.
My concerns are with the way that JNDI handles naming referrals and
resultantly their use of the manageDSAIT control within LDAP operations.
In the document titled "JNDI Implementor Guidelines for LDAP Service
Providers - Draft 0.4.2" which can be found at the following location:
http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#referral
a property called java.naming.referral is described.
This property identifies how referrals are to be handled. The default
value of this property is 'ignore'.
The way in which the JNDI API will ignore a referral is by:
"sending a non-critical ManageDsaIT (RFC 3296) LDAP control with each
LDAP request".
In my opinion this is a massive abuse and misuse of the control since
the manageDSAIT control affects a lot more than the returning of referrals.
Looking at RFC3296, I see the following:
"A control, ManageDsaIT, is defined to allow manipulation of referral
and other special objects as normal objects. As the name of control
implies, it is intended to be analogous to the ManageDsaIT service
option described in X.511(97) [X.511]."
Being analogous to the ManageDsaIT service option described in X.511
causes me to have the following concerns:
· The purpose of the control is that it should only be used by
administrative users to manage the DIT. This is significantly different
to it being used as a mechanism to ignore referrals.
· All DSE's are treated as normal entries. This means that all of the
below DSE's will be treated as an object entry (i.e DSE Type Entry):
o Root * Root DSE
o Glue- Represents Knowledge of a name only
o Cp * Context Prefix
o Alias * Alias Entry
o Subr * Subordinate Reference
o Nssr * Non-Specific Subordinate Reference
o Supr * Superior Reference
o Xr * Cross Reference
o AdmPoint * Administrative Point
o Subentry
o Shadow * Shadow Copy
o ImmSupr * Immediate Superior Reference
o Rhob * RHOB Information
o Sa * Subordinate Reference to alias entry
o DsSubentry * DSA Specific subentry
o FamilyMember * Family Member
The purpose here, as I see it, is purely to manage the data within these
entries that would not normally be accessible through the protocol
(DAP). The fact that you don't receive a referral is purely because you
want to administer the data within these entries.
· An operation will never be chained. This is an obvious effect of
treating all DSE's as object entries. If clients who want to ignore
referrals continue to send the manageDSAIT control with every request, a
request will never be chained. This will severely affect any LDAP
Directory that also supports the X.500 distributed protocol (DSP), as
well as any directory that implements Jim's distributed procedure draft.
· Schema Checking on entries.
The manageDSAIT control in X.500 somewhat allows the directory to
perform operations that are not entirely consistent with the schema
governing that entry. For example, it is explicitly stated in X.511 that
an operation that carries the manageDSAIT control can result in the
modification of attributes that are specified as 'no user modification'.
Based on the above information, it is my opinion that using the
manageDSAIT control to prevent a directory from returning referrals is
largely inappropriate and its future use should be largely discouraged.
Comments?
_________________________________________
Andrew Sciberras
eB2Bcom - View500 Software Engineer
Woodhouse Corporate Centre
Suite 3, 935 Station Street
Box Hill North, Victoria 3129, Australia
EMail: andrew.sciberras@eb2bcom.com
Web http://www.eb2bcom.com
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext