jacc related

[dt pham]

I have this code working with wildfly 24 on my custom login module:

HttpServletRequest request = (HttpServletRequest) PolicyContext.getContext("javax.servlet.http.HttpServletRequest");

Now, I would like to move to wildfly 27, this code doesn't work any more. I look at the context keys, it only have two keys:

PolicyContext.getHandlerKeys = [javax.security.auth.Subject.container, org.wildfly.security.auth.server.SecurityIdentity]

it does not have "javax.servlet.http.HttpServletRequest" OR "jakarta.servlet.http.HttpServletRequest"

How do I get the HttpServletRequest from login page for my custom login module? 

[Diana Krepinska]

Hi, how does your configuration for custom login module look like? The deprecated security subsystem was removed in wildfly and you should migrate to elytron https://docs.wildfly.org/25/WildFly_Elytron_Security.html#Migrate_Legacy_Security_to_Elytron_Security

[dt pham]

I don't use legacy security module at all here. I create my custom login module by implementing my own SecurityRealm. It works on both wildfly 24 and 27 (of course with some custom configurations. I look at wfly 27 and see a lot more Realm introduced and may be I will see if I can manage to use one of the new realm supported by 27 later) I would like to make it clear for my issue here:

1) I don't enable jacc in wildfly 24 at all and it always give me the HttpServletResuest from my custom login module.

I look at HandlerKeys, it has one key "javax.servlet.http.HttpServletRequest" and that is why I can have this code work:

HttpServletRequest request = (HttpServletRequest) PolicyContext.getContext("javax.servlet.http.HttpServletRequest");

2) In wildfly 27, if I don't enable jacc, I have empty HandlerKeys, and when enabling jacc, I have two keys  [javax.security.auth.Subject.container, org.wildfly.security.auth.server.SecurityIdentity] and therefore I cannot obtain  HttpServletResuest  for key   "javax.servlet.http.HttpServletRequest" OR "jakarta.servlet.http.HttpServletRequest"

[Arjan Tijms]

Hi,

Would it not be even better to migrate to standard Jakarta EE Security modules?

Kind regards,

Arjan Tijms

[Diana Krepinska]

Have you migrated your app from javax.* to jakarta.* interface? WildFly 27 requires jakarta.* . If so, you can create a reproducer otherwise it is not clear what is the issue.

[dt pham]

Yes, it is jakarta now. Otherwise my app won't run. I actually have my app runs fine on wildfly 27 except the issue I mentioned to get extra data from the query of my custom login request. The extra data is for special case when my login module is needing more than just user and password. Look like the login won't propagate the HttpServletRequest from login page to SecurityRealm any more on Wildfly 27 ( or on jakarta version here).

[dt pham]

Based on https://jakarta.ee/specifications/authorization/2.1/jakarta-authorization-spec-2.1.html#a721

All Jakarta Servlet containers must register a PolicyContextHandler whose getContext method returns a jakarta.servlet.http.HttpServletRequest object when invoked with the key “jakarta.servlet.http.HttpServletRequest”. When this handler is activated, the container must return the HttpServletRequest object corresponding to the component request being processed by the container.

The question is how do I activate the handler on wildfly 27?

[dt pham]

Or, was this spec https://jakarta.ee/specifications/authorization/2.1/jakarta-authorization-spec-2.1.html#a721  implemented on wildfly 27?

[dt pham]

For now, I just use ThreadLocal to propagate my custom login request query string via my custom HttpHandler and down to my custom login module realm and ejb. I believe the jakata.ee specs above is not available on wildfly 27 yet. I don't know if there is better way to handle this for now.

[Florin Spătar]

I encountered that exact same issue when I migrated my project from WildFly 26 to WildFly 27. I attached simple servlet app raised it as an issue here: https://issues.redhat.com/browse/WFLY-17824

[Darran Lofthouse]

What does your complete application-security-domain resource look like in the Undertow subsystem?

[Florin Spătar]

I use original standalone-full.xml from WildFly 27.0.1

            <application-security-domains>
                <application-security-domain name="other" security-domain="ApplicationDomain"/>
            </application-security-domains>

If I follow these instructions https://docs.jboss.org/author/display/WFLY/Elytron%20and%20Java%20Authorization%20Contract%20for%20Containers%20(JACC).html, two handlers are activated:

• javax.security.auth.Subject.container
• org.wildfly.security.auth.server.SecurityIdentity

but no HttpServletRequest

[Darran Lofthouse]

So do you have enable-jacc set to true on the application-security-domain resource?

[Florin Spătar]

Yes, enable-jacc is set to true on the application-security-domain resource.

Here are the steps I used to enable jacc:

florin@debian:~/bin/wildfly-27.0.1.Final/bin$ ./jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect
[standalone@localhost:9990 /] /subsystem=security:write-attribute(name=initialize-jacc, value=false)
Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [("subsystem" => "security")]"

[standalone@localhost:9990 /] /subsystem=elytron/policy=jacc:add(jacc-policy={})
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

[standalone@localhost:9990 /] reload
[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=other:add(http-authentication-factory=application-http-authentication,enable-jacc=true)
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0212: Duplicate resource [
    (\"subsystem\" => \"undertow\"),
    (\"application-security-domain\" => \"other\")
]",
    "rolled-back" => true
}

[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=other:write-attribute(name=enable-jacc,value=true)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

[standalone@localhost:9990 /] reload

These steps altered standalone-full.xml as follows:

florin@debian:~/bin/wildfly-27.0.1.Final/bin$ diff ../standalone/configuration/standalone-full.xml.orig ../standalone/configuration/standalone-full.xml
354a355,357
>             <policy name="jacc">
>                 <jacc-policy/>
>             </policy>
535c538

<                 <application-security-domain name="other" security-domain="ApplicationDomain"/>

---
>                 <application-security-domain name="other" security-domain="ApplicationDomain" enable-jacc="true"/>

After enabling jacc, PolicyContext.getHandlerKeys returns [javax.security.auth.Subject.container, org.wildfly.security.auth.server.SecurityIdentity]

You can use the attached WARs & servlet project from https://issues.redhat.com/browse/WFLY-17824 to reproduce the issue.

[Darran Lofthouse]

Thank you for the report and the reproducers, I have put together the changes needed and we are working to get this into WildFly 28.

With the changes the output I now get calling the reproducer is:

Hello World!
PolicyContext.getHandlerKeys = [jakarta.servlet.http.HttpServletRequest, org.wildfly.security.auth.server.SecurityIdentity, javax.security.auth.Subject.container]
looking for jakarta.servlet.http.HttpServletRequest

No errors reported.

[Florin Spătar]

Awesome!

Thank you very much.