[
https://issues.apache.org/jira/browse/TOMEE-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jung updated TOMEE-4649:
-------------------------------
Description:
{{SecurityContext.hasAccessToWebResource("/protectedServlet", "GET")}} returns
{{false}} for user {{tom}}, who holds the Manager role, on a resource guarded
by {{@HttpMethodConstraint("GET")}}. The spec requires {{true}} here, since tom
is authorized for that resource and method.
The caller and role checks work. The {{securitycontext/callerdata}} servlet
reports the correct caller name and confirms role membership. Only the
{{hasAccessToWebResource}} check gives the wrong answer.
The cause: TomEE's {{SecurityContext}} does not call through to the servlet
authorization/Policy layer for this check. It answers the access question on
its own, without asking the layer that holds the real constraint data, so it
cannot see that GET is allowed for the Manager role.
h2. Steps to reproduce / TCK reference
Run the old TCK test:
* Class/method:
{{securitycontext/callerdata/Client.java#testSecurityContextHasAccessToWebResource}}
This test is excluded in {{runner-standalone/exclusions/security-old.txt}} in
the apache/tomee-tck harness repo. Remove the exclusion once the fix lands,
then rerun the {{security-old}} suite to confirm the test passes.
was:
h2. Description
{{SecurityContext.hasAccessToWebResource("/protectedServlet", "GET")}} returns
{{false}} for user {{tom}}, who holds the Manager role, on a resource guarded
by {{@HttpMethodConstraint("GET")}}. The spec requires {{true}} here, since tom
is authorized for that resource and method.
The caller and role checks work. The {{securitycontext/callerdata}} servlet
reports the correct caller name and confirms role membership. Only the
{{hasAccessToWebResource}} check gives the wrong answer.
The cause: TomEE's {{SecurityContext}} does not call through to the servlet
authorization/Policy layer for this check. It answers the access question on
its own, without asking the layer that holds the real constraint data, so it
cannot see that GET is allowed for the Manager role.
h2. Steps to reproduce / TCK reference
Run the old TCK test:
* Class/method:
{{securitycontext/callerdata/Client.java#testSecurityContextHasAccessToWebResource}}
This test is excluded in {{runner-standalone/exclusions/security-old.txt}} in
the apache/tomee-tck harness repo. Remove the exclusion once the fix lands,
then rerun the {{security-old}} suite to confirm the test passes.
> SecurityContext.hasAccessToWebResource() returns false for an authorized
> caller
> -------------------------------------------------------------------------------
>
> Key: TOMEE-4649
> URL: https://issues.apache.org/jira/browse/TOMEE-4649
> Project: TomEE
> Issue Type: Bug
> Reporter: Markus Jung
> Priority: Major
>
> {{SecurityContext.hasAccessToWebResource("/protectedServlet", "GET")}}
> returns {{false}} for user {{tom}}, who holds the Manager role, on a resource
> guarded by {{@HttpMethodConstraint("GET")}}. The spec requires {{true}} here,
> since tom is authorized for that resource and method.
> The caller and role checks work. The {{securitycontext/callerdata}} servlet
> reports the correct caller name and confirms role membership. Only the
> {{hasAccessToWebResource}} check gives the wrong answer.
> The cause: TomEE's {{SecurityContext}} does not call through to the servlet
> authorization/Policy layer for this check. It answers the access question on
> its own, without asking the layer that holds the real constraint data, so it
> cannot see that GET is allowed for the Manager role.
> h2. Steps to reproduce / TCK reference
> Run the old TCK test:
> * Class/method:
> {{securitycontext/callerdata/Client.java#testSecurityContextHasAccessToWebResource}}
> This test is excluded in {{runner-standalone/exclusions/security-old.txt}} in
> the apache/tomee-tck harness repo. Remove the exclusion once the fix lands,
> then rerun the {{security-old}} suite to confirm the test passes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
