Wildfly 26 - Java EE Security - Inject SecurityContext

[Claudio Weiler]

Hi!

This is an old issue: https://developer.jboss.org/thread/278902

How can I inject SecurityContext from Java EE Security specification?

When I try to inject  javax.security.enterprise.SecurityContext, it throws following exception: "WELD-001408: Unsatisfied dependencies for type SecurityContext with qualifiers @Default"

In above old thread, I was told to use "jaspitest" security domain, but never managed to made this work. But now, with WildFly 26, there is no more "jaspitest".

Everything (but this injection) works:

• web security restriction in web.xml
• JSF checking with request.isUserInRole
• javax.annotation.security.RolesAllowed anotation in EJB and CDI beans

My security domain is based on Keycloak adapter (WF26).

Hope someone can help me understand this!

Thanks!

-------->8--------

Snippets from standalone.xml

<security-domains>
    <security-domain name="ManagementDomain" default-realm="ManagementRealm" permission-mapper="default-permission-mapper">
        <realm name="ManagementRealm" role-decoder="groups-to-roles"/>
        <realm name="local" role-mapper="super-user-mapper"/>
    </security-domain>
    <security-domain name="ApplicationDomain" default-realm="ApplicationRealm" permission-mapper="default-permission-mapper">
        <realm name="ApplicationRealm" role-decoder="groups-to-roles"/>
        <realm name="local"/>
    </security-domain>
    <security-domain name="KeycloakDomain" default-realm="KeycloakOIDCRealm" permission-mapper="default-permission-mapper">
        <realm name="KeycloakOIDCRealm"/>
    </security-domain>
</security-domains>

...

<application-security-domains>
    <application-security-domain name="other" http-authentication-factory="keycloak-http-authentication"/>
    <application-security-domain name="keycloak" http-authentication-factory="keycloak-http-authentication"/>
</application-security-domains>

[Darran Lofthouse]

How are you configuring the authentication mechanism for this deployment?

For Jakarta EE Security if we detect that a Jakarta EE Security authentication mechanism is activated then the Jakarta EE Security beans are made available for use by the deployment, otherwise none of them are made available.  Is there something specific you are looking to access on the SecurityContext?

[Claudio Weiler]

Hi Darran!

> How are you configuring the authentication mechanism for this deployment?

I register keycloak adapter(*) as documentation and tools. Results on standalone.xml is on first post.

To enable this application-security-domain in application I use web.xml and jboss-ejb3.xml (EAR deployment). Note that security context is working flawless.

* I know keycloak adapter is deprecated, but in WF 26 OIDC can't propagate security context from war to ear: https://github.com/wildfly/wildfly-proposals/pull/501

Obs. I also have HAL protected with this security domain

>  Is there something specific you are looking to access on the SecurityContext?

I want to use Java EE SecurityContext for some manual checks, without this class I need to use EJBContext (ejb) or ExternalContext (jsf).

Thanks!

[Arjan Tijms]

Hi,

On Tuesday, August 22, 2023 at 2:47:34 PM UTC+2 Darran Lofthouse wrote:

For Jakarta EE Security if we detect that a Jakarta EE Security authentication mechanism is activated then the Jakarta EE Security beans are made available for use by the deployment, otherwise none of them are made available.  Is there something specific you are looking to access on the SecurityContext?

Maybe we should clarify this better in the specification, although I'm sure I at least stated the intend on several occasions; the Jakarta Security context is independent from what authentication mechanism has been used to authenticate. The connection between existing security APIs and Jakarta EE Security works in two ways:

1. Independent of whether Servlet build-in authentication mechanisms or Jakarta Security authentication mechanisms are used (or even Jakarta Authentication ones), the Jakarta Security Context should be functional.

2. When a Jakarta Security authentication mechanism was used to authenticate, all existing security APIs (specifically those in Servlet, Enterprise Beans and REST) should continue to work, in the same way when authentication with a Servlet build-in authentication mechanism was done.

Kind regards,

Arjan Tijms

 

[Darran Lofthouse]

On Wednesday, 23 August 2023 at 18:12:28 UTC+1 Arjan Tijms wrote:

Hi,

On Tuesday, August 22, 2023 at 2:47:34 PM UTC+2 Darran Lofthouse wrote:

For Jakarta EE Security if we detect that a Jakarta EE Security authentication mechanism is activated then the Jakarta EE Security beans are made available for use by the deployment, otherwise none of them are made available.  Is there something specific you are looking to access on the SecurityContext?

Maybe we should clarify this better in the specification, although I'm sure I at least stated the intend on several occasions; the Jakarta Security context is independent from what authentication mechanism has been used to authenticate. The connection between existing security APIs and Jakarta EE Security works in two ways:

If you could please get an issue raised Arjan to clarify this in the spec that would be great.

 

1. Independent of whether Servlet build-in authentication mechanisms or Jakarta Security authentication mechanisms are used (or even Jakarta Authentication ones), the Jakarta Security Context should be functional.

This sounds complementary to something I am actually working to propose in Soteria, at the moment in Soteria the CDI extension registrations means it is all or nothing.  The proposal I am looking to make it to make it easier for vendors to select the subset that they need, so in this regard the SecurityContext could be handled in a minimal core set of beans registered.