-
1. Re: basic authentication difference in Wildfly
mchoma Jan 29, 2018 9:56 AM (in response to cbppbc)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 Jan 30, 2018 9:28 AM (in response to mchoma)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
mchoma Jan 31, 2018 7:39 AM (in response to cbppbc)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
mchoma Feb 2, 2018 7:23 AM (in response to mchoma)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 Feb 5, 2018 5:53 AM (in response to mchoma)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
mchoma Feb 5, 2018 8:33 AM (in response to cbppbc)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?
-
7. Re: basic authentication difference in Wildfly
shyamag Jun 4, 2019 1:27 AM (in response to mchoma)I have same problem...auhentication working on jboss as 7.1 but not on wildfly..
web.xml
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!-- <security-constraint>
<web-resource-collection>
<web-resource-name>AgencyPortalUI</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint> -->
<session-config>
<!-- 15 minutes 900000 milliseconds -->
<session-timeout>100</session-timeout>
</session-config>
</web-app>
and my jboss configuration ,same on wildfly
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-domains>
<security-domain name="other" cache-type="default">
<authentication>
<login-module code="Remoting" flag="optional">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
<login-module code="RealmDirect" flag="optional">
<module-option name="usersProperties" value="${jboss.server.config.dir}/application-users.properties"/>
<module-option name="rolesProperties" value="${jboss.server.config.dir}/application-roles.properties"/>
<module-option name="realm" value="ApplicationRealm"/>
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
</authentication>
</security-domain>
<security-domain name="jboss-web-policy" cache-type="default">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
<security-domain name="jboss-ejb-policy" cache-type="default">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
</security-domains>
</subsystem>
and my code
try {
LOGGER.info("before authenticate {}");
userTO = restEasyPortalServiceProxy.getLoginService().authenticate(
userName, userPass);
LOGGER.info("After authenticate : {}", userTO);
userSessionData.setAuthToken(userTO.getAuthToken());
} catch