[jboss-jira] [JBoss JIRA] (WFLY-6809) Web authentication not treating "**" role constraint as expected

[arjan tijms (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266490#comment-13266490 ] 

arjan tijms commented on WFLY-6809:
-----------------------------------

The Servlet spec lead essentially has clarified this some time ago on his personal blog. See this archived version: 

https://web.archive.org/web/20150912103140/https://weblogs.java.net/blog/swchan2/archive/2013/04/19/role-servlet-31-security-constraint

(or the current automatically migrated one, which however formats horribly: https://community.oracle.com/blogs/swchan2/2013/04/19/role-servlet-31-security-constraint)

I also had a chat with the JACC spec lead about this some time ago. He clarified that in a full Java EE product, the Servlet container *must* follow the JACC spec. So in this case 3.1.3.2 of the JACC spec applies, where a {{WebResourcePermission}} must indeed be added and enforced for the pre-dispatch (authorization) outcome.

_(actually according to the JACC spec lead the Servlet container in a full Java EE server must use the default JACC provider at run time for the pre-dispatch outcome as well as the programmatic role checks. Although in JBoss/WildFly the default JACC provider is available and initialised, it's not actually used by the Servlet container)_

> Web authentication not treating "**" role constraint as expected
> ----------------------------------------------------------------
>
>                 Key: WFLY-6809
>                 URL: https://issues.jboss.org/browse/WFLY-6809
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final
>            Reporter: Guillermo González de Agüero
>            Assignee: Stuart Douglas
>         Attachments: rolestest.war
>
>
> Servlet spec 3.1 states at point 13.3:
> ??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.??
> But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403):
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
>          version="3.1">
>     <security-constraint>
>         <web-resource-collection>
>             <url-pattern>/*</url-pattern>
>         </web-resource-collection>
>         <auth-constraint>
>             <role-name>**</role-name>
>         </auth-constraint>
>     </security-constraint>
>     <login-config>
>         <auth-method>BASIC</auth-method>
>     </login-config>
> </web-app>
> {code}
> With the following, and authenticating a user that has a role "**", the requested page is shown:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
>          version="3.1">
>     <security-constraint>
>         <web-resource-collection>
>             <url-pattern>/*</url-pattern>
>         </web-resource-collection>
>         <auth-constraint>
>             <role-name>**</role-name>
>         </auth-constraint>
>     </security-constraint>
>     <login-config>
>         <auth-method>BASIC</auth-method>
>     </login-config>
>     <security-role>
>         <role-name>**</role-name>
>     </security-role>
> </web-app>
> {code}
> Reproducer war is attached.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)