arjantijms
commented
2 years ago I recognise some of the tone and wording here as coming from Ron Monzillo, who probably was the author of that section. If I'm not mistaken he based that off of the corresponding rules in Jakarta Authorization.
Although it's not an easy read either, you may find some clarification there: https://jakarta.ee/specifications/authorization/2.0/authorization-spec-2.0.html
markt-asf
Overall this section is somewhat confusing with seemingly conflicting definitions vaguely established. This is even worse when the 'deny-uncovered-http-methods' comes into play.
"When an application’s security configuration contains no uncovered methods" - seems like double negative? According to definition above, uncovered means its not present, so configuration cant contain those at all?
"The security-constraint schema provides the ability to enumerate (including by omission) " - seemingly defines "covered" methods in an ambiguous way - "including by omission" - partial or full? Its tad more confusing in light of following statements " We refer to the HTTP methods that are not established by the enumeration as 'uncovered' HTTP methods." So enumeration by omission seems to define 'covered' method, but later on, omission defines 'uncovered'.
In light of 1 and 2, what should deny-uncovered-http-methods do?
"The determination of whether methods are uncovered is made after all the constraints that apply to a url-pattern have been combined" - another definition of 'uconvered' ?
Possibly minor or might have been covered along the spec, but "Uncovered HTTP methods are NOT protected at all request URLs for which a url pattern of the security-constraint is a best match." - what kind of protection?
In the end, it would be best to establish clear definitions and rules( if any) and afterwards stack up rules on top of those.
REF: https://issues.redhat.com/browse/JBEAP-23166