Auth constraint with role name of "*" defaults to deny

This will probably need some further investigation but just raising the Jira for now so recorded.

I have been working with a deployment where I wish to trigger authentication for all paths except for one specific path where I wish to allow unauthenticated access so went for the following constraints.

     <security-constraint>
         <display-name>All Paths</display-name>
         <web-resource-collection>
             <web-resource-name>All</web-resource-name>
             <url-pattern>/*</url-pattern>
         </web-resource-collection>
         <auth-constraint>
             <role-name>**</role-name>
         </auth-constraint>
    </security-constraint>

     <security-constraint>
         <display-name>Unrestricted Path</display-name>
         <web-resource-collection>
             <web-resource-name>Unrestricted</web-resource-name>
             <url-pattern>/some/special/path</url-pattern>
         </web-resource-collection>
         <auth-constraint>
             <role-name>*</role-name>
         </auth-constraint>
    </security-constraint>

This had the desired effect in relation to authentication, it became mandatory for all paths except the special path. The all paths constrains also did not trigger any authorisation failures i.e. 403 but the special path does.

Debugging this we have a default behaviour of deny all if no roles are specified. This definitely makes sense for annotated servlets where a developer could inadvertently omit an annotation so we deliberately fail safe. But in this example my configuration specifically states I want to allow anyone through so if this constraint is matched I think we should consider if the specific constraint should default to PERMIT.

I did look at jboss-web.xml overrides to see if I could override the mode, although I can override on a servlet basis I can't override it for the general path based constraint. If the current behaviour is deemed correct maybe a path based override in the jboss-web.xml could be considered.