Add "jaspitest" security domain to standalone.xml of WildFly instances

[arjantijms]

All JASPIC tests now fail because of a missing security domain. This security domain is a bit of an unfortunate thing (it actually shouldn't be needed, but for the moment it is)

The required XML to be added in the "security-domains" tag is:

<security-domain name="jaspitest" cache-type="default">
    <authentication-jaspi>
        <login-module-stack name="dummy">
            <login-module code="Dummy" flag="optional"/>
        </login-module-stack>
        <auth-module code="Dummy"/>
    </authentication-jaspi>
</security-domain>

[bartoszmajsak]

Hi @arjantijms
Could you make pull request out of it?

[bartoszmajsak]

Does it also apply to jacc module?

[arjantijms]

Could you make pull request out of it?

That may not be 100% trivial as it concerns standalone.xml, which is not
deployed and afaik not under version control. It's part of the installed
WildFly instance on the Jenkins server.

[bartoszmajsak]

I believe we can have our own standalone.xml versioned and then pass it as startup argument for the container, sth like: ./standalone.sh -c standalone-javaeesamples.xml
So in arquillian.xml we can use serverConfig attributeof the container configuration for that.

[radcortez]

It should be possible to add that into a CLI script and execute it in the Wildfly instance running the tests. I have done something similar, like combining these:
http://www.radcortez.com/spring-batch-as-wildfly-module/
and
http://www.radcortez.com/custom-principal-and-loginmodule-for-wildfly/

[radcortez]

In the custom principal sample, I'm executing the CLI file directly in the test, but we can extract it and run it as a maven profile with the wildfly plugin. This can be linked with the already existent profile to run the tests.

[bartoszmajsak]

I think making a custom xml is less of an over head, but on the other hand CLI is a bit more flexible. I think the optimal solution would be to have an ability to pass an arbitrary CLI script through container adapter configuration and let it do the work. @aslakknutsen what do you think about it?

[arjantijms]

One step further would be to have an Arquillian option to copy/deploy
arbitrary resources from the test archive to a location relative to the
server container.

This is for instance needed to really test JACC on multiple containers;
JACC is extremely deploy unfriendly as it requires the custom JACC modules
to be on the classpath of the container.

Next to "arbitrary location", Arquillian could abstract it to "server
classpath" since this location is oftentimes different for each server.

On Tuesday, August 12, 2014, Bartosz Majsak notifications@github.com
wrote:

I think making a custom xml is less of an over head, but on the other hand
CLI is a bit more flexible. I think the optimal solution would be to have
an ability to pass an arbitrary CLI script through container adapter
configuration and let it do the work. @aslakknutsen
https://github.com/aslakknutsen what do you think about it?

—
Reply to this email directly or view it on GitHub
#243 (comment)
.

[arjantijms]

Hi again, just wondering what the best path forward here is.

Being able to deploy arbitrary resources to the container is of course really cool, but perhaps the easiest solution for now is to just copy the snippet I opened this issue with in the standalone.xml file of the installed WildFly?

[arun-gupta]

Lets move forward with your suggested approach and file an issue on spec/WildFly to make it more standards-based ?

[arjantijms]

Sounds like a plan ;)

I've been discussing the issue with Stefan Guilhen for a while now, so it's definitely known. It was a while ago that we last talked though, so I'll ask him what the current status is. I do remember he was looking into activating JASPIC like all other servers do, so without the requirement of a dummy domain in standalone.xml.

At any length, I'll create a specific issue for this as well in case there isn't one already. Thanks!

[johnament]

I'll create a standalone.xml in source so that we can at least run the tests again.

Can you create a snippet so that this can run on glassfish as well?

[arjantijms]

I'll create a standalone.xml in source so that we can at least run the tests again.

Great!

Can you create a snippet so that this can run on glassfish as well?

It's not needed for GlassFish (or any other Java EE implementation for that matter). As the only server out there WildFly requires that JASPIC is explicitly activated at the server level, but this is not entirely compliant. The code activates JASPIC programmatically, which should be all that's needed.

As mentioned above, I've extensively discussed this with Stefan Guilhen and he agreed it's a kind of hack, but at the time the release window for 8.0 was closing so the sort of hack was left in.

[arjantijms]

It looks like this is still broken. See e.g.

https://javaee-support.ci.cloudbees.com/job/javaee7-samples-wildfly-8.2/lastBuild/org.javaee7.jaspic$wrapping/testReport/org.javaee7.jaspic.wrapping/WrappingTest/org_javaee7_jaspic_wrapping_WrappingTest/

Although WildFly is being more than a little cryptic with its error message, the following seems to indicate that the required security domain is still or again missing:

Caused by: java.lang.Exception: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.deployment.default-server.default-host./3a7dd5d2-41ce-424c-8f03-a6ae390b9985.UndertowDeploymentInfoService is missing [jboss.security.security-domain.jaspitest]"]}

(btw, this also again proves how bad it is to have to rely on things in standalone.xml)