6 Replies Latest reply on Feb 5, 2018 8:33 AM by Martin Choma

    basic authentication difference in Wildfly

    cbppbc Newbie

      Hello,

       

      I have configured BASIC authentication in my application against the url pattern /admin/* and setup a role (AdminUsers) that a user should belong to in order to access this pattern.

      When I go to any url matching the /admin/* path I get the browser username and password popup and I can successfully enter the credentials of a user who is allocated to the corresponding role.

       

      The behaviour on Wildfly11 is that after authentication, any call from a servlet under the /admin/* path to request.isUserInRole("AdminUsers") returns true. And a call from a servlet not under the /admin/* path to request.isUserInRole("AdminUsers") returns false.

       

      However, under Glassfish 4, Tomcat 8, and Weblogic 12 this latter call to request.isUserInRole("AdminUsers") in a resource not under the the /admin/* path after authentication returns true.

       

      It seems for Wildfly the request path is also taken into consideration, whereas for the other application servers mentioned it's more of a general consideration of whether the user belongs to the role irrespective of the current request path.

       

      I'm currently porting an application from Tomcat to Wildfly11 and hence have found this difference. Is this due to different interpretations of the spec between the app servers? And can Wildfly11/Undertow be configured for basic authentication to work as it does in Tomcat ?

       

      Thanks

        • 1. Re: basic authentication difference in Wildfly
          Martin Choma Master

          And in WildFly 11 did you use Elytron subsystem or legacy security subsystem?

           

          In Elytron I believe Basic authentication is performed on each request. Browser provides credentials on each request. Accessing unprotected resource are you authenticated, in other word is output of request.getRemoteUser() expected?

          What if you access first unprotected resource and then protected?

          In legacy you can cache on security domain level so it will in theory solve your problem.

           

          Can you paste your whole web.xml?

          • 2. Re: basic authentication difference in Wildfly
            cbppbc Newbie

            Yes I believe Elytron is being used since other than adding users and deploying my application I haven't made any configuration changes to wildlfy after downloading. And I do see the following logged on application startup

            [org.wildfly.security] (ServerService Thread Pool -- 23) ELY00001: WildFly Elytron version 1.1.6.Final

             

            I tried what you suggested, and the output of request.getRemoteUser() is null on an unprotected resource. If I access first an unprotected resource and then protected, then the getRemoteUser() is null on the unprotected then on the protected it is populated correctly (after authentication ofcourse).

             

            The cache on security domain in legacy sounds like something to try. Do you have any more specifics on how I would go about this?

             

            And web.xml for your reference:

            <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

            xmlns="http://java.sun.com/xml/ns/javaee"

            xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

            xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

            http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

            id="WebApp_ID" version="3.0">

             

              <display-name>AdminApp</display-name>

              <welcome-file-list>

                <welcome-file>index</welcome-file>

              </welcome-file-list>

             

              <security-constraint>

                <web-resource-collection>

                  <web-resource-name>Admins</web-resource-name>

                  <url-pattern>/admin/*</url-pattern>

                </web-resource-collection>

                <auth-constraint>

                  <role-name>AdminUsers</role-name>

                </auth-constraint>

              </security-constraint>

             

              <security-role>

                <role-name>AdminUsers</role-name>

              </security-role>

             

              <login-config>

                <auth-method>BASIC</auth-method>

                <realm-name>AdminRealm</realm-name>

              </login-config>

            </web-app>

             

            Thanks

            • 3. Re: basic authentication difference in Wildfly
              Martin Choma Master

              If so (you did no changes in configuration), you are using legacy security solution. And I assume cache is on as your default security domain used is other and there is this line in your standalone.xml:

               

              <security-domain name="other" cache-type="default">

               

              What happens if you configure explicitely:

               

              <web-resource-collection>

                    <web-resource-name>Guests</web-resource-name>

                    <url-pattern>/*</url-pattern>

                  </web-resource-collection>

                  <auth-constraint>

                    <role-name>*</role-name>

                  </auth-constraint>

              • 4. Re: basic authentication difference in Wildfly
                Martin Choma Master

                Does it behaves the same also with Elytron. You can switch to Elytron solution with:

                 

                bin/jboss-cli.sh --file=docs/examples/enable-elytron.cli

                 

                • 5. Re: basic authentication difference in Wildfly
                  cbppbc Newbie

                  I made  the Guests configuration as suggested and it does result in the calls to request.isUserInRole("AdminUsers") returning true in paths not on the /admin/* pattern. The only downside is that it prompts for credentials on hitting any application path whereas we only need this from a user if they enter anything in the /admin/* path.

                   

                  And the behaviour is the same after applying the Elytron solution.

                  • 6. Re: basic authentication difference in Wildfly
                    Martin Choma Master

                    Problem is I can't find any argument for filing the JIRA in servlet specification. Currently wildfly behaviour seems correct to me.

                     

                    dlofthouse swd847 Can you have a look?