WildFly 24 Elytron not propogating security context to JAX-RS/EJB

1,324 views
Skip to first unread message

Peter Griffiths

unread,
Oct 28, 2021, 11:06:27 AM10/28/21
to WildFly
Hi all,

I've seen a few posts on here reporting similar issues but none cover exactly what we're seeing...

We're having trouble migrating one of our apps to the Elytron security subsystem on WildFly 24.0.1.Final.  The issue we're currently hitting is that the security context isn't propagated to the EJB/JAX-RS layer from the UI/undertow layer.

With the legacy security subsystem, we can login to the UI via a form and the created user's session allows access to our JAX-RS endpoints.  This isn't happening with the Elytron subsystem.

Interestingly, we have successfully migrated one of our apps to Elytron in the same way and didn't have this same issue.  The apps are structured slightly differently, however; they are both EAR files that contain WAR files but the one that doesn't work for us has the UI and JAX-RS/EJB code in separate WAR files, and therefore separate context roots.  The one that does work has the JAX-RS/EJB code within the same WAR/context root.

Both our apps have jboss-all.xml files within the EAR enabling SSO across the whole app:
<?xml version="1.0" encoding="UTF-8"?>
<jboss umlns="urn:jboss:1.0">
    <shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
        <session-config>
            <cookie-config>
                <path>/</path>
                <name>jsession_id_app</name>
            </cookie-config>
        </session-config>
    </shared-session-config>
</jboss>

Based on the TRACE logs I get after enabling security logging, I suspect it's this difference that's causing our issue:

Failing multiple WAR file app login:
TRACE [org.wildfly.security.http.servlet] (default task-4) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /rest
TRACE [org.wildfly.security.http.servlet] (default task-4) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /rest
TRACE [org.wildfly.security.http.servlet] (default task-4) JASPIC Unavailable, using HTTP authentication.
TRACE [org.wildfly.security] (default task-4) No CachedIdentity to restore.
TRACE [org.wildfly.security] (default task-4) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@513dec47] for mechanism [BASIC]
TRACE [org.wildfly.security] (default task-4) Handling SocketAddressCallback
TRACE [org.wildfly.security] (default task-4) Handling MechanismInformationCallback type='HTTP' name='BASIC' host-name='localhost' protocol='http'
TRACE [org.wildfly.security] (default task-4) Handling AvailableRealmsCallback: realms = []

Working single WAR file app login:
TRACE [org.wildfly.security.http.servlet] (default task-11) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /ui/rest
TRACE [org.wildfly.security.http.servlet] (default task-11) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /ui/rest
TRACE [org.wildfly.security.http.servlet] (default task-11) JASPIC Unavailable, using HTTP authentication.
TRACE [org.wildfly.security] (default task-11) No CachedIdentity to restore.
TRACE [org.wildfly.security] (default task-11) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@1493a3da] for mechanism [BASIC]
TRACE [org.wildfly.security] (default task-11) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@525c5e47] for mechanism [FORM]
TRACE [org.wildfly.security] (default task-11) Handling SocketAddressCallback
TRACE [org.wildfly.security] (default task-11) Handling MechanismInformationCallback type='HTTP' name='BASIC' host-name='localhost' protocol='http'
TRACE [org.wildfly.security] (default task-11) Handling AvailableRealmsCallback: realms = []
TRACE [org.wildfly.security] (default task-11) Handling SocketAddressCallback
TRACE [org.wildfly.security] (default task-11) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
TRACE [org.wildfly.security.http.form] (default task-11) Trying to re-authenticate session f2da-ZEZnd9xgaXp84wG7uCDp41hYnYrG_L5nUxx. Request URI: [http://localhost:8080/ui/rest/endpoint], Context path: [/ui/rest]
TRACE [org.wildfly.security] (default task-11) Handling CachedIdentityAuthorizeCallback: principal = null  authorizedIdentity = SecurityIdentity{principal=username, securityDomain=org.wildfly.security.auth.server.SecurityDomain@6384171c, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='FILE', securityRealm=org.wildfly.extension.elytron.PropertiesRealmDefinition$RealmWrapper@d4f2440}, creationTime=2021-10-28T12:17:31.068Z}
TRACE [org.wildfly.security] (default task-11) Handling AuthenticationCompleteCallback: succeed
TRACE [org.wildfly.security] (default task-11) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=username, securityDomain=org.wildfly.security.auth.server.SecurityDomain@6384171c, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='FILE', securityRealm=org.wildfly.extension.elytron.PropertiesRealmDefinition$RealmWrapper@d4f2440}, creationTime=2021-10-28T12:17:31.068Z}
TRACE [org.wildfly.security] (default task-11) Role mapping: principal [username] -> decoded roles [role1] -> domain decoded roles [] -> realm mapped roles [role1] -> domain mapped roles [role1]

From the above, the app that fails doesn't ever have a FORM HttpServerAuthenticationMechanism created to then reauthenticate the user's session.  Based on the logs for the app that does work, this re-authentication is based on the context path (despite SSO being enabled and set to the / path).  This might explain why we aren't seeing this work for us as our WARs have their own context roots.

Is there something we might be missing from the Elytron side here that might explain what we're seeing or help us get to the point we can migrate?  Nothing jumps out from the various docs on the topic I've read through.

In terms of our WildFly config, we do have both WAR files in the same security domain from the web.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
    <security-domain flushOnSessionInvalidation="true">app_domain</security-domain>
</jboss-web>

Both the undertow and EJB subsystems are configured to use the same domain:
undertow
<application-security-domains>
<application-security-domain name="app_domain" http-authentication-factory="application-http-authentication"/>
</application-security-domains>

ejb
<application-security-domains>
<application-security-domain name="app_domain" security-domain="app_domain"/>
</application-security-domains>

Any assistance here would be greatly appreciated.

Regards,
Peter

Ralph Soika

unread,
Oct 29, 2021, 3:40:06 AM10/29/21
to WildFly
Hi,
I have written a block about this topic as I also stumbled into some migration problems. See here:


Maybe you have missed the ejb jar config? Please let me know if this helped you to solve your problem.

===
Ralph

Peter Griffiths

unread,
Nov 3, 2021, 10:29:13 AM11/3/21
to WildFly
Hi,

Thanks for the link.  I indeed did not have any jboss-ejb3.xml files in the EJB artifacts.  In our case, the config for that comes from the subsystem itself (as we know there isn't anything else going to use the WildFly domain we can use global settings).  As a test, I added one in our EJB artifact (the WAR file) with settings that match those in the linked blog post but still saw the same issue; unauthenticated REST calls apparently ignoring the session setup by undertow.

Peter

Martin Choma

unread,
Dec 9, 2021, 3:37:27 AM12/9/21
to WildFly
This is interesting indeed. Was you able to come to solution? That reminds me security propagation of remote ejb calls which should work [1]. But not sure if it is  your case, more probably not. When you say it works on legacy security, are you in point when only difference is setting security in ejb/undertow subsystems? Is application-http-authentication http authenticaiton factory pointing to app_domain security domain? 

Jean-Christophe Bodin

unread,
Mar 23, 2022, 6:07:38 AM3/23/22
to WildFly
Hi, i've the same problem with wildfly 26/elytron 15
I have two WAR.
One can manage login using a database. Authentication works perfectly when it's deploy by its own. Roles are check as they should. When I embed it in an ear it still works.
Then I try to add a second WAR in the ear and to share session, I add jboss-all.xml to activate shared sessions. In this configuration, login page is still display and authentification process succeed (console show me data: User [FS-FR001/jc.b...@xxxx.com] authenticated successfully). But then forbidden is displayed. 

When I check sessions in wildfly I can see two sessions:
org.wildfly.security.http.form.FormAuthenticationMechanism.Location
http://127.0.0.1:8080/Login/static/logged.html?customerCode=FS-FR001
and 

org.wildfly.security.http.form.FormAuthenticationMechanism.elytron-identity
CachedIdentity{FORM, 'FS-FR001/jc.b...@xxxx.com', SecurityIdentity{principal=FS-FR001/jc.b...@xxxx.com, securityDomain=org.wildfly.security.auth.server.SecurityDomain@2aa28de, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='akistoDbRealm', securityRealm=org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm@27825f32}, creationTime=2022-03-23T09:08:37.787114Z}, false}

It seems that sessions are shared because i see the same sessions for my two wars of the ear.

If i retry to access to a page, the login page display again and a new session is opened (three identical sessions exists for the two wars).
Here's what is displayed in the console after authentification succeed:

10:38:26,727 DEBUG [org.wildfly.security.http.form] (default task-1) User [FS-FR001/jc.b...@xxxx.com] authenticated successfully

10:38:26,727 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: succeed

10:38:26,727 TRACE [org.wildfly.security] (default task-1) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=FS-FR001/jc.b...@xxxx.com, securityDomain=org.wildfly.security.auth.server.SecurityDomain@11662250, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='akistoDbRealm', securityRealm=org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm@4f6a27f6}, creationTime=2022-03-23T09:38:26.624538Z}

WITH JBOSS-ALL => 10:38:26,727 TRACE [org.wildfly.security.http.form] (default task-1) User redirected to default path [http://127.0.0.1:8080/Login/static/]

WITHOUT JBOSS-ALL => 10:44:21,020 TRACE [org.wildfly.security.http.form] (default task-1) User redirected to original path [http://127.0.0.1:8080/Login/static/logged.html?customerCode=FS-FR001]

10:38:26,728 INFO  [org.wildfly.security] (default task-1) ***************************************************

10:38:26,728 INFO  [org.wildfly.security] (default task-1) FS-FR001

10:38:26,728 INFO  [org.wildfly.security] (default task-1) ***************************************************

10:38:26,729 INFO  [org.wildfly.security] (default task-1) Decoded roles [Accounts auditor, Accounts validator, Accounts owner, Other]

10:38:26,729 INFO  [org.wildfly.security] (default task-1) ***************************************************

10:38:26,729 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [FS-FR001/jc.b...@xxxx.com] -> decoded roles [Accounts auditor, Accounts validator, Accounts owner, Other] -> domain decoded roles [] -> realm mapped roles [Accounts auditor, Accounts validator, Accounts owner, Other] -> domain mapped roles [Accounts auditor, Accounts validator, Accounts owner, Other]

10:38:26,738 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /Login

10:38:26,738 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /Login

10:38:26,738 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.

10:38:26,738 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.

10:38:26,738 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@11484bda] for mechanism [FORM]

WITH JBOSS-ALL => 10:38:26,739 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate. There is no session attached to the following request. Request URI: [http://127.0.0.1:8080/Login/static/], Context path: [/Login]

WITH JBOSS-ALL => 10:38:26,739 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = null  authorizedIdentity = null

WITHOUT JBOSS-ALL => 10:44:21,034 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate session 3pB1x7p0hJ8DYghVbP4oFtzr9lIlPoP85VunmRE3. Request URI: [http://127.0.0.1:8080/Login/static/logged.html?customerCode=FS-FR001], Context path: [/Login]
WITHOUT JBOSS-ALL => 10:44:21,034 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = null  authorizedIdentity = SecurityIdentity{principal=FS-FR001/jc.bodin@
xxxx.com, securityDomain=org.wildfly.security.auth.server.SecurityDomain@62cc2fad, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='akistoDbRealm', securityRealm=org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm@772df3b2}, creationTime=2022-03-23T09:44:20.920585Z}
WITHOUT JBOSS-ALL => 10:44:21,034 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: succeed
WITHOUT JBOSS-ALL => 10:44:21,035 TRACE [org.wildfly.security] (default task-1) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=FS-FR001/jc.bodin@
xxxx.com, securityDomain=org.wildfly.security.auth.server.SecurityDomain@62cc2fad, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='akistoDbRealm', securityRealm=org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm@772df3b2}, creationTime=2022-03-23T09:44:20.920585Z}
WITHOUT JBOSS-ALL => 10:44:21,035 INFO  [org.wildfly.security] (default task-1) ***************************************************
WITHOUT JBOSS-ALL => 10:44:21,035 INFO  [org.wildfly.security] (default task-1) FS-FR001
WITHOUT JBOSS-ALL => 10:44:21,035 INFO  [org.wildfly.security] (default task-1) ***************************************************
WITHOUT JBOSS-ALL => 10:44:21,035 INFO  [org.wildfly.security] (default task-1) Decoded roles [Accounts auditor, Accounts validator, Accounts owner, Other]
WITHOUT JBOSS-ALL => 10:44:21,035 INFO  [org.wildfly.security] (default task-1) ***************************************************
WITHOUT JBOSS-ALL => 10:44:21,035 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [FS-FR001/jc.bodin@
xxxx.com] -> decoded roles [Accounts auditor, Accounts validator, Accounts owner, Other] -> domain decoded roles [] -> realm mapped roles [Accounts auditor, Accounts validator, Accounts owner, Other] -> domain mapped roles [Accounts auditor, Accounts validator, Accounts owner, Other]


Reply all
Reply to author
Forward
0 new messages