SSO Unit Testing

[julien1]

We need to discuss the unit testing of the various SSO integration we are developping. This topic should be used.

[soshah]

Basically we will need a different unit test environment for different SSO Frameworks being integrated.

Our first framework integration in experimental stage has been CAS.

See here was environment setup details: http://wiki.jboss.org/wiki/Wiki.jsp?page=CASSSOFrameworkIntegration

Here are my initial thoughts on what is needed for testing the CAS integration

1/ A CAS web application instance with the JBoss Portal Authentication Handler integrated as mentioned in the wiki. (This would probably need to be via loading tomcat as a service inside microcontainer)

2/ From Portal standpoint, we probably just need a very simple web application with the CAS Valve installed (loaded along with the CAS server in the microcontainer as well)

3/ We will need to load the JAAS service that takes care of the Portal authentication in the microcontainer as well.

Note: Looks like points 2 and 3 will be common across all SSO integrations while point 1 will vary depending on SSO Framework in question

Thanks

[soshah]

FYI-

The previous post details the setup/test framework environment needed by the SSO test cases.

The SSO test cases themselves need to simulate a browser based user that

1/ Navigates to one instance of the portal (call it Portal 1)

2/ Logs in to the Portal

3/ Supports any SSO orchestration at the browser level that is needed for the SSO Framework in question

4/ Establishes the SSO session on Portal 1

5/ Navigates to a second instance of the portal (call this Portal 2)

6/ And asserts that on Portal 2, authentication is not required and the Subject from Portal 1 is automatically authenticated.


These test cases run at the browser level and should use the http client library to access the Portal

Thanks

[julien1]

can we suppose of course that what you call portal1 and portal2 are plain old war files that are customized to use the correct auth config and a special servlets ?

[soshah]

can we suppose of course that what you call portal1 and portal2 are plain old war files that are customized to use the correct auth config and a special servlets ?

Correct. From an SSO standpoint, there is no difference between a Portal and any other web application.

I have also noticed that we can use a barebones portal which is jboss-portal.sar with only the portal-core.war and portal-server.war files and ofcourse the conf directory and lib directory for configuration and thirdparty dependencies respectively

[julien1]

I would prefer to use a simpler servlet as it decouples the feature from the portal and does not introduce a dependency of the test case on the portal configuration structure.

[soshah]

yeah. that sounds fine.

I will create a very simple servlet based web application that uses the authentication mechanism of Portal and use that to test.

[julien1]

keep in mind you can copy the way that portals deploy the jaas security domain using an mbean and a login-config file, that will help you to avoid to have to modify login-config of app server.

[mwringe]

I have been looking into setting up the test framework for this, and I am a bit confused. The CAS tests are using httpclient and it is going to be setup to use an embedded tomcat instance instead of running it in Portal or the application server.
What is the point of using the microcontainer/microkernel? Wouldn't it make sense to just setup this test and run it with how your normally use cactus?
I think I am missing something here.

[soshah]

the idea with embedded tomcat is to load up the server side requirement of the testcase within the testsuite environment,

Otherwise the serverside portion is always needed and the test cases wouldn't successfully run as part of running the test suite.

Also, in this case cactus will not apply, since cactus is for running the test case on the server.

In this case the test case runs on the client side (simulating the browser performing an SSO session)....embedded tomcat needs to provide the serverside environment needed to run the test cases

Thanks

[mwringe]

Also, in this case cactus will not apply, since cactus is for running the test case on the server.

I meant cargo, not cactus in my last reply, sorry. I would use cargo to setup the embedded server to be used for the tests.

So, does the microcontainer/microkernel not need to be used then? This is my confusion.

[soshah]

The test case uses http as a way to communicate with the serverside environment

so it really does not matter what the system is on the other end.

as long as embedded tomcat can be loaded in memory with the testsuite when the test case is ready to run

Thanks

[mwringe]

yeah. that sounds fine.

I will create a very simple servlet based web application that uses the authentication mechanism of Portal and use that to test.

Is that available anywhere? also what needs to be done to setup the josso tests?

[soshah]

No the simple web application is not done yet. I will be looking into it this week.

However, it would still be a good idea to sometimes be able to run the full server side portal setup inside of Cairo to once in a while do a proper test, so that we don't miss any fringe scenarios, which can pop up with SSO quite a bit.

JOSSO has very similar setup to CAS from deployment standpoint.

Have you gotten the CAS setup to run inside Cairo yet?

Here are the details for the CAS setup.
http://wiki.jboss.org/wiki/Wiki.jsp?page=CASSSOFrameworkIntegration

Thanks

[julien1]

there are 2 things about cargo:

- container life cycle control

- deployment

The portlet and web module use cargo to control an instance of a local container. (in addition of that the test framework has support for using cargo for deployment during the test, but it should not be used here)

In the future I want to migrate part of the sso integration in the web module and provide integrations with other platforms whenever it is possible.

Having the test case directly embed tomcat should not be done. Ant (or maven in the future) should control the life cycle of the container using the cargo start / stop.

Ant has also support for deploying into the container and also for shared classpath.

Here is an example used from the web module:

 <target name="cargo.tomcat-6.start" depends="cargo.setup">
 <cargo
 containerId="tomcat5x"
 home="${test.tomcat-6.home}"
 output="${cargo.log.dir}/cargo.${test.id}.server.log"
 log="${cargo.log.dir}/cargo.${test.id}.start.log"
 action="start"
 wait="${cargo.wait}">
 <sharedClasspath>
 <path location="${apache.log4j.lib}/log4j.jar"/>
 <path location="${oswego.concurrent.lib}/concurrent.jar"/>
 <path location="${jboss.portal/modules/common.lib}/portal-common-lib.jar"/>
 <path location="${sun.jaf.lib}/activation.jar"/>
 <path location="${junit.junit.lib}/junit.jar"/>
 <path location="${build.lib}/portal-web-lib.jar"/>
 </sharedClasspath>
 <configuration>
 <property name="cargo.servlet.port" value="8080"/>
 <property name="cargo.logging" value="high"/>
 <!--<property name="cargo.jvmargs" value="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000"/>-->
 <deployable type="war" file="${codehaus.cargo.lib}/manager.war"/>
 <deployable type="war" file="${test.spi.server.path}"/>
 </configuration>
 </cargo>
 </target>

 <target name="cargo.tomcat-6.stop" depends="cargo.setup">
 <cargo
 containerId="tomcat5x"
 home="${test.tomcat-6.home}"
 log="${cargo.log.dir}/cargo.${test.id}.shutdown.log"
 action="stop">
 <configuration>
 </configuration>
 </cargo>
 </target>

Note the sharedClasspath attribute that is used to load classes visible by tomcat (equivalent to put jar in tomcat lib).

Note also the nested that will deploy the war files once the container has properly been started.