"not" claims lead to spurious error response

[paul-palmer]

We have a use case in which we need to block users with a specific claim from accessing certain parts of the web site.

If we use negative logic to test the claim:
Require not claim roles:forbidden-role or

<RequireNone>
  Require claim roles:forbidden-role
</RequireNone>

the "Requires" are processed correctly, yielding the intended result. However, even though the authorized user's request succeeds, the header:

WWW-Authenticate: Bearer realm="***", error="insufficient_scope", error_description="Different scope(s) or other claims required""

will be added to the response. It appears benign, but is causing confusion when on-boarding new customers.

This appears to be a bug in the module. Can anyone confirm that it is in fact benign?

[zandbelt]

On which platform, which version of the module and which AuthType is this?

Edit: never mind, I reproduced it locally: it is benign indeed: the header is sent by the module after seeing AUTH_DENIED, however the module has no way to know about the surrounding negating logic. I guess we're looking at an extra configuration option to suppress this confusing header...

[paul-palmer]

Thank you for the quick investigation to confirm the benign impact.

Instead of simply suppressing the header, would it be better to set some state at the point of detection and then add the header only after it is determined that a 401 is warranted?

Or, maybe add a variant to "claim" that does not trigger the header?

Or, going further, ideally (for my use case at least) something like "Require not forbidden-claim roles:forbidden-role" that triggers a WWW-Authenticate when the claim is true instead of false.

For my part, I am going to investigate if there are better ways outside of this module to satisfy our use case.

[paul-palmer]

If I understand the code correctly, this header could be generated any time a claim check fails so even something like:

<RequireAny>
  Require claim roles:acceptable-role1
  Require claim roles:acceptable-role2
</RequireAny>

could trigger this behavior if a user had only one of acceptable-role1 or acceptable-role2

[zandbelt]

agree, but it should be noted that this only happens in OAuth 2.0 RS mode (which is deprecated in itself)

[zandbelt]

how about this: 8ed00cc

[paul-palmer]

This looks like a workable and flexible solution. It would certainly satisfy our needs.

[zandbelt]

ok, that is merged now and will be in 2.4.8 later