Re: authmeth: Access controls vs. confidentialityRequired

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:30 PM 9/28/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> At 11:23 AM 9/28/2004, Hallvard B Furuseth wrote:
>>>Kurt D. Zeilenga writes:
>>>> The choice of which code to return depends on what the
>>>> server is trying to indicate.   For instance, if the
>>>> server requires some form of data confidentiality to
>>>> update the directory, returning confidentialityRequired
>>>> is a good code to indicate that this requirement has
>>>> been violated.
>>> (...)
>>>> However, if the server is willing to
>>>> perform the operation but decides in that performance
>>>> that some access control factor precludes completing
>>>> that operation, insufficientAccessRights is good code
>>>> to indicate this.
>>>
>>> I don't understand.  Sounds to me like either the first case is an
>>> example of the second, unless you mean the second case is about how the
>>> operation is implemented - that is, it starts performing the operation
>>> and then runs into the access control factor, as opposed to discovering
>>> the access control factor at once.  I don't see why that should affect
>>> what the server says about why the operation was refused.
>> 
>> I'm trying to point out that the choice of code that
>> is returned in such cases often depends on whether
>> the decision to return the code was made within the
>> access rights (authorization) subsystem or made within
>> some other administrative control subsystem.
>
>Well, yes, that's why I started this thread.  The natural way for the
>server to do this does not seem to be the right way, unless it
>explicitly provides another way than access control factors which should
>be used to require a secure connection for access to an entity.

>I've been waffling a bit over this, but lacking examples to the
>contrary, I think the draft has it right 'in theory': The server MUST
>return confidentialityRequired.  In practice, I suspect that's too hard
>a requirement and only should be a SHOULD, with a warning that ignoring
>the SHOULD can give severely misleading error responses.

As I previously noted, I don't think the specification should,
in general, prescribe when particular results codes are to be
returned.  Instead, the specification should detail what each
code indicates (in regards to the request) and, except for some
guidelines, leave it to servers to return the most appropriate
result code.

Kurt