[jboss-cvs] JBossAS SVN: r79298 - in branches/JBPAPP_4_2_0_GA_CP/testsuite: imports and 3 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Oct 9 07:13:01 EDT 2008
Author: pskopek at redhat.com
Date: 2008-10-09 07:13:00 -0400 (Thu, 09 Oct 2008)
New Revision: 79298
Added:
branches/JBPAPP_4_2_0_GA_CP/testsuite/src/main/org/jboss/test/util/CheckSumCalculator.java
Modified:
branches/JBPAPP_4_2_0_GA_CP/testsuite/build.xml
branches/JBPAPP_4_2_0_GA_CP/testsuite/imports/server-config.xml
branches/JBPAPP_4_2_0_GA_CP/testsuite/src/resources/cc/testCaseMapping_1.0.xml
branches/JBPAPP_4_2_0_GA_CP/testsuite/src/stylesheets/junit-frames.xsl
Log:
JBPAPP-1055: Integrate changes to TestSuite for Common Criteria.
Modified: branches/JBPAPP_4_2_0_GA_CP/testsuite/build.xml
===================================================================
--- branches/JBPAPP_4_2_0_GA_CP/testsuite/build.xml 2008-10-09 11:03:35 UTC (rev 79297)
+++ branches/JBPAPP_4_2_0_GA_CP/testsuite/build.xml 2008-10-09 11:13:00 UTC (rev 79298)
@@ -857,18 +857,100 @@
</target>
<import file="imports/cc.xml"/>
-
+
+ <!-- This target creates CC configuration -->
+ <target name="create-cc-config" description="Creates CC configuration">
+ <!-- Create the CC config starting with the pruduction config -->
+ <create-config baseconf="production" newconf="cc" newconf-src="cc">
+ <patternset>
+ <include name="**/*"/>
+ </patternset>
+ </create-config>
+
+ <!-- delete SNMP adapter, because it is not allowed in CC config -->
+ <delete dir="${jboss.dist}/server/cc/deploy/snmp-adaptor.sar"/>
+
+ <!-- copy alternate part of configuration (cc-none, cc-db, cc-ldap) -->
+ <copy todir="${jboss.dist}/server/cc" overwrite="true">
+ <fileset dir="${build.resources}/test-configs/${alternate-config}">
+ <include name="**/*"/>
+ </fileset>
+ </copy>
+
+ <!-- DB config patch (copy JDBC driver library) -->
+ <copy todir="${jboss.dist}/server/cc/lib" overwrite="true" failonerror="false">
+ <fileset dir="/qa/tools/opt/opt/jdbc-drivers">
+ <include name="${jdbc-driver.pattern}"/>
+ </fileset>
+ </copy>
+
+ </target>
+
+ <!-- Calculates MD5 sums for all libraries used while testing.
+ This will be used as proof of testing for CC evaluation.
+ -->
+ <target name="calculate-md5">
+ <mkdir dir="${build.reports}/html"/>
+
+ <java classname="org.jboss.test.util.CheckSumCalculator">
+ <classpath>
+ <pathelement location="${basedir}/output/classes"/>
+ </classpath>
+ <arg line="-base ${jboss.dist}/ -output ${build.reports}/html/allmd5sum.txt -d ${jboss.dist}/lib -d ${jboss.dist}/server/cc/lib"/>
+ </java>
+
+ </target>
+
+ <!-- Common Criteria Evaluation Tests running with Java Security Manager turned on.
+ Using UsersRolesLoginModule login module.
+ -->
+ <target name="tests-cc-sm" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned on. Using UsersRolesLoginModule login module.">
+ <antcall target="tests-cc-sm-generic">
+ <param name="alternate-config" value="cc-none"/>
+ <!-- This parameter controls junitreport to produce CC testify section. -->
+ <param name="cc-testify" value="true"/>
+ </antcall>
+ </target>
+
+ <!-- Common Criteria Evaluation Tests running with Java Security Manager turned on.
+ Using DatabaseServerLoginModule login module.
+ -->
+ <target name="tests-cc-sm-db" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned on. Using DatabaseServerLoginModule login module.">
+ <antcall target="tests-cc-sm-generic">
+ <param name="alternate-config" value="cc-db"/>
+ <!-- This parameter controls junitreport to produce CC testify section. -->
+ <param name="cc-testify" value="true"/>
+ </antcall>
+ </target>
+
+ <!-- Common Criteria Evaluation Tests running with Java Security Manager turned on.
+ Using LdapLoginModule login module.
+ -->
+ <target name="tests-cc-sm-ldap" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned on. Using LdapLoginModule login module.">
+ <antcall target="tests-cc-sm-generic">
+ <param name="alternate-config" value="cc-ldap"/>
+ <!-- This parameter controls junitreport to produce CC testify section. -->
+ <param name="cc-testify" value="true"/>
+ </antcall>
+ </target>
+
<!-- Common Criteria Evaluation Tests running with Java Security Manager turned on.
-->
- <target name="tests-cc-sm" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned on."
+ <target name="tests-cc-sm-generic" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned on."
depends="generate-cc-patternsets,maybejars">
<record name="${basedir}/build.log" append="no" action="start" loglevel="${buildlog.level}"/>
+
+ <antcall target="create-cc-config">
+ <param name="alternate-config" value="${alternate-config}"/>
+ </antcall>
+
+ <antcall target="calculate-md5"/>
<property name="nojars" value="true"/>
<server:start name="cc-sm"/>
- <antcall target="run-cc-tests-sm"/>
+ <!-- <antcall target="run-cc-tests-sm"/> -->
<antcall target="run-cc-tests"/>
<antcall target="tests-report"/>
@@ -879,29 +961,60 @@
<record name="${basedir}/build.log" action="stop"/>
</target>
-
+
+
+ <!-- Common Criteria Evaluation Tests running with Java Security Manager turned off.
+ Using UsersRolesLoginModule login module.
+ -->
+ <target name="tests-cc" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned off. Using UsersRolesLoginModule login module.">
+ <antcall target="tests-cc-generic">
+ <param name="alternate-config" value="cc-none"/>
+ <!-- This parameter controls junitreport to produce CC testify section. -->
+ <param name="cc-testify" value="true"/>
+ </antcall>
+ </target>
+
+ <!-- Common Criteria Evaluation Tests running with Java Security Manager turned off.
+ Using DatabaseServerLoginModule login module.
+ -->
+ <target name="tests-cc-db" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned off. Using DatabaseServerLoginModule login module.">
+ <antcall target="tests-cc-generic">
+ <param name="alternate-config" value="cc-db"/>
+ <!-- This parameter controls junitreport to produce CC testify section. -->
+ <param name="cc-testify" value="true"/>
+ </antcall>
+ </target>
+
+ <!-- Common Criteria Evaluation Tests running with Java Security Manager turned off.
+ Using LdapLoginModule login module.
+ -->
+ <target name="tests-cc-ldap" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned off. Using LdapLoginModule login module.">
+ <antcall target="tests-cc-generic">
+ <param name="alternate-config" value="cc-ldap"/>
+ <!-- This parameter controls junitreport to produce CC testify section. -->
+ <param name="cc-testify" value="true"/>
+ </antcall>
+ </target>
+
<!-- Common Criteria Evaluation Tests running with Java Security Manager turned off.
-->
- <target name="tests-cc" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned off."
+ <target name="tests-cc-generic" description="Execute all Common Criteria Evaluation tests with Java Security Manager turned off."
depends="generate-cc-patternsets,maybejars">
<record name="${basedir}/build.log" append="no" action="start" loglevel="${buildlog.level}"/>
- <!-- Create the sso enabled tomcat config starting with the default config -->
- <create-config baseconf="all" newconf="cc" newconf-src="cc">
- <patternset>
- <include name="conf/**"/>
- <include name="deploy/**"/>
- </patternset>
- </create-config>
+ <antcall target="create-cc-config">
+ <param name="alternate-config" value="${alternate-config}"/>
+ </antcall>
+ <antcall target="calculate-md5"/>
<property name="nojars" value="true"/>
<server:start name="cc"/>
<antcall target="run-cc-tests"/>
- <antcall target="tests-report"/>
+ <antcall target="tests-report"/>
<echo>Waiting for server to shutdown...</echo>
<server:stop name="cc"/>
@@ -919,26 +1032,6 @@
<antcall target="tests-cc-unit"/>
- <!--
- <antcall target="tests-standard-unit"/>
- <antcall target="tests-security-basic-unit"/>
- -->
-
- <!--
- <antcall target="tomcat-ssl-tests"/>
- -->
- <!-- not sure about single sign on, be carefull starts own JBoss config
- <antcall target="tomcat-sso-tests"/>
- -->
- <!--
- <antcall target="tests-standard-stress"/>
- <antcall target="tests-jbossmx-compliance"/>
- <antcall target="tests-jbossmx-implementation"/>
- <antcall target="tests-jbossmx-performance"/>
- <antcall target="tests-iiop"/>
- <antcall target="tests-scout-jaxr"/>
- <antcall target="tests-webservice"/>
- -->
</target>
<!-- Collection of CC related tests.
Modified: branches/JBPAPP_4_2_0_GA_CP/testsuite/imports/server-config.xml
===================================================================
--- branches/JBPAPP_4_2_0_GA_CP/testsuite/imports/server-config.xml 2008-10-09 11:03:35 UTC (rev 79297)
+++ branches/JBPAPP_4_2_0_GA_CP/testsuite/imports/server-config.xml 2008-10-09 11:13:00 UTC (rev 79298)
@@ -343,7 +343,7 @@
<jvmarg value="-Djboss.test.deploy.dir=${jboss.test.deploy.dir}" />
<jvmarg value="-Djava.security.manager"/>
<jvmarg value="-Djava.security.policy==${jboss.dist}/bin/security_cc.policy"/>
- <jvmarg value="-Djava.security.debug=access,failure"/>
+ <jvmarg value="-Djava.security.debug=access:failure"/>
<sysproperty key="java.endorsed.dirs" value="${jboss.dist}/lib/endorsed" />
<sysproperty key="jgroups.udp.ip_ttl" value="${jbosstest.udp.ip_ttl}" />
</server>
Added: branches/JBPAPP_4_2_0_GA_CP/testsuite/src/main/org/jboss/test/util/CheckSumCalculator.java
===================================================================
--- branches/JBPAPP_4_2_0_GA_CP/testsuite/src/main/org/jboss/test/util/CheckSumCalculator.java (rev 0)
+++ branches/JBPAPP_4_2_0_GA_CP/testsuite/src/main/org/jboss/test/util/CheckSumCalculator.java 2008-10-09 11:13:00 UTC (rev 79298)
@@ -0,0 +1,185 @@
+package org.jboss.test.util;
+
+import java.io.BufferedInputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.io.PrintWriter;
+import java.security.MessageDigest;
+import java.security.NoSuchAlgorithmException;
+import java.util.Iterator;
+import java.util.LinkedList;
+
+/**
+ * This utility class calculates check sum of files specified. It is used for
+ * Common Criteria certification testify section produced by junit reports.
+ *
+ * Called from build.xml as using <java .. > ant task.
+ *
+ * @author pskopek at redhat.com
+ */
+public class CheckSumCalculator {
+
+ class DirSpec {
+ public String dirPath;
+ public String fileNameSuffix;
+ }
+
+
+ private LinkedList dirSpecs = new LinkedList();
+ private String outputFileName = "MD5SUM";
+ private String base = "";
+
+ /**
+ * @param args
+ */
+ public static void main(String[] args) {
+ CheckSumCalculator csc = new CheckSumCalculator();
+ csc.parseArguments(args);
+ try {
+ csc.calculate();
+ }
+ catch (IOException e) {
+ throw new RuntimeException(e);
+ }
+ }
+
+ public CheckSumCalculator() {
+ }
+
+ public void parseArguments(String args[]) {
+
+ boolean isDirectory = false;
+ boolean isOutput = false;
+ boolean isSuffix = false;
+ boolean isBase = false;
+
+ for (int i = 0; i < args.length; i++) {
+ if (args[i].equals("-d")) {
+ isDirectory = true;
+ }
+ else if (args[i].equals("-output")) {
+ isOutput = true;
+ }
+ else if (args[i].equals("-s")) {
+ isSuffix = true;
+ }
+ else if (args[i].equals("-base")) {
+ isBase = true;
+ }
+ else {
+
+ if (isDirectory) {
+ DirSpec ds = new DirSpec();
+ ds.dirPath = args[i].trim();
+ ds.fileNameSuffix = ".jar";
+
+ dirSpecs.add(ds);
+ }
+ else if (isSuffix) {
+ ((DirSpec)dirSpecs.getLast()).fileNameSuffix = args[i].trim();
+ }
+ else if (isOutput) {
+ outputFileName = args[i].trim();
+ }
+ else if (isBase) {
+ base = args[i].trim();
+ }
+
+ isDirectory = false;
+ isSuffix = false;
+ isOutput = false;
+ isBase = false;
+ }
+
+
+ }
+ }
+
+ public void calculate() throws IOException {
+
+ PrintWriter pw = new PrintWriter(outputFileName);
+
+ Iterator dsIterator = dirSpecs.iterator();
+ while (dsIterator.hasNext()) {
+ DirSpec ds = (DirSpec)dsIterator.next();
+
+ calculateDirectory(ds, pw);
+
+ }
+
+ pw.close();
+
+
+ }
+
+
+ private void calculateDirectory(DirSpec ds, PrintWriter pw) throws IOException {
+
+ File dir = new File(ds.dirPath);
+
+ File[] content = dir.listFiles();
+ for (int i = 0; i < content.length; i++) {
+ if (content[i].isDirectory()) {
+ DirSpec innerDir = new DirSpec();
+ innerDir.dirPath = content[i].getCanonicalPath();
+ innerDir.fileNameSuffix = ds.fileNameSuffix;
+ calculateDirectory(innerDir, pw);
+ }
+ else if (content[i].isFile() && content[i].getName().endsWith(ds.fileNameSuffix)) {
+ pw.print(calculateFileCheckSum(content[i]));
+ pw.print(" ");
+
+ String canonicalPath = content[i].getCanonicalPath();
+ if (canonicalPath.startsWith(base)) {
+ canonicalPath = canonicalPath.substring(base.length());
+ }
+ pw.println(canonicalPath);
+
+ }
+ }
+
+ }
+
+
+ private String calculateFileCheckSum(File f) throws IOException {
+
+ BufferedInputStream in = new BufferedInputStream(new FileInputStream(f));
+
+ byte[] buf = new byte[2048];
+
+ MessageDigest md;
+ try {
+ md = MessageDigest.getInstance("MD5");
+ }
+ catch (NoSuchAlgorithmException e) {
+ throw new IllegalArgumentException(e);
+ }
+
+ int len;
+ while ((len = in.read(buf, 0, buf.length)) > -1) {
+ md.update(buf, 0, len);
+ }
+ in.close();
+
+ return CheckSumCalculator.convertToHex(md.digest());
+
+
+ }
+
+ private static String convertToHex(byte[] data) {
+ StringBuffer buf = new StringBuffer();
+ for (int i = 0; i < data.length; i++) {
+ int halfbyte = (data[i] >>> 4) & 0x0F;
+ int two_halfs = 0;
+ do {
+ if ((0 <= halfbyte) && (halfbyte <= 9))
+ buf.append((char) ('0' + halfbyte));
+ else
+ buf.append((char) ('a' + (halfbyte - 10)));
+ halfbyte = data[i] & 0x0F;
+ } while(two_halfs++ < 1);
+ }
+ return buf.toString();
+ }
+}
Modified: branches/JBPAPP_4_2_0_GA_CP/testsuite/src/resources/cc/testCaseMapping_1.0.xml
===================================================================
--- branches/JBPAPP_4_2_0_GA_CP/testsuite/src/resources/cc/testCaseMapping_1.0.xml 2008-10-09 11:03:35 UTC (rev 79297)
+++ branches/JBPAPP_4_2_0_GA_CP/testsuite/src/resources/cc/testCaseMapping_1.0.xml 2008-10-09 11:13:00 UTC (rev 79298)
@@ -13,6 +13,8 @@
tsfi.jms - JMS traffic
+ tsfi.jts.api - JBossTS API
+
tsfi.ws.http - Web Services over HTTP
tsfi.ws.https - Web Services over HTTPS
@@ -63,7 +65,7 @@
</test>
</testCase>
<testCase name="org.jboss.ejb3.test.security.unit.EJBSpecUnitTestCase">
- <desc>Test of EJB spec conformace using the security-spec.jar deployment unit. These test the basic role based access model.</desc>
+ <desc>Test of EJB spec conformance using the security-spec.jar deployment unit. These test the basic role based access model. These tests incorporate the use of the javax.annotation.security annotations: PermitAll, DeclareRoles, RolesAllowed, DenyAll, RunAs and org.jboss.annotation.security SecurityDomain</desc>
<test name="testSecurityDomain">
<desc>Validate that the users have the expected logins and roles.</desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
@@ -198,6 +200,32 @@
<TSFI>tsfi.rmi.http</TSFI>
</test>
</testCase>
+ <testCase name="org.jboss.ejb3.test.security.unit.ServletUnitTestCase">
+ <desc>Tests of servlet container integration into the JBoss server. This test
+ requires than a web container be integrated into the JBoss server. The tests
+ currently do NOT use the java.net.HttpURLConnection and associated http client
+ and these do not return valid HTTP error codes so if a failure occurs it
+ is best to connect the webserver using a browser to look for additional error
+ info.
+
+ The secure access tests require a user named 'jduke' with a password of 'theduke'
+ with a role of 'AuthorizedUser' in the servlet container.</desc>
+ <test name="testEJBServlet">
+ <desc></desc>
+ <TSFI>tsfi.http</TSFI>
+ </test>
+ </testCase>
+ <testCase name="org.jboss.test.security.test.ClientLoginModuleEJBUnitTestCase">
+ <desc>Call BeanA using jduke/theduke
+ +-- call BeanB switching idenity using ClientLoginModule
+ +---- call BeanC switching idenity using ClientLoginModule
+ validing the expected caller principal with different ejb method permissions</desc>
+ <test name="testClientLoginModule">
+ <desc></desc>
+ <TSFI>???jnp.. isn't it disabled?</TSFI>
+ </test>
+ </testCase>
+
<testCase name="">
<desc></desc>
<test name="">
@@ -212,177 +240,240 @@
<testCase name="org.jboss.test.security.test.CallerInfoUnitTestCase">
<desc>Tests of the caller context state</desc>
<test name="testCallerSubject">
- <desc>Test return of a custom principal from getCallerPrincipal.</desc>
- <TSFI>???jnp.. isn't it disabled?</TSFI>
+ <desc>Test Objective: Test return of a custom principal from getCallerPrincipal.
+ Call a method on the ejb/StatelessSession, ejb/StatefulSession, ejb/Entity
+ ejb-refs and validate that the security context seen after each call
+ matches the expected context seen at the start of the call.
+ Expected Result: Security context after each call type must contain expected principal pushed to the custom princials
+ before the call.
+ </desc>
+ <TSFI>tsfi.rmi.jrmp</TSFI>
</test>
</testCase>
<testCase name="org.jboss.test.security.test.SubjectContextUnitTestCase">
- <desc></desc>
+ <desc>Tests of the JACC subject policy context handler state and consistency with the container caller principal, isCallerInRole methods.</desc>
<test name="testUserMethodViaServlet">
- <desc></desc>
+ <desc>Test Objective: Test if calling userMethod via servlet has caller principal equal to one we called the method with.
+ Test if caller has proper roles assigned.
+ Tests if policy subject contains proper roles.
+ Tests if run as identity works for subsequent call to session bean.
+ Expected Result: Run without exceptions and http request finishes with HTTP_OK status.
+ </desc>
<TSFI>tsfi.http</TSFI>
</test>
</testCase>
<testCase name="org.jboss.test.security.test.DeepCopySubjectUnitTestCase">
<desc>JBAS-2657: Add option to deep copy the authenticated subject sets
- *
- * Testcase that unit tests the cloneability of various JBossSX
- * Principal/Groups
- * Also does a test of the serverside Subject deep copy via a mutable
- * Principal</desc>
+
+ Testcase that unit tests the cloneability of various JBossSX
+ Principal/Groups
+ Also does a test of the serverside Subject deep copy via a mutable
+ Principal</desc>
<test name="testSubjectCloning">
- <desc>Test the Deep Copy of Subjects by the JaasSecurityManager via a test servlet deployed</desc>
+ <desc>Test Objective: Test the Deep Copy of Subjects by the JaasSecurityManager via a test servlet deployed.
+ Expected Result: Run without exceptions and with proper HTTP result after each of three different calls.
+ </desc>
<TSFI>tsfi.http</TSFI>
</test>
</testCase>
<testCase name="org.jboss.test.security.test.EJBSpecUnitTestCase">
<desc>Test of EJB spec conformace using the security-spec.jar deployment unit. These test the basic role based access model.</desc>
<test name="testSecurityDomain">
- <desc>Validate that the users have the expected logins and roles.</desc>
- <TSFI>tsfi.jmx</TSFI>
+ <desc>Test Objective: Validate that the users have the expected logins and roles.
+ Tests following if user has correct password, correct role, user cannot call method using bad password.
+ Tests same cases for use with different security domain.
+ Expected Result: All assertions after call has to be fulfilled and there is no exception thrown during execution.
+ </desc>
+ <TSFI>tsfi.jmx.rmi</TSFI>
</test>
<test name="testStatefulCreateCaller">
- <desc>Test the use of getCallerPrincipal from within the ejbCreate in a stateful session bean</desc>
- <TSFI>???jnp.. isn't it disabled?</TSFI>
+ <desc>Test Objective: Test the use of getCallerPrincipal from within the ejbCreate in a stateful session bean.
+ Expected Result: Finish the test without exceptions indicating successful use of getCallerPrincipal.
+ </desc>
+ <TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testGetCallerPrincipal">
- <desc>Test that:
+ <desc>Test Objective:
1. SecureBean returns a non-null principal when getCallerPrincipal
- is called with a security context and that this is propagated
- to its Entity bean ref.
+ is called with a security context and that this is propagated
+ to its Entity bean ref.
2. UnsecureBean throws an IllegalStateException when getCallerPrincipal
- is called without a security context.</desc>
- <TSFI>???jnp.. isn't it disabled?</TSFI>
+ is called without a security context.
+ Expected Result: 1. Return caller principal which is equal to the one of callee.
+ 2. Throw RemoteException on unsecured session bean which.
+ </desc>
+ <TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testDomainInteraction">
- <desc>Test that a call interacting with different security domains does not change the</desc>
+ <desc>Test Objective: Test that a call interacting with different security domains does not change the roles it had before the call.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testPrincipalPropagation">
- <desc>Test that the calling principal is propagated across bean calls.</desc>
+ <desc>Test Objective: Test that the calling principal is propagated across bean calls.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testMethodAccess">
- <desc>Test that the echo method is accessible by an Echo
- role. Since the noop() method of the StatelessSession
- bean was not assigned any permissions it should be unchecked.</desc>
+ <desc>Test Objective: Test that the echo method is accessible by an Echo
+ role. Since the noop() method of the StatelessSession
+ bean was not assigned any permissions it should be unchecked.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testDomainMethodAccess">
- <desc>Test that the echo method is accessible by an Echo
- role. Since the excluded() method of the StatelessSession
- bean has been placed into the excluded set it should not
- accessible by any user. This uses the security domain of the
- JaasSecurityDomain service to test its use as an authentication mgr.</desc>
+ <desc>Test Objective: Test that the echo method is accessible by an Echo
+ role. Since the excluded() method of the StatelessSession
+ bean has been placed into the excluded set it should not
+ accessible by any user. This uses the security domain of the
+ JaasSecurityDomain service to test its use as an authentication mgr.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testMethodAccess2">
- <desc>Test that the permissions assigned to the stateless session bean:
- with ejb-name=org/jboss/test/security/ejb/StatelessSession_test
- are read correctly.</desc>
+ <desc>Test Objective: Test that the permissions assigned to the stateless session bean:
+ with ejb-name=org/jboss/test/security/ejb/StatelessSession_test
+ are read correctly.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testLocalMethodAccess">
- <desc>Test a user with Echo and EchoLocal roles can access the CalleeBean
- through its local interface by calling the CallerBean and that a user
- with only a EchoLocal cannot call the CallerBean.</desc>
+ <desc>Test Objective: Test a user with Echo and EchoLocal roles can access the CalleeBean
+ through its local interface by calling the CallerBean and that a user
+ with only a EchoLocal cannot call the CallerBean.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testUncheckedRemote">
- <desc>Test access to a bean with a mix of remote interface permissions and
- * unchecked permissions with the unchecked permissions declared first.</desc>
+ <desc>Test Objective: Test access to a bean with a mix of remote interface permissions and unchecked permissions with the unchecked permissions declared first.
+ Expected Result: Unchecked remoote access has to pass without exception and exluded() method call should throw RemoteException.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testRemoteUnchecked">
- <desc>Test access to a bean with a mix of remote interface permissions and
- * unchecked permissions with the unchecked permissions declared last.</desc>
+ <desc>Test Objective: Test access to a bean with a mix of remote interface permissions and unchecked permissions with the unchecked permissions declared last.
+ Expected Result: Unchecked remoote access has to pass without exception and exluded() method call should throw RemoteException.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testUnchecked">
- <desc>Test that a user with a role that has not been assigned any
- method permissions in the ejb-jar descriptor is able to access a
- method that has been marked as unchecked.</desc>
+ <desc>Test Objective: Test that a user with a role that has not been assigned any
+ method permissions in the ejb-jar descriptor is able to access a
+ method that has been marked as unchecked.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testUncheckedWithLogin">
- <desc>Test that a user with a valid role is able to access a
- bean for which all methods have been marked as unchecked.</desc>
+ <desc>Test Objective: Test that a user with a valid role is able to access a
+ bean for which all methods have been marked as unchecked.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testExcluded">
- <desc>Test that user scott who has the Echo role is not able to
- access the StatelessSession2.excluded method even though
- the Echo role has been granted access to all methods of
- StatelessSession2 to test that the excluded-list takes
- precendence over the method-permissions.</desc>
+ <desc>Test Objective: Test that user scott who has the Echo role is not able to
+ access the StatelessSession2.excluded method even though
+ the Echo role has been granted access to all methods of
+ StatelessSession2 to test that the excluded-list takes
+ precendence over the method-permissions.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testRunAs">
- <desc>This method tests the following call chains:
- 1. RunAsStatelessSession.echo() -> PrivateEntity.echo()
- 2. RunAsStatelessSession.noop() -> RunAsStatelessSession.excluded()
- 3. RunAsStatelessSession.forward() -> StatelessSession.echo()
- 1. Should succeed because the run-as identity of RunAsStatelessSession
- is valid for accessing PrivateEntity.
- 2. Should succeed because the run-as identity of RunAsStatelessSession
- is valid for accessing RunAsStatelessSession.excluded().
- 3. Should fail because the run-as identity of RunAsStatelessSession
- is not Echo.</desc>
+ <desc>Test Objective: This method tests the following call chains:
+ 1. RunAsStatelessSession.echo() -> PrivateEntity.echo()
+ 2. RunAsStatelessSession.noop() -> RunAsStatelessSession.excluded()
+ 3. RunAsStatelessSession.forward() -> StatelessSession.echo()
+ Expected Result: 1. Should succeed because the run-as identity of RunAsStatelessSession
+ is valid for accessing PrivateEntity.
+ 2. Should succeed because the run-as identity of RunAsStatelessSession
+ is valid for accessing RunAsStatelessSession.excluded().
+ 3. Should fail because the run-as identity of RunAsStatelessSession is not Echo.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testDeepRunAs">
- <desc>This method tests the following call chain:
- Level1CallerBean.callEcho() -> Level2CallerBean.invokeEcho()
- -> Level3CalleeBean.echo()
- The Level1CallerBean uses a run-as of InternalRole and the Level2CallerBean
- and Level3CalleeBean are only accessible by InternalRole.</desc>
+ <desc>Test Objective: This method tests the following call chain:
+ Level1CallerBean.callEcho() -> Level2CallerBean.invokeEcho() -> Level3CalleeBean.echo()
+ The Level1CallerBean uses a run-as of InternalRole and the Level2CallerBean
+ and Level3CalleeBean are only accessible by InternalRole.
+ Expected Result: Test has to finished without any exception.
+ Test makes sure we cannot access Level2CallerBean remotely, therefore the call have to throw an Exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testRunAsSFSB">
- <desc></desc>
+ <desc>Test Objective: Test RunAs for proper role propagation on stateful session beans.
+ Expected Result: Test should finish without any exceptions thrown.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testJBAS1852">
- <desc>Test the run-as side-effects raised in http://jira.jboss.com/jira/browse/JBAS-1852</desc>
+ <desc>Test Objective: Test the run-as side-effects raised in http://jira.jboss.com/jira/browse/JBAS-1852
+ (Unexpected Principal (Security Identity) Propagation Switch).
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testMDBRunAs">
- <desc>Test that an MDB with a run-as identity is able to access secure EJBs
- that require the identity.</desc>
+ <desc>Test Objective: Test that an MDB with a run-as identity is able to access secure EJBs that require the identity.
+ Expected Result: Message sent to QueueA has to come through to QueueB with not set to Failed.
+ </desc>
<TSFI>tsfi.jms</TSFI>
+ <TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testMDBDeepRunAs">
- <desc>Test that an MDB with a run-as identity is able to access secure EJBs
- that require the identity. DeepRunAsMDB -> Level1MDBCallerBean.callEcho() ->
- Level2CallerBean.invokeEcho() -> Level3CalleeBean.echo()
- The MDB uses a run-as of InternalRole and the Level2CallerBean
- and Level3CalleeBean are only accessible by InternalRole.</desc>
+ <desc>Test Objective: Test that an MDB with a run-as identity is able to access secure EJBs
+ that require the identity. DeepRunAsMDB -> Level1MDBCallerBean.callEcho() ->
+ Level2CallerBean.invokeEcho() -> Level3CalleeBean.echo()
+ The MDB uses a run-as of InternalRole and the Level2CallerBean
+ and Level3CalleeBean are only accessible by InternalRole.
+ Expected Result: Message sent to QueueD has to come through to QueueB with not set to Failed.
+ </desc>
<TSFI>tsfi.jms</TSFI>
+ <TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testRunAsWithRoles">
- <desc>This method tests that the RunAsWithRolesMDB is assigned multiple roles
- * within its onMessage so that it can call into the ProjRepository session
- * bean's methods that required ProjectAdmin, CreateFolder and DeleteFolder
- * roles.</desc>
+ <desc>Test Objective: This method tests that the RunAsWithRolesMDB is assigned multiple roles
+ within its onMessage so that it can call into the ProjRepository session
+ bean's methods that required ProjectAdmin, CreateFolder and DeleteFolder roles.
+ Expected Result: Message sent to QueueD has to come through to QueueB with not set to Failed.
+ </desc>
<TSFI>tsfi.jms</TSFI>
+ <TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testHandle">
- <desc>Test the security behavior of handles. To obtain secured bean from
- a handle that the handle be </desc>
+ <desc>Test Objective: Test the security behavior of handles. To obtain secured bean from a handle that the handle be logged in and not logged in.
+ Expected Result: Tests has to pass sections when logged in and throw the exception when not logged in.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testStatefulHandle">
- <desc>Test the security behavior of stateful handles. To obtain secured bean
- from a handle requires that there be a security context to obtain the ejb.</desc>
+ <desc>Test Objective: Test the security behavior of stateful handles. To obtain secured bean
+ from a handle requires that there be a security context to obtain the ejb.
+ Expected Result: Tests has to pass sections when logged in and throw the exception when not logged in.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testStress">
- <desc>Stress test declarative security.</desc>
+ <desc>Test Objective: Stress test declarative security. Using number of threads.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testStressNoJaasCache">
- <desc>Stress test declarative security with the JAAS cache disabled.</desc>
+ <desc>Test Objective: Stress test declarative security with the JAAS cache disabled. Using testStress test.
+ Expected Result: Test has to finish without any exception.
+ </desc>
<TSFI>tsfi.jmx.rmi</TSFI>
</test>
</testCase>
@@ -510,6 +601,7 @@
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
</testCase>
+<!--
<testCase name="org.jboss.test.jca.test.SecurityContextUnitTestCase">
<desc>Tests of how security context interact with the JCA layer.</desc>
<test name="testCallerIdentityPropagation">
@@ -529,6 +621,7 @@
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
</testCase>
+-->
<testCase name="org.jboss.test.jmx.test.RMIAdaptorAuthorizationUnitTestCase">
<desc>Authorization of the RMI Adaptor
* Especially tests the usage of the authorization delegate
@@ -561,21 +654,6 @@
<TSFI>tsfi.https</TSFI>
</test>
</testCase>
- <testCase name="org.jboss.ejb3.test.security.unit.ServletUnitTestCase">
- <desc>Tests of servlet container integration into the JBoss server. This test
- requires than a web container be integrated into the JBoss server. The tests
- currently do NOT use the java.net.HttpURLConnection and associated http client
- and these do not return valid HTTP error codes so if a failure occurs it
- is best to connect the webserver using a browser to look for additional error
- info.
-
- The secure access tests require a user named 'jduke' with a password of 'theduke'
- with a role of 'AuthorizedUser' in the servlet container.</desc>
- <test name="testEJBServlet">
- <desc></desc>
- <TSFI>tsfi.http</TSFI>
- </test>
- </testCase>
<testCase name="org.jboss.test.security.test.ClientLoginModuleEJBUnitTestCase">
<desc>Call BeanA using jduke/theduke
+-- call BeanB switching idenity using ClientLoginModule
@@ -833,6 +911,7 @@
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
</testCase>
+ <!--
<testCase name="org.jboss.test.security.test.SRPLoginModuleUnitTestCase">
<desc>Test of the secure remote password(SRP) service and its usage via JAAS
login modules.</desc>
@@ -870,7 +949,8 @@
multiple sessions for the same user. This creates two threads</desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
- </testCase>
+ </testCase>
+ -->
<testCase name="SRPUnitTestCase">
<desc>Test of the secure remote password(SRP) session key to perform crypto
operations.</desc>
@@ -1762,42 +1842,242 @@
<!-- JBoss (TOE) has passed J2EE TCK 1.4, so some testcases from there are also picked up -->
<testSuite name="CTS">
- <testCase name="J2EE">
- <desc>J2EETM 1.4 Platform assertions</desc>
- <test name="J2EE:SPEC:21">
- <desc> All J2EE products are required to support three login mechanisms: HTTP basic authentication, SSL mutual authentication, and form-based login. An application is not required to use any of these mechanisms, but they are required to be available for any application's use.</desc>
- <TSFI>tsfi.http</TSFI>
+ <testCase name="com.sun.ts.tests.ejb.ee.timer.entity.cmp20.Client">
+ <desc>EJB:SPEC:864, 864.1, 864.2 If the Bean Provider invokes the setRollbackOnly method from within the ejbTimeout method, the container must rollback the transaction in which the ejbTimeout method is invoked. The container must retry the timeout after the transaction rollback. </desc>
+ <test name="rollbackTxInEjbTimeoutIntervalTest">
+ <desc>Create a container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an interval timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, long, Serializable) </desc>
+ <TSFI>tsfi.jts.api</TSFI>
</test>
- <test name="J2EE:SPEC:22">
- <desc>All J2EE products are required to support HTTP basic authentication (RFC2068). Platform Providers are also required to support basic authentication over SSL.</desc>
- <TSFI>tsfi.http</TSFI>
- <TSFI>tsfi.https</TSFI>
+ <test name="rollbackTxInEjbTimeoutSingleEventTest">
+ <desc>Create a container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an single-event timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, Serializable)</desc>
+ <TSFI>tsfi.jts.api</TSFI>
</test>
- <test name="J2EE:SPEC:25">
- <desc>Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet. A web container reports that no user has been authenticated by returning null from the HttpServletRequest method getUserPrincipal. This is different than the corresponding result for EJB containers. The EJB specification requires that the EJBContext method getCallerPrincipal always return a valid Principal object. The method can never return null. Components running in a web container must be able to call enterprise beans even when no user has been authenticated in the web container. When a call is made in such a case from a component in a web container to an enterprise bean, a J2EE product must provide a principal for use in the call. A J2EE product may provide a principal for use by unauthenticated callers using many approaches, including, but not limited to: Alw!
ays use a single distinguished principal. Use a different distinguished principal per server, or per session, or per application. Allow the deployer or system administrator to choose which principal to use through the Run As capability of the web and enterprise bean containers. </desc>
- <TSFI>tsfi.http</TSFI>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.timer.mdb.Client">
+ <desc>EJB:SPEC:864, 864.1, 864.2 If the Bean Provider invokes the setRollbackOnly method from within the ejbTimeout method, the container must rollback the transaction in which the ejbTimeout method is invoked. The container must retry the timeout after the transaction rollback. </desc>
+ <test name="rollbackTxInEjbTimeoutSingleEventTest">
+ <desc>Create a message-driven container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an single-event timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, Serializable)</desc>
+ <TSFI>tsfi.jts.api</TSFI>
</test>
- <test name="J2EE:SPEC:27">
- <desc>A Product Provider must support both of the following: 1. Configured Identity.AJ2EE container must be able to authenticate for access to the resource using a principal and authentication data specified by a Deployer at deployment time.The authentication must not depend in any way on data provided by the application components. Providing for the confidential storage of the authentication information is the responsibility of the Product Provider. 2. Programmatic Authentication. The J2EE product must provide for specification of the principal and authentication data for a resource by the application component at runtime using appropriate APIs. The application may obtain the principal and authentication data through a variety of mechanisms, including receiving them as parameters, obtaining them from the component's environment, and so forth.</desc>
- <TSFI>tsfi.http</TSFI>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.timer.session.stateless.bm.Client">
+ <desc>EJB:SPEC:849 If an enterprise bean cancels a timer within a transaction, and if the transaction is rolled back, the container rescinds the timer cancellation. </desc>
+ <test name="cancelAndRollbackSingleEventTest">
+ <desc> Create a bean implementing the TimedObject interface.
+ In the ejbTimeout method, send a JMS message.
+ Create a single-event timer within a transaction
+ context.
+ In a separate transaction, cancel the timer and
+ roll back the transaction.
+ Access the timer and verify that no exception is
+ thrown.
+ In the application client, block on a JMS receive
+ for a period longer than the timer's duration.
+ Verify that the message is received.
+ API tested:
+ TimerService.createTimer(long, Serializable)
+ Timer.getHandle()
+ TimerHandle.getTimer()
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
</test>
- <test name="J2EE:SPEC:30">
- <desc> Caller Authorization A J2EE product must enforce the access control rules specified at deployment time (see Section J2EE.3.6, Deployment Requirements) and more fully described in the EJB and servlet specifications.</desc>
+</testCase>
+ <testCase name="com.sun.ts.tests.ejb.ee.timer.session.stateless.cm.Client">
+ <desc>EJB:SPEC:848 If an enterprise bean creates a timer within a transaction, and if the transaction is rolled back, the timer creation is rolled back.</desc>
+ <test name="rollbackTxOnCreationSingleEventTest">
+ <desc>Create a container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an single-event timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, Serializable)</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.entity.cmp.cm.Tx_SetRollbackOnly.Client">
+ <desc>EJB:SPEC:589 When the EJBContext.setRollbackOnly() method is invoked from a business method executing with the Required, RequiresNew, or Mandatory transaction attribute, the Container must ensure that the transaction will never commit. </desc>
+ <test name="test1">
+ <desc>setRollbackOnly with EJB - Required
+ Create an instance of a stateful session Testbean bean.
+ Create an instance of a stateful session TxECMPBean (Required) bean.
+ Perform a delete row operation to a table
+ and force a rollback via EJBContext.setRollbackOnly().
+ Ensure the EJBContext.getRollbackOnly() status returns true.
+ Ensure the transaction is rolledback.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="test5">
+ <desc>setRollbackOnly with EJB - Mandatory
+ Create an instance of a stateful session Testbean bean.
+ Create an instance of a stateful session TxECMPBean (Mandatory) bean.
+ Mark a transaction involving an entity EJB for rollback, in a Mandatory case
+ Verify that and TransactionRequiredException is thrown due to the fact that the call to create was not in a transaction.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="test8">
+ <desc>setRollbackOnly with EJB - RequiresNew
+ Create an instance of a stateful session Testbean bean.
+ Create an instance of a stateful session TxECMPBean (RequiresNew) bean.
+ Perform a delete row operation to a table
+ and force a rollback via EJBContext.setRollbackOnly().
+ Ensure the EJBContext.getRollbackOnly() status returns true.
+ Ensure the transaction is rolledback.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxM_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_MANDATORY) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxBM_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_BEAN_MANAGED) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxS_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_SUPPORTS) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxRN_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_REQUIRESNEW) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxR_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_REQUIRES) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.pm.ejbql.tx.Client">
+ <desc>The Container is responsible for ensuring that updates to the states of all entity beans in the same transaction context as the ejbFindMETHOD method are visible in the results of the ejbFindMETHOD method. Before invoking the ejbFindMETHOD method, the container must therefore first synchronize the state of any entity bean instances that are participating in the same transaction context as it is used to execute the ejbFindMETHOD method by invoking ejbStore() method on those entity bean instances.</desc>
+ <test name="txTest2">
+ <desc>Create an instance of a CMP 2.0 entity bean. Begin a transaction with the transaction attribute set to Required. Update the data and ensure that the update is visible within the transaction context by invoking a finder method with associated EJB-QL. Rollback the transaction and verify the rollback was successful.</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="txTest4">
+ <desc>Create an instance of a CMP 2.0 entity bean. Begin a transaction with the transaction attribute set to RequiredNew. Update the data and ensure that the update is visible within the transaction context by invoking a finder method with associated EJB-QL. Rollback the transaction and verify the rollback was successful.</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="txTest6">
+ <desc>Create an instance of a CMP 2.0 entity bean. Begin a transaction with the transaction attribute set to Mandatory. Update the data and ensure that the update is visible within the transaction context by invoking a finder method with associated EJB-QL. Rollback the transaction and verify the rollback was successful.</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.integration.session.jspejbjdbc.URLClient">
+<desc>J2EE:SPEC:40, 40.1, 40.2, J2EE:SPEC:47 JSP pages may access multiple resource managers and invoke multiple enterprise beans within a single transaction. The specified transaction context is automatically propagated to the enterprise beans and transactional resource managers.The result of the propagation may be subject to the enterprise bean transaction attributes. If a web component invokes an enterprise bean from a thread associated with a JTA transaction, the J2EE platform must propagate the transaction context with the enterprise bean invocation. Whether the target enterprise bean will be invoked in this transaction context or not is determined by the rules defined in the EJB specification.</desc>
+ <test name="test1">
+ <desc> Functional test to demonstrate an N-Tier client which performs database transactions via accessing web server component, ejb server component and database server component using the Application Programming Model as described in the J2EE Platform Specification. The test is a complete end-to-end tests and is modeled as follows: URLClient -> JSP -> JAVABEAN -> EJB -> DB. The test strategy is to create an N-Tier Application Test involving jsp and ejb. Deploy it on the J2EE server. Verify correct operations.
+</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+</testCase>
+<testCase name="com.sun.ts.tests.integration.entity.servletejbjdbc.URLClient">
+<desc>J2EE:SPEC:40, 40.1, 40.2, J2EE:SPEC:47 Servlets may access multiple resource managers and invoke multiple enterprise beans within a single transaction. The specified transaction context is automatically propagated to the enterprise beans and transactional resource managers.The result of the propagation may be subject to the enterprise bean transaction attributes. If a web component invokes an enterprise bean from a thread associated with a JTA transaction, the J2EE platform must propagate the transaction context with the enterprise bean invocation. Whether the target enterprise bean will be invoked in this transaction context or not is determined by the rules defined in the EJB specification.</desc>
+ <test name="test1">
+ <desc> Functional test to demonstrate an N-Tier client which performs database transactions via accessing web server component, ejb server component and database server component using the Application Programming Model as described in the J2EE Platform Specification. The test is a complete end-to-end tests and is modeled as follows: URLClient -> SERVLET -> JAVABEAN -> EJB -> DB. The test strategy is to create an N-Tier Application Test involving jsp and ejb. Deploy it on the J2EE server. Verify correct operations.
+</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+</testCase>
+<testCase name="com.sun.ts.tests.integration.sec.propagation.Client">
+ <desc>J2EE:SPEC:25 Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet. A web container reports that no user has been authenticated by returning null from the HttpServletRequest method getUserPrincipal. This is different than the corresponding result for EJB containers. The EJB specification requires that the EJBContext method getCallerPrincipal always return a valid Principal object. The method can never return null. Components running in a web container must be able to call enterprise beans even when no user has been authenticated in the web container. When a call is made in such a case from a component in a web container to an enterprise bean, a J2EE product must provide a principal for use in the call. A J2EE product may provide a principal for use by unauthenticated callers using many approaches, including, but not limited t!
o: Always use a single distinguished principal. Use a different distinguished principal per server, or per session, or per application. Allow the deployer or system administrator to choose which principal to use through the Run As capability of the web and enterprise bean containers. J2EE:SPEC:30 Propagated Caller Identities. It must be possible to configure a J2EE product so that a propagated caller identity is used in all authorization decisions. With this configuration, for all calls to all enterprise beans from a single application within a single J2EE product, the principal name returned by the EJBContext method getCallerPrincipal must be the same as that returned by the first enterprise bean in the call chain. If the first enterprise bean in the call chain is called by a servlet or JSP page, the principal name must be the same as that returned by the HttpServletRequest method getUserPrincipal in the calling servlet or JSP page. (However, if the HttpServletRequest met!
hod getUserPrincipal returns null, the principal used in calls to ente
rprise beans is not specified by this specification, although it must still be possible to configure enterprise beans to be callable by such components.) Note that this does not require delegation of credentials, only identification of the caller. A single principal must be the principal used in authorization decisions for access to all enterprise beans in the call chain. The requirements in this section apply only when a J2EE product has been configured to propagate caller identity.</desc>
+ <test name="test_web_to_ejb_noauth">
+ <desc>1. Send request for web_to_ejb_noauth.jsp, a jsp page that
+ is set up with no authentication.
+ 2. web_to_ejb_noauth.jsp looks up Bean1, a stateless
+ session bean.
+ 3. web_to_ejb_noauth.jsp calls
+ bean1.getCallerPrincipalName(), which returns
+ the caller principal.
+ 4. web_to_ejb_noauth.jsp returns the caller principal as
+ the contents of the web page as follows:
+ value of getUserPrincipal().getName()
+ call is successful or not
+ value of second call to getUserPrincipal()
+ 5. Receive response from web_to_ejb_noauth.jsp and ensure
+ the principal output is null for both calls in the jsp
+ and the call to the ejb is successful.
+
+ Note: The value returned for an unauthenticated caller from a
+ call to getRemoteUserPrincipal() in a servlet must
+ be null, and an unauthenticated caller can call an ejb
+ successfully.
+ </desc>
<TSFI>tsfi.http</TSFI>
- <TSFI>tsfi.rmi.jrmp</TSFI>
</test>
- <test name="J2EE:SPEC:31">
- <desc> Propagated Caller Identities. It must be possible to configure a J2EE product so that a propagated caller identity is used in all authorization decisions. With this configuration, for all calls to all enterprise beans from a single application within a single J2EE product, the principal name returned by the EJBContext method getCallerPrincipal must be the same as that returned by the first enterprise bean in the call chain. If the first enterprise bean in the call chain is called by a servlet or JSP page, the principal name must be the same as that returned by the HttpServletRequest method getUserPrincipal in the calling servlet or JSP page. (However, if the HttpServletRequest method getUserPrincipal returns null, the principal used in calls to enterprise beans is not specified by this specification, although it must still be possible to configure enterprise beans to be callable by such components.) Note that this does not require delegation of credentials, o!
nly identification of the caller. A single principal must be the principal used in authorization decisions for access to all enterprise beans in the call chain. The requirements in this section apply only when a J2EE product has been configured to propagate caller identity</desc>
+ <test name="test_web_to_ejb_auth">
+ <desc> 1. Send request for web_to_ejb_auth.jsp, a jsp page that
+ is set up for BASIC authentication. Pass in j2ee as
+ username and password.
+ 2. web_to_ejb_auth.jsp looks up Bean1, a stateless session
+ bean.
+ 3. web_to_ejb_auth.jsp calls
+ bean1.getCallerPrincipalName(), which returns
+ the caller principal.
+ 4. web_to_ejb_auth.jsp returns the caller principal as the
+ contents of the web page as follows.
+ value of getUserPrincipal().getName()
+ value of ejb.getCallerPrincipal().getName()
+ value of second call to getUserPrincipal()
+ 5. Receive response from web_to_ejb_auth.jsp and ensure
+ the principal output is "j2ee" for both the jsp and
+ the ejb.
+ </desc>
<TSFI>tsfi.http</TSFI>
</test>
- <test name="J2EE:SPEC:33">
- <desc> All J2EE products must implement the access control semantics described in the EJB, JSP, and servlet specifications, and provide a means of mapping the deployment descriptor security roles to the actual roles exposed by a J2EE product </desc>
+ </testCase>
+ <testCase name="com.sun.ts.tests.integration.sec.secbasicssl.Client">
+ <desc>J2EE:SPEC:22 All J2EE products are required to support HTTP basic authentication (RFC2068). Platform Providers are also required to support basic authentication over SSL.</desc>
+ <test name="test_login_basic_over_ssl">
+ <desc> This assertion ensures that HTTP Basic authentication over SSL is supported by the J2EE server. It first calls request.isSecure() to ensure it returns true, indicating that a secure connection is in place. Next, the fully qualified URL for the page being viewed is received via the HttpUtils.getRequestURL( request ) method. This url is checked to make sure it begins with https, indicating HTTPS is in use.</desc>
<TSFI>tsfi.http</TSFI>
+ <TSFI>tsfi.https</TSFI>
</test>
- <test name="">
- <desc></desc>
- <TSFI></TSFI>
- </test>
</testCase>
<!-- template -->
@@ -1808,6 +2088,6 @@
<TSFI></TSFI>
</test>
</testCase>
+
</testSuite>
-
-</cc:testCaseMapping>
\ No newline at end of file
+</cc:testCaseMapping>
Modified: branches/JBPAPP_4_2_0_GA_CP/testsuite/src/stylesheets/junit-frames.xsl
===================================================================
--- branches/JBPAPP_4_2_0_GA_CP/testsuite/src/stylesheets/junit-frames.xsl 2008-10-09 11:03:35 UTC (rev 79297)
+++ branches/JBPAPP_4_2_0_GA_CP/testsuite/src/stylesheets/junit-frames.xsl 2008-10-09 11:13:00 UTC (rev 79298)
@@ -534,6 +534,7 @@
</xsl:for-each>
</table>
<xsl:call-template name="pageFooter"/>
+ <xsl:call-template name="cc-testify"/>
</body>
</html>
</xsl:template>
@@ -638,8 +639,38 @@
<td>OS Arch</td><td><xsl:value-of select="$os.arch"/></td>
</tr>
</table>
+
</xsl:template>
+
+<!-- Common Criteria Testify -->
+<xsl:template name="cc-testify">
+ <xsl:if test="//property[@name='cc-testify']/@value">
+ <p/>
+ <hr size="1"/>
+ <p/>
+ <h2>Common Criteria Testify</h2>
+ <a href="allmd5sum.txt">MD5 sums of involved libraries</a>
+ <p/>
+ <table class="details">
+ <tr>
+ <td>Hudson Job Name</td><td><xsl:value-of select="//property[@name='env.JOB_NAME']/@value"/></td>
+ </tr><tr>
+ <td>Build ID</td><td><xsl:value-of select="//property[@name='env.BUILD_ID']/@value"/></td>
+ </tr><tr>
+ <td>Build Tag</td><td><xsl:value-of select="//property[@name='env.BUILD_TAG']/@value"/></td>
+ </tr><tr>
+ <td>Build Number</td><td><xsl:value-of select="//property[@name='env.BUILD_NUMBER']/@value"/></td>
+ </tr><tr>
+ <td>Date</td><td><xsl:value-of select="//property[@name='TODAY']/@value"/></td>
+ </tr><tr>
+ <td>Time</td><td><xsl:value-of select="//property[@name='TIMENOW']/@value"/></td>
+ </tr>
+ </table>
+ </xsl:if>
+</xsl:template>
+
+
<!-- class header -->
<xsl:template name="testsuite.test.header">
<tr bgcolor="#A6CAF0" valign="top">
More information about the jboss-cvs-commits
mailing list