[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: new internet draft - LDAP Extensions Style Guide
clarification request, please - I interpret the first statement below (Bind
discussion) to indicate that any authentication/authorization information is
ONLY conveyed during the Bind argument/response exchange. Is this correct?
Can subsequent operations also convey information useful to an access
control decision function?
regards,
Sandi
-----Original Message-----
From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com]
Sent: Tuesday, August 15, 2000 4:30 PM
To: ietf-ldapext@netscape.com
Subject: Re: new internet draft - LDAP Extensions Style Guide
At 05:43 PM 8/15/2000 +0100, David Chadwick wrote:
>I agree with Kurt that controls are there to modify individual
>operations and therefore putting them on the Bind is a nonsense.
I would not say that it is "a nonsense". As it stands now, the Bind
Operation does have an affect on every succeeding operation. For example,
the identity and the authentication mechanism in the Bind will result in
different privileges and levels of access to the directory information. It
seems natural to me to include at the time of the bind a list of Controls
that the client is willing to accept from the server. The alternatives are
I see it are:
- don't ever let the client tell the server
- include a list of acceptable controls with each operation request,
assuming that the server is really stupid, and
can't remember the list from one operation to the next.
- define a new extended operation that allows the client to submit a list
of acceptable controls
I seem to remember in one of the draft versions of RFC 2251 that there was
a way to set client options/defaults. I'd thought that it was in the Bind
someplace, but was later dropped. Maybe one of the Marks (Smith or Wahl)
can remember better (not that history matters that much). This gives a way
of allowing for controls which are not specifically solicited to be
returned by the server, without the client having to specifically request
them.
Perhaps it doesn't matter too much (as you say below), if each control
definition includes the list of valid other controls that may be returned
in the response, and unsolicited, unsupported controls are always ignored
by the client. Hopefully, the interaction amongst controls will not
become too complex in the future.
>The client may perform some operations and not want the controls
>to take effect (e.g. duplicate entries) even though it supports them.
>
>Thus a server should not send controls to the client if the client has
>not used them first on the operation. It follows from this that each
>operation request control needs to clearly specify which response
>controls may be applied by the server, but I guess we are already
>doing this in our extensions, although sometimes it might be implicit.
>This will need to be checked as the IDs move to proposed standard.
>
>David
>
>***************************************************
>
>David Chadwick
>IS Institute, University of Salford, Salford M5 4WT
>Tel +44 161 295 5351 Fax +44 161 745 8169
>Mobile +44 790 167 0359
>Email D.W.Chadwick@salford.ac.uk
>Home Page http://www.salford.ac.uk/its024/chadwick.htm
>Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
>X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
>Entrust key validation string MLJ9-DU5T-HV8J
>
>***************************************************
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories:
http://www.phptr.com/ptrbooks/ptr_0139744525.html
****************************************************************************
*
This confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
****************************************************************************
**