Date: Wed, 21 Feb 2007 12:16:04 -0800
> From: Pete Rowley <prowley@xxxxxxxxxx>
Sorry, I don't mean to beat too much on a dead horse, but ...
Howard Chu wrote:
> Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to
> request this privilege. There is no assumption of automagic
> authorization.
I guess we can add that. Rich and I have already talked about that as a TBD.
While observing RFC4513 is a good thing, and this implementation does so
when auto-bind is switched off, I believe these kinds of decisions are
the domain of site administrative policy and not of standards documents.
Further, a client in the anonymous bind state has no practical knowledge
of the effects of that state on server responses in any case, nor can it
be sure that binding as a non-anonymous user has any effect on those
responses, nor indeed does auto-bind necessarily remove or add any
privilege for the client - that is all administrative policy and
undefined by any RFC. This is just one more administrative policy option.
Certainly it's true that LDAP has nothing specific to say about
authorization. But don't confuse authorization with authentication; they're
two separate things. A client can easily determine that it's in an anonymous
state, using the WhoAmI extended op.
If "ldapwhoami -x -H ldapi:///" doesn't return a zero-length ID, then your
server is broken.
In addition, LDAP is defined as it is in no small part to the underlying
assumption of TCP and designed around the practical methods of
authentication given that assumption, strictly speaking LDAPI isn't LDAP
(it's not even platform agnostic), and LDAPI has other methods at its
disposal.
And again, don't confuse the protocol with the transport. Fuzzy thinking like
that is one of the reasons we have LDAP today, instead of just DAP over TCP.
Sure the RFCs only define LDAP in terms of TCP, but obviously any reliable,
ordered, stream transport will work just as well. And in a proper library
implementation, such a transport can be substituted between any client and
server without needing to alter any other code in the client or server.
While I understand your concern, the feature is an option, not a
requirement.
Yes, but it shouldn't be an option at all. You provide the option in the
expectation that someone will use it. The presence of such an option
therefore encourages client writers to depend on non-standard behaviors. You
might say "this is a site-local policy decision" but it doesn't just affect a
single site. You implicitly create lock-in with features like this, and you
have no idea what other servers such clients will eventually be talking to.
I would expect thinking like this from Microsoft or Sun, but not from an open
source developer. And no matter how much we may think our respective server
is the best in the world, and that no one would ever have any reason to talk
to any other server, one need only look at SunOne to see that nothing lasts
forever. Providing options that break standards like this *hurts* your users,
it doesn't help them.
The standard mechanism for using an LDAP session with previously established
credentials is to use a SASL/EXTERNAL Bind. Encouraging any other behavior is
flat out wrong.
Yes, it's OK to provide options that completely change the behavior of the
server. But it's only OK to do that *when the client explicitly asks for it*.
I could define a control that causes all strings to be returned in Morse
code, and that would be perfectly fine, because a client has to use the
control before it gets such an outlandish behavior.
Some folks may be wondering why I'm spending so much time on this point,
since it's your server and I'm not contributing to its code. Just remember
that network protocols are about interoperability; nothing you do exists in a
vacuum. Every mistake anyone makes affects everyone - just look at the
dynamic group mess if you need an example...
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
