Payara Server is an open source middleware platform that supports reliable and secure deployments of Java EE (Jakarta EE) and MicroProfile applications in any environment: on premise, in the cloud or hybrid.
Using Custom Form Authentication we successfully protect resources and identify users with their roles.
Upon a redeployment with keeping sessions, e.g. during development with Eclipse and Payara Tools or by redeploying the WAR-file with session/state keeping active, the roles are lost. There is no redirection to the login page. Instead a 403 error is thrown on protected resources. While losing the roles, there is still a principal object attainable via an injected SecurityContext. That one however changes type, which might be a hint to the underlaying problem.
Expected Outcome
A redeployment with no real functional changes and state/session keeping active should keep the users roles and have them continue using the application.
If during redeployment the session cannot be kept it is expected to also lose the current principal and to redirect to the login page instead of throwing a 403 error.
Current Outcome
After first deployment and upon calling a protected resource one is redirected to the configured login page and after successful login a principal like jakarta.security.enterprise.CallerPrincipal@45f05de is created and the appropriate roles are attained.
After a redeployment access to a protected resource results in a 403 error. There is no redirection to the login page.
All roles are lost, i.e. a call to SecurityContext#isCallerInRole("someRole") returns false.
However, getting the principal via securityContext.getCallerPrincipal() returns an object of type com.sun.enterprise.security.web.integration.WebPrincipal.
Upon first deployment call the protected resource http://localhost:8080/CustomFormAuthentication/auth/welcome.xhtml. It redirects to a login-page. You can login successfully with username user and password pass0. You are redirected to a simple "Welcome Secure" page.
Authentication type :FORM
Caller Principal :jakarta.security.enterprise.CallerPrincipal@45f05de
Caller Principal Class :class jakarta.security.enterprise.CallerPrincipal
User in Role 'user' :true
User in Role 'admin' :false
Redeploy the application, making certain to activate the Keep State feature.
Call the protected resource from above again: you receive a 403 error and you are not redirected to a login.
Call the servlet again, you get an output like:
Authentication type :FORM
Caller Principal :user
Caller Principal Class :class com.sun.enterprise.security.web.integration.WebPrincipal
User in Role 'user' :false
User in Role 'admin' :false
As you can see the Principal still identifies as the logged in "user", however the class type changed. The role "user" is not active anymore.
Operating System
Windows 10 Pro
JDK Version
OpenJDK 64-Bit Server VM Zulu17.42+19-CA (build 17.0.7+7-LTS, mixed mode, sharing)
Brief Summary
Using Custom Form Authentication we successfully protect resources and identify users with their roles. Upon a redeployment with keeping sessions, e.g. during development with Eclipse and Payara Tools or by redeploying the WAR-file with session/state keeping active, the roles are lost. There is no redirection to the login page. Instead a 403 error is thrown on protected resources. While losing the roles, there is still a principal object attainable via an injected SecurityContext. That one however changes type, which might be a hint to the underlaying problem.
Expected Outcome
A redeployment with no real functional changes and state/session keeping active should keep the users roles and have them continue using the application. If during redeployment the session cannot be kept it is expected to also lose the current principal and to redirect to the login page instead of throwing a 403 error.
Current Outcome
After first deployment and upon calling a protected resource one is redirected to the configured login page and after successful login a principal like
jakarta.security.enterprise.CallerPrincipal@45f05de
is created and the appropriate roles are attained.After a redeployment access to a protected resource results in a 403 error. There is no redirection to the login page. All roles are lost, i.e. a call to
SecurityContext#isCallerInRole("someRole")
returnsfalse
. However, getting the principal viasecurityContext.getCallerPrincipal()
returns an object of typecom.sun.enterprise.security.web.integration.WebPrincipal
.Reproducer
https://dyn.jaran.de/nc/s/8E3nn5dyqPt5SqJ contains a war file (with sources) created from an example implementation by Baeldung ([https://www.baeldung.com/java-ee-8-security]()).
Upon first deployment call the protected resource http://localhost:8080/CustomFormAuthentication/auth/welcome.xhtml. It redirects to a login-page. You can login successfully with username
user
and passwordpass0
. You are redirected to a simple "Welcome Secure" page.After that call the servlet http://localhost:8080/CustomFormAuthentication/welcome. You're presented with an output like:
Redeploy the application, making certain to activate the Keep State feature. Call the protected resource from above again: you receive a 403 error and you are not redirected to a login. Call the servlet again, you get an output like:
As you can see the Principal still identifies as the logged in "user", however the class type changed. The role "user" is not active anymore.
Operating System
Windows 10 Pro
JDK Version
OpenJDK 64-Bit Server VM Zulu17.42+19-CA (build 17.0.7+7-LTS, mixed mode, sharing)
Payara Distribution
Payara Server Full Profile