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

Closed
arjantijms opened this Issue Jul 25, 2014 · 23 comments

Comments

Projects
None yet
6 participants
@arjantijms
Contributor

arjantijms commented Jul 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Aug 12, 2014

Contributor

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

Contributor

bartoszmajsak commented Aug 12, 2014

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

@bartoszmajsak

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Aug 12, 2014

Contributor

Does it also apply to jacc module?

Contributor

bartoszmajsak commented Aug 12, 2014

Does it also apply to jacc module?

@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Aug 12, 2014

Contributor

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.

Contributor

arjantijms commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Aug 12, 2014

Contributor

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.

Contributor

bartoszmajsak commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@radcortez

radcortez Aug 12, 2014

Contributor

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/

Contributor

radcortez commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@radcortez

radcortez Aug 12, 2014

Contributor

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.

Contributor

radcortez commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Aug 12, 2014

Contributor

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?

Contributor

bartoszmajsak commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Aug 12, 2014

Contributor

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)
.

Contributor

arjantijms commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Sep 30, 2014

Contributor

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?

Contributor

arjantijms commented Sep 30, 2014

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

This comment has been minimized.

Show comment
Hide comment
@arun-gupta

arun-gupta Oct 1, 2014

Contributor

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

Contributor

arun-gupta commented Oct 1, 2014

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

@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Oct 1, 2014

Contributor

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!

Contributor

arjantijms commented Oct 1, 2014

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 johnament self-assigned this Oct 5, 2014

@johnament

This comment has been minimized.

Show comment
Hide comment
@johnament

johnament Oct 5, 2014

Contributor

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?

Contributor

johnament commented Oct 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Oct 5, 2014

Contributor

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.

Contributor

arjantijms commented Oct 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Feb 23, 2015

Contributor

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)

Contributor

arjantijms commented Feb 23, 2015

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)

@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Feb 23, 2015

Contributor

@johnament @arun-gupta Did you ever looked into this? Is it still broken or did it broke again when a new WildFly install was done?

Contributor

arjantijms commented Feb 23, 2015

@johnament @arun-gupta Did you ever looked into this? Is it still broken or did it broke again when a new WildFly install was done?

@arun-gupta

This comment has been minimized.

Show comment
Hide comment
@arun-gupta

arun-gupta Feb 23, 2015

Contributor

I never looked at it. Have you followed on wildfly-dev alias?

Contributor

arun-gupta commented Feb 23, 2015

I never looked at it. Have you followed on wildfly-dev alias?

@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Feb 23, 2015

Contributor

@arun-gupta

I never looked at it. Have you followed on wildfly-dev alias?

Sorry, I perhaps wasn't entirely clear. The question was not about fixing the underlying issue (I recently had a short discussion with Stefan Guilhen about this), but about applying the XML fragment from the openings post to standalone.xml.

But eventually this is probably not going to work. The JASPIC tests require a modification of standalone.xml, so I have to ask one of the maintainers of the WildFly installation of this project to do that. Maybe they do this, maybe they don't do this. Maybe my explanation is clear, maybe it isn't. And when the XML fragment gets applied, it may get put in the right or wrong place. And suppose it's finally at the right place, then everything starts all over again whenever a new installation for WildFly is done.

This is actually quite an interesting public display of exactly what goes wrong in organizations that have a split between developers and ops, and where something that is a developer thing has to be done by ops, since it's in a file that only ops is allowed to touch ;)

Perhaps its therefor better that we go for the solution proposed by @bartoszmajsak and pack a copy of standalone.xml with the tests where the fragment is added, or go for the CLI approach suggested by @radcortez. There's also some information here which mentions yet another method (programmatic): https://developer.jboss.org/thread/238534

Contributor

arjantijms commented Feb 23, 2015

@arun-gupta

I never looked at it. Have you followed on wildfly-dev alias?

Sorry, I perhaps wasn't entirely clear. The question was not about fixing the underlying issue (I recently had a short discussion with Stefan Guilhen about this), but about applying the XML fragment from the openings post to standalone.xml.

But eventually this is probably not going to work. The JASPIC tests require a modification of standalone.xml, so I have to ask one of the maintainers of the WildFly installation of this project to do that. Maybe they do this, maybe they don't do this. Maybe my explanation is clear, maybe it isn't. And when the XML fragment gets applied, it may get put in the right or wrong place. And suppose it's finally at the right place, then everything starts all over again whenever a new installation for WildFly is done.

This is actually quite an interesting public display of exactly what goes wrong in organizations that have a split between developers and ops, and where something that is a developer thing has to be done by ops, since it's in a file that only ops is allowed to touch ;)

Perhaps its therefor better that we go for the solution proposed by @bartoszmajsak and pack a copy of standalone.xml with the tests where the fragment is added, or go for the CLI approach suggested by @radcortez. There's also some information here which mentions yet another method (programmatic): https://developer.jboss.org/thread/238534

@arun-gupta

This comment has been minimized.

Show comment
Hide comment
@arun-gupta

arun-gupta Feb 24, 2015

Contributor

CLI approach is probably the recommended one. Do you think this needs further discussion or you can send a PR?

Contributor

arun-gupta commented Feb 24, 2015

CLI approach is probably the recommended one. Do you think this needs further discussion or you can send a PR?

@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Feb 24, 2015

Contributor

Okay, I'll try the CLI approach then. Don't think it needs much more discussion. I will experiment a bit with it locally and if works I'll send a PR. Thanks!

Contributor

arjantijms commented Feb 24, 2015

Okay, I'll try the CLI approach then. Don't think it needs much more discussion. I will experiment a bit with it locally and if works I'll send a PR. Thanks!

@trajano

This comment has been minimized.

Show comment
Hide comment
@trajano

trajano Aug 4, 2015

The CLI approach would be, but not sure where to put it in.

/subsystem=security/security-domain=jaspitest:add(cache-type=default)
/subsystem=security/security-domain=jaspitest/authentication=jaspi:add()
/subsystem=security/security-domain=jaspitest/authentication=jaspi/login-module-stack=dummy:add()
/subsystem=security/security-domain=jaspitest/authentication=jaspi/login-module-stack=dummy/login-module=dummy:add(code=Dummy, flag=optional)
/subsystem=security/security-domain=jaspitest/authentication=jaspi/auth-module=jaspi:add(code=org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule, flag=required)

trajano commented Aug 4, 2015

The CLI approach would be, but not sure where to put it in.

/subsystem=security/security-domain=jaspitest:add(cache-type=default)
/subsystem=security/security-domain=jaspitest/authentication=jaspi:add()
/subsystem=security/security-domain=jaspitest/authentication=jaspi/login-module-stack=dummy:add()
/subsystem=security/security-domain=jaspitest/authentication=jaspi/login-module-stack=dummy/login-module=dummy:add(code=Dummy, flag=optional)
/subsystem=security/security-domain=jaspitest/authentication=jaspi/auth-module=jaspi:add(code=org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule, flag=required)
@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Aug 4, 2015

Contributor

I did a tiny amount of experimenting, but didn't got very far either with the CLI approach yet. It needs to be executed before the test war is deployed.

Another approach where I had more success with is a programmatic option. The code for that needs to be put in a jar and can be put in WEB-INF/lib (via e.g. Maven dependency). I was still contemplating how to handle this best. Publish the jar to Maven central and have the JBoss profile depend on it, or put the code in sub-module of the samples project.

Contributor

arjantijms commented Aug 4, 2015

I did a tiny amount of experimenting, but didn't got very far either with the CLI approach yet. It needs to be executed before the test war is deployed.

Another approach where I had more success with is a programmatic option. The code for that needs to be put in a jar and can be put in WEB-INF/lib (via e.g. Maven dependency). I was still contemplating how to handle this best. Publish the jar to Maven central and have the JBoss profile depend on it, or put the code in sub-module of the samples project.

@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Aug 24, 2015

Contributor

With regards to the programmatic option mentioned in my last comment, I indeed published it to Maven central and wrote a blog article about it here: http://arjan-tijms.omnifaces.org/2015/08/activating-jaspic-in-jboss-wildfly.html

I'll look into adding this as a dependency for the current JASPIC tests to see if everything then runs on a stock JBoss.

Contributor

arjantijms commented Aug 24, 2015

With regards to the programmatic option mentioned in my last comment, I indeed published it to Maven central and wrote a blog article about it here: http://arjan-tijms.omnifaces.org/2015/08/activating-jaspic-in-jboss-wildfly.html

I'll look into adding this as a dependency for the current JASPIC tests to see if everything then runs on a stock JBoss.

@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Jul 8, 2016

Contributor

Since WildFLy 10 and EAP 7.0 the jaspitest domain has been added by default, so this issue can be closed now.

Contributor

arjantijms commented Jul 8, 2016

Since WildFLy 10 and EAP 7.0 the jaspitest domain has been added by default, so this issue can be closed now.

@arjantijms arjantijms closed this Jul 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment