diff --git a/Jenkinsfile b/Jenkinsfile index 8d58b73bee..9fcd7e16ec 100644 --- a/Jenkinsfile +++ b/Jenkinsfile @@ -17,7 +17,7 @@ env.label = "jakartaee-tck-pod-${UUID.randomUUID().toString()}" default_suites=[ "samples", "signaturetest/javaee" ] -default_tcks=["caj", "connector", "el", "jacc", "jaxws", "jms", "jpa", "jsp", "jstl", "jta", "saaj", "servlet", "websocket"] +default_tcks=["caj", "connector", "el", "jaxws", "jms", "jpa", "jsp", "jstl", "jta", "saaj", "servlet", "websocket"] def cts_suites = params.test_suites != null ? params.test_suites.split() : default_suites def tcks = params.standalone_tcks != null ? params.standalone_tcks.split() : default_tcks @@ -190,7 +190,7 @@ spec: description: 'Run the full EE compliance testsuite or a standalone tck' ) string(name: 'test_suites', defaultValue: 'connector ejb ejb30/bb ejb30/lite/appexception ejb30/lite/async ejb30/lite/basic ejb30/lite/ejbcontext ejb30/lite/enventry ejb30/lite/interceptor ejb30/lite/lookup ejb30/lite/naming ejb30/lite/nointerface ejb30/lite/packaging ejb30/lite/singleton ejb30/lite/stateful ejb30/lite/tx ejb30/lite/view ejb30/lite/xmloverride ejb30/assembly ejb30/timer ejb30/webservice ejb30/zombie ejb30/misc ejb30/sec ejb32 el integration jacc javaee javamail jaxrs jdbc_appclient jdbc_ejb jdbc_jsp jdbc_servlet jms_appclient jms_ejb jms_jsp jms_servlet jpa_appmanaged jpa_appmanagedNoTx jpa_pmservlet jpa_puservlet jpa_stateful3 jpa_stateless3 jsonb jsonp jsp jstl jta jws samples servlet signaturetest/javaee webservices12 webservices13 websocket xa', description: 'Space separated list of Test suites to run') - string(name: 'standalone_tcks', defaultValue: 'caj connector el jacc jaxws jms jpa jsp jstl jta saaj servlet websocket', + string(name: 'standalone_tcks', defaultValue: 'caj connector el jaxws jms jpa jsp jstl jta saaj servlet websocket', description: 'Space separated list of standalone TCKs to build and run') string(name: 'USER_KEYWORDS', defaultValue: '', diff --git a/bin/coverage-build.xml b/bin/coverage-build.xml index 889974fc6a..87cebe4694 100644 --- a/bin/coverage-build.xml +++ b/bin/coverage-build.xml @@ -77,10 +77,10 @@ - + webservices13,websocket,xa,jaxws,jpa,jsp,webservices12"/> @@ -311,10 +311,10 @@ + concurrency,websocket"> @@ -349,16 +349,6 @@ - - - - - - - - - - @@ -395,17 +385,6 @@ - - - - - - - - - - - @@ -510,16 +489,6 @@ - - - - - - - - - - diff --git a/bin/xml/impl/glassfish/common.xml b/bin/xml/impl/glassfish/common.xml index ac2d860427..9fc10021c5 100644 --- a/bin/xml/impl/glassfish/common.xml +++ b/bin/xml/impl/glassfish/common.xml @@ -1315,20 +1315,6 @@ - - - - - - - - - - - - @@ -1387,12 +1373,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/bin/xml/ts.vehicles.xml b/bin/xml/ts.vehicles.xml index c2fa51d081..96752b418f 100644 --- a/bin/xml/ts.vehicles.xml +++ b/bin/xml/ts.vehicles.xml @@ -1113,75 +1113,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/common/src/main/java/com/sun/ts/lib/harness/commonarchives.properties b/common/src/main/java/com/sun/ts/lib/harness/commonarchives.properties index fdef86753a..37009d8d67 100644 --- a/common/src/main/java/com/sun/ts/lib/harness/commonarchives.properties +++ b/common/src/main/java/com/sun/ts/lib/harness/commonarchives.properties @@ -127,9 +127,6 @@ commonarchives.com/sun/ts/tests/jws/webservice/webservice3/client=com/sun/ts/tes commonarchives.com/sun/ts/tests/jws/webservice/webservice4/client=com/sun/ts/tests/jws/webservice/webservice4/server -# jacc common app -commonarchives.com/sun/ts/tests/jacc=com/sun/ts/tests/jacc/util - commonarchives.com/sun/ts/tests/jaxp/tck_source/commonarchives.com/sun/ts/tests/api/xml_schema=com/sun/ts/tests/jaxp/api/xml_schema # webservices12 common apps diff --git a/common/src/main/java/com/sun/ts/lib/harness/keyword.properties b/common/src/main/java/com/sun/ts/lib/harness/keyword.properties index 933befee4a..230917b4cd 100644 --- a/common/src/main/java/com/sun/ts/lib/harness/keyword.properties +++ b/common/src/main/java/com/sun/ts/lib/harness/keyword.properties @@ -450,9 +450,6 @@ com/sun/ts/tests/el = el javaee javaee_web_profile com/sun/ts/tests/integration = integration javaee com/sun/ts/tests/integration/entity = javaee_optional -com/sun/ts/tests/jacc = jacc javaee -com/sun/ts/tests/jacc/web = jacc javaee jacc_web_profile jacc_web javaee_web_profile_optional -com/sun/ts/tests/jacc/ejb = jacc javaee jacc_ejb com/sun/ts/tests/javamail = javamail javaee javamail_web_profile javaee_web_profile_optional com/sun/ts/tests/javaee = javaee com/sun/ts/tests/jaxrs = jaxrs javaee jaxrs_web_profile javaee_web_profile @@ -502,8 +499,6 @@ com/sun/ts/tests/servlet/spec/security/annotations = javaee com/sun/ts/tests/signaturetest = signaturetest com/sun/ts/tests/signaturetest/caj = signaturetest caj com/sun/ts/tests/signaturetest/connector = connector -com/sun/ts/tests/signaturetest/jacc = signaturetest jacc -com/sun/ts/tests/signaturetest/jaspic = signaturetest jaspic jaspic_servlet jaspic_soap jaspic_core com/sun/ts/tests/signaturetest/javaee = signaturetest javaee javaee_web_profile com/sun/ts/tests/signaturetest/jaxrs = signaturetest jaxrs #com/sun/ts/tests/signaturetest/jaxws = signaturetest jaxws @@ -517,7 +512,6 @@ com/sun/ts/tests/signaturetest/jstl = signaturetest jstl #com/sun/ts/tests/signaturetest/saaj = signaturetest saaj com/sun/ts/tests/signaturetest/servlet = signaturetest servlet com/sun/ts/tests/signaturetest/websocket = signaturetest websocket -com/sun/ts/tests/signaturetest/securityapi = signaturetest securityapi com/sun/ts/tests/signaturetest/wsmd = signaturetest wsmd com/sun/ts/tests/xa = xa javaee xa_web_profile com/sun/ts/tests/servlet/api/jakarta_servlet/asynccontext = servlet30 javaee javaee_web_profile @@ -570,4 +564,3 @@ com/sun/ts/tests/websocket = websocket javaee javaee_web_profile com/sun/ts/tests/ejb30/persistence/lock = javaee com/sun/ts/tests/ejb30/persistence/ee = javaee com/sun/ts/tests/ejb30/sec/permsxml = javaee security_manager_enabled -com/sun/ts/tests/securityapi = securityapi javaee javaee_web_profile diff --git a/common/src/main/java/com/sun/ts/tests/common/vehicle/VehicleRunnerFactory.java b/common/src/main/java/com/sun/ts/tests/common/vehicle/VehicleRunnerFactory.java index 4f339351d3..6e96fc1f6e 100644 --- a/common/src/main/java/com/sun/ts/tests/common/vehicle/VehicleRunnerFactory.java +++ b/common/src/main/java/com/sun/ts/tests/common/vehicle/VehicleRunnerFactory.java @@ -58,8 +58,6 @@ public final class VehicleRunnerFactory { private static VehicleRunnable connectorServletRunner; - private static VehicleRunnable jaspicServletRunner; - private static VehicleRunnable customVehicleRunner; private static VehicleRunnable webRunner; @@ -288,19 +286,6 @@ private static VehicleRunnable getConnectorServletRunner() { return connectorServletRunner; } - private static VehicleRunnable getJaspicServletRunner() { - if (jaspicServletRunner == null) { - try { - Class c = Class.forName( - "com.sun.ts.tests.common.vehicle.jaspicservlet.JaspicServletVehicleRunner"); - jaspicServletRunner = (VehicleRunnable) c.newInstance(); - } catch (Exception ex) { - ex.printStackTrace(); - } - } - return jaspicServletRunner; - } - // this supports the rare case of a user defined custome vehicle private static VehicleRunnable getCustomVehicleRunner() { if (customVehicleRunner == null) { @@ -345,8 +330,6 @@ public static VehicleRunnable getVehicleRunner(String vtype) { return getPUServletRunner(); } else if (vtype.equalsIgnoreCase("connectorservlet")) { return getConnectorServletRunner(); - } else if (vtype.equalsIgnoreCase("jaspicservlet")) { - return getJaspicServletRunner(); } else if (vtype.equalsIgnoreCase("customvehicle")) { return getCustomVehicleRunner(); } else if (vtype.equalsIgnoreCase("ejblitejsf")) { diff --git a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicServletVehicle.java b/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicServletVehicle.java deleted file mode 100755 index 04c5193880..0000000000 --- a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicServletVehicle.java +++ /dev/null @@ -1,127 +0,0 @@ -/* - * Copyright (c) 2011, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.common.vehicle.jaspicservlet; - -import java.io.BufferedInputStream; -import java.io.IOException; -import java.io.ObjectInputStream; -import java.io.ObjectOutputStream; -import java.rmi.RemoteException; -import java.util.Properties; - -import com.sun.javatest.Status; -import com.sun.ts.lib.harness.EETest; -import com.sun.ts.lib.harness.RemoteStatus; -import com.sun.ts.lib.util.TestUtil; - -import jakarta.servlet.ServletConfig; -import jakarta.servlet.ServletException; -import jakarta.servlet.http.HttpServlet; -import jakarta.servlet.http.HttpServletRequest; -import jakarta.servlet.http.HttpServletResponse; - -public class JaspicServletVehicle extends HttpServlet { - protected Properties properties = null; - - protected String[] arguments = null; - - protected EETest testObj = null; - - public void init(ServletConfig config) throws ServletException { - TestUtil.logTrace("init " + this.getClass().getName() + " ..."); - super.init(config); - } - - public void doGet(HttpServletRequest req, HttpServletResponse res) - throws ServletException, IOException { - try { - // get the inputstream and read any objects passed from the - // client, e.g. properties, args, etc. - // wrap the Inputstream in an ObjectInputstream and read - // the properties and args. - TestUtil.logTrace("JaspicServletVehicle - In doGet"); - - ObjectInputStream objInStream = new ObjectInputStream( - new BufferedInputStream(req.getInputStream())); - System.out.println("JaspicServletVehicle - got InputStream"); - TestUtil.logTrace("JaspicServletVehicle - got InputStream"); - properties = (Properties) objInStream.readObject(); - System.out.println("read properties!!!"); - - // create an instance of the test client and run here - Class c = Class.forName(properties.getProperty("test_classname")); - testObj = (EETest) c.newInstance(); - - // Thread.currentThread().dumpStack(); - arguments = (String[]) objInStream.readObject(); - // arguments = new String[1]; - // arguments[0] = ""; - TestUtil.logTrace("JaspicServletVehicle - read Objects"); - try { - TestUtil.init(properties); - TestUtil.logTrace("Remote logging set for Servlet Vehicle"); - TestUtil.logTrace("JaspicServletVehicle - Here are the props"); - TestUtil.list(properties); - } catch (Exception e) { - throw new ServletException("unable to initialize remote logging"); - } - ObjectOutputStream objOutStream = new ObjectOutputStream( - res.getOutputStream()); - System.out.println("got outputstream"); - // now run the test and return the result - RemoteStatus finalStatus = runTest(); - System.out.println("ran test"); - objOutStream.writeObject(finalStatus); - objOutStream.flush(); - objOutStream.close(); - - } catch (Throwable t) { - System.out.println(t.getMessage()); - TestUtil.logTrace(t.getMessage()); - t.printStackTrace(); - throw new ServletException( - "test failed to run within the Servlet Vehicle"); - } - - } - - public void doPost(HttpServletRequest req, HttpServletResponse res) - throws ServletException, IOException { - System.out.println("In doPost!"); - TestUtil.logTrace("In doPost"); - doGet(req, res); - } - - protected RemoteStatus runTest() throws RemoteException { - RemoteStatus sTestStatus = new RemoteStatus(Status.passed("")); - - try { - // call EETest impl's run method - sTestStatus = new RemoteStatus(testObj.run(arguments, properties)); - - if (sTestStatus.getType() == Status.PASSED) - TestUtil.logMsg("Test running in servlet vehicle passed"); - else - TestUtil.logMsg("Test running in servlet vehicle failed"); - } catch (Throwable e) { - TestUtil.logErr("Test running in servlet vehicle failed", e); - sTestStatus = new RemoteStatus( - Status.failed("Test running in servlet vehicle failed")); - } - return sTestStatus; - } -} diff --git a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicServletVehicleRunner.java b/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicServletVehicleRunner.java deleted file mode 100755 index 5d1f57eca2..0000000000 --- a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicServletVehicleRunner.java +++ /dev/null @@ -1,35 +0,0 @@ -/* - * Copyright (c) 2011, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.common.vehicle.jaspicservlet; - -import com.sun.javatest.Status; -import com.sun.ts.lib.util.TestUtil; - -/* - * This is the class that is different for each vehicle. - * This should lookup and invoke the vehicle in the container (if there is one). - */ -public class JaspicServletVehicleRunner extends JaspicVehicleRunner { - protected Status run() { - // run in a jaspicservlet - sTestStatus = runWebVehicleTest(sVehicle); - - TestUtil.logMsg("Test: returning from running in a jaspicservlet vehicle"); - - return sTestStatus; - }// run -} diff --git a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicVehicleRunner.java b/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicVehicleRunner.java deleted file mode 100755 index b4406534b1..0000000000 --- a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/JaspicVehicleRunner.java +++ /dev/null @@ -1,159 +0,0 @@ -/* - * Copyright (c) 2011, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.common.vehicle.jaspicservlet; - -import java.io.IOException; -import java.io.ObjectInputStream; -import java.io.ObjectOutputStream; -import java.net.MalformedURLException; -import java.net.URL; -import java.net.URLConnection; -import java.util.Properties; - -import com.sun.javatest.Status; -import com.sun.ts.lib.harness.RemoteStatus; -import com.sun.ts.lib.porting.TSURL; -import com.sun.ts.lib.util.TestUtil; -import com.sun.ts.tests.common.vehicle.VehicleRunnable; - -public class JaspicVehicleRunner implements VehicleRunnable { - - protected String sVehicle = "jaspicservlet"; - - protected Status sTestStatus = Status.passed(""); - - String urlSuffix = ""; - - Status sServletStatus = Status.passed(""); - - String sVehicleArchiveName = ""; - - String contextRootPrefix; - - String[] argv; - - Properties p; - - public Status run(String[] argv, Properties p) { - this.argv = argv; - this.p = p; - sVehicle = p.getProperty("vehicle"); - - // use this name for the context root or jndi name to eliminate - // naming conflicts for apps deployed at the same time - sVehicleArchiveName = p.getProperty("vehicle_archive_name"); - - if (sVehicleArchiveName.indexOf("_vehicles") != -1) { - contextRootPrefix = sVehicleArchiveName.substring(0, - sVehicleArchiveName.indexOf("_vehicles") + 1) + sVehicle - + "_vehicle_web"; - } else { - if (sVehicleArchiveName.endsWith("_web")) { - contextRootPrefix = sVehicleArchiveName; - } else { - contextRootPrefix = sVehicleArchiveName + "_web"; - } - } - - // default urlSuffix - urlSuffix = "/" + contextRootPrefix + "/" + sVehicle + "_vehicle"; - - return run(); - } // run - - protected Status run() { - // run in a jaspicservlet - urlSuffix = "/" + contextRootPrefix + "/jaspicservlet_vehicle"; - sServletStatus = runWebVehicleTest("jaspicservlet"); - - TestUtil.logMsg("Test: returning from running in jaspicservlet vehicles"); - - if (sServletStatus.isPassed()) { - sTestStatus = Status.passed("Test passed in a jaspicservlet "); - } else { - sTestStatus = Status.failed("Test failed in a jaspicservlet "); - } - return sTestStatus; - } - - protected Status runWebVehicleTest(String vehicle) { - URLConnection connection = null; - URL url = null; - ObjectOutputStream objOut = null; - ObjectInputStream objIn = null; - Status status; - - try { - TSURL ctsURL = new TSURL(); - url = ctsURL.getURL("http", p.getProperty("webServerHost"), - Integer.parseInt(p.getProperty("webServerPort")), urlSuffix); - connection = url.openConnection(); - TestUtil.logMsg("Opened connection to " + url); - connection.setDoOutput(true); - connection.setDoInput(true); - connection.setUseCaches(false); - connection.setRequestProperty("Content-Type", - "java-internal/" + p.getClass().getName()); - // connection.connect(); - objOut = new ObjectOutputStream(connection.getOutputStream()); - TestUtil.logTrace("got outputstream"); - objOut.writeObject(p); - objOut.writeObject(argv); - TestUtil.logTrace("wrote objects to the " + vehicle + " vehicle"); - objOut.flush(); - objOut.close(); - objOut = null; - - // read the status when it comes back - objIn = new ObjectInputStream(connection.getInputStream()); - status = ((RemoteStatus) objIn.readObject()).toStatus(); - TestUtil.logMsg("Test status from a " + vehicle + ": " + status.getType() - + ":" + status.getReason()); - - } catch (MalformedURLException e) { - e.printStackTrace(); - status = Status.failed("Fatal: Improper URL"); - } catch (NumberFormatException e) { - e.printStackTrace(); - status = Status.failed( - "Please set an appropriate value for the property: webServerPort"); - } catch (IOException e) { - e.printStackTrace(); - status = Status.failed("Fatal: Problem with connection: " + e); - } catch (Exception e) { - e.printStackTrace(); - status = Status.failed( - "ServiceTest failed inside a " + vehicle + ": " + e.getMessage()); - } finally { - - if (objOut != null) { - try { - objOut.close(); - } catch (Exception e) { - } - } - - if (objIn != null) { - try { - objIn.close(); - } catch (Exception e) { - } - } - } - return status; - } -} diff --git a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/build.xml b/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/build.xml deleted file mode 100755 index 3af7d2095d..0000000000 --- a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/build.xml +++ /dev/null @@ -1,24 +0,0 @@ - - - - - - - - diff --git a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/jaspicservlet_vehicle_web.xml b/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/jaspicservlet_vehicle_web.xml deleted file mode 100755 index d8646b2e76..0000000000 --- a/common/src/main/java/com/sun/ts/tests/common/vehicle/jaspicservlet/jaspicservlet_vehicle_web.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - jaspicservlet_vehicle - - JaspicServlet_VehicleLogicalName - com.sun.ts.tests.common.vehicle.jaspicservlet.JaspicServletVehicle - - - JaspicServlet_VehicleLogicalName - /jaspicservlet_vehicle - - - 54 - - diff --git a/docker/build_signatures.sh b/docker/build_signatures.sh index 94eaecdbb5..ee675c9233 100755 --- a/docker/build_signatures.sh +++ b/docker/build_signatures.sh @@ -103,8 +103,6 @@ export SIGFILEPATH=$TS_HOME/src/com/sun/ts/tests/signaturetest/signature-reposit # jakarta.annotation java $jdk9options $CLASSNAME Setup ${OPTIONS} -classpath ${sigTestClasspath} -apiVersion 2.1 -package jakarta.annotation -FileName ${SIGFILEPATH}/jakarta.annotation.sig -# jakarta.security.jacc -java $CLASSNAME Setup ${OPTIONS} -classpath ${sigTestClasspath} -apiVersion 1.6 -package jakarta.security.jacc -FileName ${SIGFILEPATH}/jakarta.security.jacc.sig # jakarta.batch java $CLASSNAME Setup ${OPTIONS} -classpath ${sigTestClasspath} -apiVersion 2.1 -package jakarta.batch -FileName ${SIGFILEPATH}/jakarta.batch.sig # jakarta.decorator diff --git a/docker/build_standalone-tcks.sh b/docker/build_standalone-tcks.sh index 116a5fa298..218d2352e9 100755 --- a/docker/build_standalone-tcks.sh +++ b/docker/build_standalone-tcks.sh @@ -68,7 +68,7 @@ fi echo "The option selected to build is $TCK_NAME TCK" if [ "All" == "$TCK_NAME" ];then - TCK_LIST=( websocket el connector jacc caj jms jsp jstl jaxws saaj servlet jpa jta ) + TCK_LIST=( websocket el connector caj jms jsp jstl jaxws saaj servlet jpa jta ) else TCK_LIST=( ${TCK_NAME} ) fi @@ -136,11 +136,6 @@ for tck in ${TCK_LIST[@]}; do TCK_SPECIFIC_PROPS="-Dconnector.home=$GF_HOME/$GF_TOPLEVEL_DIR/glassfish/" DOC_SPECIFIC_PROPS="" JAXWS_SPECIFIC_PROPS="" - elif [ "jacc" == "$tck" ] - then - TCK_SPECIFIC_PROPS="-Djacc.home=$GF_HOME/$GF_TOPLEVEL_DIR/glassfish/ -Djacc.classes=$JAKARTA_JARS/modules/jakarta.jms-api.jar:$JAKARTA_JARS/modules/jakarta.annotation-api.jar:$JAKARTA_JARS/modules/security.jar:$JAKARTA_JARS/modules/jakarta.servlet-api.jar:$JAKARTA_JARS/modules/jakarta.authorization-api.jar:$JAKARTA_JARS/modules/jakarta.ejb-api.jar:$JAKARTA_JARS/modules/jakarta.persistence-api.jar:$JAKARTA_JARS/modules/jakarta.interceptor-api.jar:$JAKARTA_JARS/modules/jakarta.mail-api.jar:$JAKARTA_JARS/modules/jakarta.transaction-api.jar:$JAKARTA_JARS/modules/jakarta.servlet.jsp-api.jar:$JAKARTA_JARS/modules/glassfish-corba-omgapi.jar:$JAKARTA_JARS/modules/glassfish-corba-omgapi.jar" - DOC_SPECIFIC_PROPS="" - JAXWS_SPECIFIC_PROPS="" elif [ "caj" == "$tck" ] then TCK_SPECIFIC_PROPS="-Dlocal.classes=$JAKARTA_JARS/modules/jakarta.annotation-api.jar:$JAKARTA_JARS/modules/jakarta.transaction-api.jar:$JAKARTA_JARS/modules/glassfish-corba-omgapi.jar" diff --git a/docker/jacctck.sh b/docker/jacctck.sh deleted file mode 100755 index e44380c984..0000000000 --- a/docker/jacctck.sh +++ /dev/null @@ -1,106 +0,0 @@ -#!/bin/bash -x - -# Copyright (c) 2018, 2022 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - -export TCK_HOME=${WORKSPACE} -echo "TCK_HOME in jacctck.sh $TCK_HOME" -echo "ANT_HOME in jacctck.sh $ANT_HOME" -echo "PATH in jacctck.sh $PATH" -echo "ANT_OPTS in jacctck.sh $ANT_OPTS" - -cd $TCK_HOME - -if ls ${WORKSPACE}/standalone-bundles/*jacctck*.zip 1> /dev/null 2>&1; then - echo "Using stashed bundle for jacctck created during the build phase" - unzip -q ${WORKSPACE}/standalone-bundles/*jacctck*.zip -d ${TCK_HOME} - TCK_NAME=jacctck -elif ls ${WORKSPACE}/standalone-bundles/*authorization-tck*.zip 1> /dev/null 2>&1; then - echo "Using stashed bundle for authorization-tck created during the build phase" - unzip -q ${WORKSPACE}/standalone-bundles/*authorization-tck*.zip -d ${TCK_HOME} - TCK_NAME=authorization-tck -else - echo "[ERROR] TCK bundle not found" - exit 1 -fi - -if [ -z "$GF_TOPLEVEL_DIR" ]; then - export GF_TOPLEVEL_DIR=glassfish7 -fi - -##### installRI.sh starts here ##### -echo "Download and install GlassFish 7.0.0 ..." -if [ -z "${GF_BUNDLE_URL}" ]; then - echo "[ERROR] GF_BUNDLE_URL not set" - exit 1 -fi -wget --progress=bar:force --no-cache $GF_BUNDLE_URL -O latest-glassfish.zip -unzip -q ${TCK_HOME}/latest-glassfish.zip -d ${TCK_HOME} - -TS_HOME=$TCK_HOME/$TCK_NAME -echo "TS_HOME $TS_HOME" - -chmod -R 777 $TS_HOME - -cd $TS_HOME/bin - -if [[ "$JDK" == "JDK17" || "$JDK" == "jdk17" ]];then - export JAVA_HOME=${JDK17_HOME} -fi -export PATH=$JAVA_HOME/bin:$PATH - -which java -java -version - -sed -i.bak 's#orb\.port=.*#orb.port=3699#g' ts.jte -sed -i.bak 's#javaee\.level=.*#javaee.level=full#g' ts.jte -sed -i.bak "s#jacc\.home=.*#jacc.home=$TCK_HOME/$GF_TOPLEVEL_DIR/glassfish#g" ts.jte -sed -i.bak 's#jacc\.host=.*#jacc.host=localhost#g' ts.jte -sed -i.bak "s#^report.dir=.*#report.dir=$TCK_HOME/${TCK_NAME}report/${TCK_NAME}#g" ts.jte -sed -i.bak "s#^work.dir=.*#work.dir=$TCK_HOME/${TCK_NAME}work/${TCK_NAME}#g" ts.jte - -CONTENT='' -C=$(echo $CONTENT | sed 's/\//\\\//g') -sed -i.bak "/<\/project>/ s/.*/${C}\n&/" $TS_HOME/bin/build.xml - -mkdir -p $TCK_HOME/${TCK_NAME}report/${TCK_NAME} -mkdir -p $TCK_HOME/${TCK_NAME}work/${TCK_NAME} - -cd $TCK_HOME/$GF_TOPLEVEL_DIR/glassfish/bin -./asadmin start-domain - -cd $TS_HOME/bin -ant config.vi - -cd $TS_HOME/bin -ant enable.jacc - -# disable run for ejb, since jacc-tck runs tests for web profile -#cd $TS_HOME/src/com/sun/ts/tests/jacc/ejb -#ant deploy runclient - -cd $TS_HOME/src/com/sun/ts/tests/ -ant deploy -cd $TS_HOME/bin -ant run.all -echo "Test run complete" - - -JT_REPORT_DIR=$TCK_HOME/${TCK_NAME}report -export HOST=`hostname -f` -echo "1 ${TCK_NAME} ${HOST}" > ${WORKSPACE}/args.txt -mkdir -p ${WORKSPACE}/results/junitreports/ -${JAVA_HOME}/bin/java -Djunit.embed.sysout=true -jar ${WORKSPACE}/docker/JTReportParser/JTReportParser.jar ${WORKSPACE}/args.txt ${JT_REPORT_DIR} ${WORKSPACE}/results/junitreports/ - -tar zcvf ${WORKSPACE}/${TCK_NAME}-results.tar.gz ${TCK_HOME}/${TCK_NAME}report ${TCK_HOME}/${TCK_NAME}work ${WORKSPACE}/results/junitreports/ ${TCK_HOME}/$GF_TOPLEVEL_DIR/glassfish/domains/domain1 $TCK_HOME/$TCK_NAME/bin/ts.* diff --git a/docker/run_jakartaeetck.sh b/docker/run_jakartaeetck.sh index 90d8f8a32e..fb553bd898 100755 --- a/docker/run_jakartaeetck.sh +++ b/docker/run_jakartaeetck.sh @@ -295,7 +295,7 @@ fi "${CTS_HOME}/vi/$GF_VI_TOPLEVEL_DIR/glassfish/bin/asadmin" --user admin --passwordfile ${ADMIN_PASSWORD_FILE} stop-domain if [[ "$PROFILE" == "web" || "$PROFILE" == "WEB" ]];then - KEYWORDS="javaee_web_profile|jacc_web_profile|jaspic_web_profile|javamail_web_profile|connector_web_profile" + KEYWORDS="javaee_web_profile|javamail_web_profile|connector_web_profile" fi if [ -z "${vehicle}" ];then @@ -359,7 +359,7 @@ sed -i.bak "s/^wsgen.ant.classname=.*/wsgen.ant.classname=$\{ri.wsgen.ant.classn sed -i.bak "s/^wsimport.ant.classname=.*/wsimport.ant.classname=$\{ri.wsimport.ant.classname\}/g" ts.jte if [[ "$PROFILE" == "web" || "$PROFILE" == "WEB" ]]; then - sed -i.bak "s/^javaee.level=.*/javaee.level=web connector jaxws jaxb javamail javaeedeploy jacc jaspic wsmd/g" ts.jte + sed -i.bak "s/^javaee.level=.*/javaee.level=web connector jaxws jaxb javamail javaeedeploy wsmd/g" ts.jte fi sed -i.bak 's/^impl.deploy.timeout.multiplier=.*/impl.deploy.timeout.multiplier=240/g' ts.jte @@ -425,12 +425,6 @@ cd "${TS_HOME}/bin" ant config.ri ##### configRI.sh ends here ##### -if [[ "securityapi" == ${test_suite} ]]; then - cd "$TS_HOME/bin"; - ant init.ldap - echo "LDAP initilized for securityapi" -fi - ### ctsStartStandardDeploymentServer.sh starts here ##### cd "$TS_HOME/bin"; echo "ant start.auto.deployment.server > /tmp/deploy.out 2>&1 & " diff --git a/docker/securityapitck.sh b/docker/securityapitck.sh deleted file mode 100644 index 01fc0bac55..0000000000 --- a/docker/securityapitck.sh +++ /dev/null @@ -1,97 +0,0 @@ -#!/bin/bash -x - -# Copyright (c) 2018, 2022 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - - -export TCK_HOME=${WORKSPACE} -echo "TCK_HOME in securityapitck.sh $TCK_HOME" -echo "ANT_HOME in securityapitck.sh $ANT_HOME" -echo "PATH in securityapitck.sh $PATH" -echo "ANT_OPTS in securityapitck.sh $ANT_OPTS" - -HOST=`hostname` - -cd $TCK_HOME - -if ls ${WORKSPACE}/standalone-bundles/*securityapitck*.zip 1> /dev/null 2>&1; then - echo "Using stashed bundle for securityapitck created during the build phase" - unzip -q ${WORKSPACE}/standalone-bundles/*securityapitck*.zip -d ${TCK_HOME} - TCK_NAME=securityapitck -elif ls ${WORKSPACE}/standalone-bundles/*security-tck*.zip 1> /dev/null 2>&1; then - echo "Using stashed bundle for security-tck created during the build phase" - unzip -q ${WORKSPACE}/standalone-bundles/*security-tck*.zip -d ${TCK_HOME} - TCK_NAME=security-tck -else - echo "[ERROR] TCK bundle not found" - exit 1 -fi - -if [ -z "$GF_TOPLEVEL_DIR" ]; then - export GF_TOPLEVEL_DIR=glassfish7 -fi - - -##### installRI.sh starts here ##### -echo "Download and install GlassFish 7.0.0 ..." -if [ -z "${GF_BUNDLE_URL}" ]; then - echo "[ERROR] GF_BUNDLE_URL not set" - exit 1 -fi -wget --progress=bar:force --no-cache $GF_BUNDLE_URL -O latest-glassfish.zip -unzip -q ${TCK_HOME}/latest-glassfish.zip -d ${TCK_HOME} - -TS_HOME=$TCK_HOME/$TCK_NAME -echo "TS_HOME $TS_HOME" - -rm -f $TS_HOME/lib/js-1.6R1.jar -rm -f $TS_HOME/lib/jax-qname.jar - -chmod -R 777 $TS_HOME -cd $TS_HOME/bin - -if [[ "$JDK" == "JDK17" || "$JDK" == "jdk17" ]];then - export JAVA_HOME=${JDK17_HOME} -fi -export PATH=$JAVA_HOME/bin:$PATH - -which java -java -version - -sed -i.bak "s#web\.home=.*#web.home=$TCK_HOME/$GF_TOPLEVEL_DIR/glassfish#g" ts.jte -sed -i.bak "s#^report.dir=.*#report.dir=$TCK_HOME/${TCK_NAME}report/${TCK_NAME}#g" ts.jte -sed -i.bak "s#^work.dir=.*#work.dir=$TCK_HOME/${TCK_NAME}work/${TCK_NAME}#g" ts.jte - -sed -i.bak 's#securityapi.classes=.*#securityapi.classes=${web.home}/modules/jakarta.servlet-api.jar${pathsep}${web.home}/modules/jakarta.security.enterprise-api.jar${pathsep}${web.home}/modules/jakarta.security.auth.message-api.jar${pathsep}${web.home}/modules/jakarta.annotation-api.jar${pathsep}${web.home}/modules/jakarta.inject-api.jar${pathsep}${web.home}/modules/jakarta.enterprise.cdi-api.jar${pathsep}${web.home}/modules/jakarta.faces.jar${pathsep}${web.home}/modules/jakarta.interceptor-api.jar${pathsep}${web.home}/modules/jakarta.authentication-api.jar${pathsep}${web.home}/modules/jakarta.ejb-api.jar${pathsep}/${ts.home}/lib/unboundid-ldapsdk.jar#g' ts.jte - -mkdir -p $TCK_HOME/${TCK_NAME}report/${TCK_NAME} -mkdir -p $TCK_HOME/${TCK_NAME}work/${TCK_NAME} - -cd $TCK_HOME/$GF_TOPLEVEL_DIR/bin -./asadmin start-database - -cd $TS_HOME/bin -ant config.vi -ant init.ldap -ant deploy.all -ant run.all - -JT_REPORT_DIR=$TCK_HOME/${TCK_NAME}report -export HOST=`hostname -f` -echo "1 ${TCK_NAME} ${HOST}" > ${WORKSPACE}/args.txt -mkdir -p ${WORKSPACE}/results/junitreports/ -${JAVA_HOME}/bin/java -Djunit.embed.sysout=true -jar ${WORKSPACE}/docker/JTReportParser/JTReportParser.jar ${WORKSPACE}/args.txt ${JT_REPORT_DIR} ${WORKSPACE}/results/junitreports/ - -tar zcvf ${WORKSPACE}/${TCK_NAME}-results.tar.gz ${TCK_HOME}/${TCK_NAME}report ${TCK_HOME}/${TCK_NAME}work ${WORKSPACE}/results/junitreports/ ${TCK_HOME}/$GF_TOPLEVEL_DIR/glassfish/domains/domain1 $TCK_HOME/$TCK_NAME/bin/ts.* - diff --git a/docker/toMaven.sh b/docker/toMaven.sh index d21b12cc30..cf2b33d2eb 100644 --- a/docker/toMaven.sh +++ b/docker/toMaven.sh @@ -26,7 +26,7 @@ if [[ "$result" != "jakartaee-tck" ]]; then exit 1 fi -modules=(appclient assembly common concurrency connector ejb ejb30 ejb32 el integration internal jacc jaspic javaee javamail jaxrs jaxws jdbc jms jpa jsf jsonb jsonp jsp jstl jta jws saaj samples securityapi servlet signaturetest webservices12 webservices13 websocket xa) +modules=(appclient assembly common concurrency connector ejb ejb30 ejb32 el integration internal javaee javamail jaxrs jaxws jdbc jms jpa jsf jsonb jsonp jsp jstl jta jws saaj samples securityapi servlet signaturetest webservices12 webservices13 websocket xa) for module in ${modules[*]}; do echo "=== Module $module ===" @@ -68,7 +68,7 @@ for module in ${modules[*]}; do done # fixup packages -modules=(appclient assembly common concurrency connector ejb ejb30 ejb32 el integration internal jacc jaspic javaee javamail jaxrs jaxws jdbc jms jpa jsf jsonb jsonp jsp jstl jta jws saaj samples securityapi servlet signaturetest webservices12 webservices13 websocket xa) +modules=(appclient assembly common concurrency connector ejb ejb30 ejb32 el integration internal javaee javamail jaxrs jaxws jdbc jms jpa jsf jsonb jsonp jsp jstl jta jws saaj samples securityapi servlet signaturetest webservices12 webservices13 websocket xa) for module in ${modules[*]}; do rm -rf $module/src/test/java/com/sun/ts/tests/ diff --git a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jacc/JACCDeliverable.java b/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jacc/JACCDeliverable.java deleted file mode 100644 index 5b43977ddc..0000000000 --- a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jacc/JACCDeliverable.java +++ /dev/null @@ -1,65 +0,0 @@ -/* - * Copyright (c) 2008, 2018 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.lib.deliverable.jacc; - -import com.sun.ts.lib.deliverable.AbstractDeliverable; -import com.sun.ts.lib.deliverable.PropertyManagerInterface; -import com.sun.javatest.TestEnvironment; -import com.sun.ts.lib.util.TestUtil; -import java.io.File; -import java.util.Map; -import java.util.Properties; - -public class JACCDeliverable extends AbstractDeliverable { - - public PropertyManagerInterface createPropertyManager(TestEnvironment te) - throws Exception { - return JACCPropertyManager.getJACCPropertyManager(te); - } - - public PropertyManagerInterface createPropertyManager(Properties p) - throws Exception { - return JACCPropertyManager.getJACCPropertyManager(p); - } - - public PropertyManagerInterface getPropertyManager() throws Exception { - return JACCPropertyManager.getJACCPropertyManager(); - } - - public boolean supportsAutoDeployment() { - return false; - } - - public boolean supportsAutoJMSAdmin() { - return false; - } - - public boolean supportsInterop() { - return false; - } - - public Map getValidVehicles() { - super.getValidVehicles(); - - // add default values - htTSValidVehicles.put("tests.service_eetest.vehicles", - new String[] { "standalone", "appclient" }); - - return htTSValidVehicles; - } - -} diff --git a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jacc/JACCPropertyManager.java b/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jacc/JACCPropertyManager.java deleted file mode 100644 index d8bbb17733..0000000000 --- a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jacc/JACCPropertyManager.java +++ /dev/null @@ -1,85 +0,0 @@ -/* - * Copyright (c) 2008, 2018 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.lib.deliverable.jacc; - -import com.sun.ts.lib.deliverable.*; -import com.sun.javatest.TestEnvironment; -import java.util.Properties; - -public class JACCPropertyManager extends AbstractPropertyManager { - - private static JACCPropertyManager jteMgr = new JACCPropertyManager(); - - /** - * This method returns the singleton instance of JACCPropertyManager which - * provides access to all ts.jte properties. This is only called once by the - * test harness. - * - * @param env - * - TestEnvironment object from JavaTest - * @return JACCPropertyManager - singleton property manager object - */ - - public final static JACCPropertyManager getJACCPropertyManager( - TestEnvironment env) throws Exception { - jteMgr.setTestEnvironment(env); - return jteMgr; - } - - /** - * This method returns the singleton instance of JACCPropertyManager which - * provides access to all ts.jte properties. This is only called by the init() - * method in ManualDeployment.java - * - * @param p - * - Properties object from JavaTest - * @return JACCPropertyManager - singleton property manager object - */ - public final static JACCPropertyManager getJACCPropertyManager(Properties p) - throws Exception { - jteMgr.setJteProperties(p); - return jteMgr; - } - - public final static JACCPropertyManager getJACCPropertyManager() - throws Exception { - return jteMgr; - } - - /** - * This method is called by the test harness to retrieve all properties needed - * by a particular test. - * - * @param sPropKeys - * - Properties to retrieve - * @return Properties - property/value pairs - */ - public Properties getTestSpecificProperties(String[] sPropKeys) - throws PropertyNotSetException { - Properties pTestProps = super.getTestSpecificProperties(sPropKeys); - String sJtePropVal = ""; - pTestProps.put("porting.ts.url.class.1", - getProperty("porting.ts.url.class.1")); - String tsHome = getProperty("TS_HOME", null); - if (tsHome == null) - tsHome = getProperty("ts_home", null); - if (tsHome != null) - pTestProps.put("ts_home", tsHome); - - return pTestProps; - } -} diff --git a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicDeliverable.java b/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicDeliverable.java deleted file mode 100644 index 71019072e8..0000000000 --- a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicDeliverable.java +++ /dev/null @@ -1,91 +0,0 @@ -/* - * Copyright (c) 2007, 2018 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/** - * - * @author Raja Perumal - */ - -package com.sun.ts.lib.deliverable.jaspic; - -import com.sun.ts.lib.deliverable.AbstractDeliverable; -import com.sun.ts.lib.deliverable.PropertyManagerInterface; -import com.sun.ts.lib.util.TestUtil; -import com.sun.javatest.TestEnvironment; - -import java.util.Map; -import java.util.Properties; -import java.io.File; - -/** - * This class serves as a place for Jaspic Deliverable specific info. - */ -public class JaspicDeliverable extends AbstractDeliverable { - - public PropertyManagerInterface createPropertyManager(TestEnvironment te) - throws Exception { - JaspicPropertyManager propMgr = JaspicPropertyManager - .getJaspicPropertyManager(te); - - // create Jaspic specific working directories - createDir(propMgr.getProperty("wsdlRepository1")); - createDir(propMgr.getProperty("wsdlRepository2")); - return propMgr; - } - - public PropertyManagerInterface createPropertyManager(Properties p) - throws Exception { - return JaspicPropertyManager.getJaspicPropertyManager(p); - } - - public PropertyManagerInterface getPropertyManager() throws Exception { - return JaspicPropertyManager.getJaspicPropertyManager(); - } - - public Map getValidVehicles() { - super.getValidVehicles(); - - htTSValidVehicles.put("tests.service_eetest.vehicles", - new String[] { "servlet", "jsp" }); - - return htTSValidVehicles; - } - - public Map getInteropDirections() { - super.getInteropDirections(); - - return htValidRunDirections; - } - - public boolean supportsInterop() { - return false; - } - - public boolean supportsAutoDeployment() { - return false; - } - - private void createDir(String sDir) throws Exception { - File fDir = new File(sDir); - - if (!fDir.exists()) { - if (!fDir.mkdirs()) { - throw new Exception("Failed to create directory: " + sDir); - } - TestUtil.logHarnessDebug("Successfully created directory: " + sDir); - } - } -} diff --git a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicJakartaEEDeliverable.java b/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicJakartaEEDeliverable.java deleted file mode 100644 index db09e0387e..0000000000 --- a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicJakartaEEDeliverable.java +++ /dev/null @@ -1,88 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/** - * - * @author Raja Perumal - */ - -package com.sun.ts.lib.deliverable.jaspic; - -import com.sun.ts.lib.deliverable.PropertyManagerInterface; -import com.sun.ts.lib.porting.DeploymentInfo; -import com.sun.ts.lib.implementation.sun.javaee.runtime.SunRIDeploymentInfo; -import com.sun.ts.lib.deliverable.AbstractDeliverable; -import com.sun.ts.lib.deliverable.PropertyNotSetException; -import com.sun.ts.lib.util.TestUtil; - -import com.sun.javatest.TestEnvironment; - -import java.util.Properties; -import java.util.Map; -import java.io.File; - -/** - * This class serves as a place for JaspicJakartaEE Deliverable specific info. - */ -public class JaspicJakartaEEDeliverable extends AbstractDeliverable { - - public PropertyManagerInterface createPropertyManager(TestEnvironment te) - throws Exception { - - JaspicJakartaEEPropertyManager propMgr = JaspicJakartaEEPropertyManager - .getJaspicJakartaEEPropertyManager(te); - - // create JaspicJakartaEE specific working directories - createDir(propMgr.getProperty("wsdlRepository1")); - createDir(propMgr.getProperty("wsdlRepository2")); - return propMgr; - } - - public PropertyManagerInterface createPropertyManager(Properties p) - throws Exception { - return JaspicJakartaEEPropertyManager.getJaspicJakartaEEPropertyManager(p); - } - - public PropertyManagerInterface getPropertyManager() throws Exception { - return JaspicJakartaEEPropertyManager.getJaspicJakartaEEPropertyManager(); - } - - public DeploymentInfo getDeploymentInfo(String earFile, - String[] sValidRuntimeInfoFilesArray) { - DeploymentInfo info = null; - try { - info = new SunRIDeploymentInfo(earFile, sValidRuntimeInfoFilesArray); - } catch (Exception e) { - e.printStackTrace(); - } - return info; - } - - public boolean supportsInterop() { - return false; - } - - private void createDir(String sDir) throws Exception { - File fDir = new File(sDir); - - if (!fDir.exists()) { - if (!fDir.mkdirs()) { - throw new Exception("Failed to create directory: " + sDir); - } - TestUtil.logHarnessDebug("Successfully created directory: " + sDir); - } - } -} diff --git a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicJakartaEEPropertyManager.java b/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicJakartaEEPropertyManager.java deleted file mode 100644 index 9aa05a2a9a..0000000000 --- a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicJakartaEEPropertyManager.java +++ /dev/null @@ -1,184 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.lib.deliverable.jaspic; - -import com.sun.javatest.TestEnvironment; -import com.sun.ts.lib.deliverable.AbstractPropertyManager; -import com.sun.ts.lib.deliverable.PropertyNotSetException; -import java.util.Properties; - -/** - * This class serves as a well known place for harness, util, and porting - * classes to retrieve property values. - */ -public class JaspicJakartaEEPropertyManager extends AbstractPropertyManager { - - private static JaspicJakartaEEPropertyManager jteMgr = new JaspicJakartaEEPropertyManager(); - - private String sDeployClass1; - - private String sDeployClass2; - - private String sLoginClass1; - - private String sURLClass1; - - private String sURLClass2; - - private String sJMSClass1; - - private String sDeployHost1; - - private String sDeployHost2; - - private String sWebServerHost; - - private String sWebServerPort; - - private String sWebServerHost2; - - private String sWebServerPort2; - - private String sSecuredWebServicePort; - - private String sSecuredWebServicePort2; - - private String sHttpsURLConnectionClass1; - - private String sWSDLRepository1; - - private String sWSDLRepository2; - - private String user1; - - private String password1; - - private String user2; - - private String password2; - - private JaspicJakartaEEPropertyManager() { - } - - /** - * This method returns the singleton instance of JaspicJakartaEEPropertyManager - * which provides access to all ts.jte properties. This is only called once by - * the test harness. - * - * @param env - * - TestEnvironment object from JavaTest - * @return JaspicJakartaEEPropertyManager - singleton property manager object - */ - public final static JaspicJakartaEEPropertyManager getJaspicJakartaEEPropertyManager( - TestEnvironment env) throws PropertyNotSetException { - jteMgr.setTestEnvironment(env); - jteMgr.initInteropProperties(); // TODO: why init interop only here? - return jteMgr; - } - - /** - * This method returns the singleton instance of JaspicJakartaEEPropertyManager - * which provides access to all ts.jte properties. This is only called by the - * init() method in ManualDeployment.java - * - * @param p - * - Properties object from JavaTest - * @return JaspicJakartaEEPropertyManager - singleton property manager object - */ - public final static JaspicJakartaEEPropertyManager getJaspicJakartaEEPropertyManager( - Properties p) throws PropertyNotSetException { - jteMgr.setJteProperties(p); - return jteMgr; - } - - public final static JaspicJakartaEEPropertyManager getJaspicJakartaEEPropertyManager() - throws PropertyNotSetException { - return jteMgr; - } - - private void initInteropProperties() { - } - - public void forwardValues() { - // reverse all interop props - setProperty("user1", user1); - setProperty("password1", password1); - setProperty("user2", user2); - setProperty("password2", password2); - - setProperty("porting.ts.deploy.class.1", sDeployClass1); - setProperty("porting.ts.deploy.class.2", sDeployClass2); - setProperty("porting.ts.login.class.1", sLoginClass1); - setProperty("porting.ts.url.class.1", sURLClass1); - setProperty("porting.ts.jms.class.1", sJMSClass1); - setProperty("deployment_host.1", sDeployHost1); - setProperty("deployment_host.2", sDeployHost2); - setProperty("webServerHost", sWebServerHost); - setProperty("webServerHost.2", sWebServerHost2); - setProperty("webServerPort", sWebServerPort); - setProperty("webServerPort.2", sWebServerPort2); - setProperty("securedWebServicePort", sSecuredWebServicePort); - setProperty("securedWebServicePort.2", sSecuredWebServicePort2); - setProperty("porting.ts.HttpsURLConnection.class.1", - sHttpsURLConnectionClass1); - setProperty("wsdlRepository1", sWSDLRepository1); - setProperty("wsdlRepository2", sWSDLRepository2); - - super.forwardValues(); - } - - public void reverseValues() { - // reverse all interop props - } - - /** - * This method is called by the test harness to retrieve all properties needed - * by a particular test. - * - * @param sPropKeys - * - Properties to retrieve - * @return Properties - property/value pairs - */ - public Properties getTestSpecificProperties(String[] sPropKeys) - throws PropertyNotSetException { - Properties pTestProps = super.getTestSpecificProperties(sPropKeys); - - // if the abstract propertymanager already loaded all props, just return - if (pTestProps.getProperty("all.props").equalsIgnoreCase("true")) { - return pTestProps; - } - - String sJtePropVal = ""; - // add all porting class props so the factories can work in the server - pTestProps.put("porting.ts.deploy.class.1", - getProperty("porting.ts.deploy.class.1")); - pTestProps.put("porting.ts.deploy.class.2", - getProperty("porting.ts.deploy.class.2")); - pTestProps.put("porting.ts.login.class.1", - getProperty("porting.ts.login.class.1")); - pTestProps.put("porting.ts.HttpsURLConnection.class.1", - getProperty("porting.ts.HttpsURLConnection.class.1")); - pTestProps.put("porting.ts.url.class.1", - getProperty("porting.ts.url.class.1")); - pTestProps.put("porting.ts.jms.class.1", - getProperty("porting.ts.jms.class.1")); - pTestProps.put("wsdlRepository1", getProperty("wsdlRepository1")); - pTestProps.put("wsdlRepository2", getProperty("wsdlRepository2")); - - return pTestProps; - } -} diff --git a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicPropertyManager.java b/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicPropertyManager.java deleted file mode 100644 index 6865d031b2..0000000000 --- a/glassfishtck/src/main/java/com/sun/ts/lib/deliverable/jaspic/JaspicPropertyManager.java +++ /dev/null @@ -1,156 +0,0 @@ -/* - * Copyright (c) 2007, 2018 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/** - * - * @author Raja Perumal - */ - -package com.sun.ts.lib.deliverable.jaspic; - -import com.sun.ts.lib.deliverable.AbstractPropertyManager; -import com.sun.ts.lib.deliverable.PropertyManagerInterface; -import com.sun.ts.lib.deliverable.PropertyNotSetException; -import com.sun.javatest.TestEnvironment; - -import java.util.Map; -import java.util.Properties; - -/** - * This class serves as a well known place for harness, util, and porting - * classes to retrieve property values. - */ -public class JaspicPropertyManager extends AbstractPropertyManager { - // uninitialized singleton instance - private static JaspicPropertyManager jteMgr = new JaspicPropertyManager(); - - private String sLoginClass1; - - private String sLoginClass2; - - private String sURLClass1; - - private String sURLClass2; - - private String sJMSClass1; - - private String sJMSClass2; - - private String sWebServerHost; - - private String sWebServerPort; - - private String sWebServerHost2; - - private String sWebServerPort2; - - private String sSecuredWebServicePort; - - private String sSecuredWebServicePort2; - - private String sHttpsURLConnectionClass1; - - private String sHttpsURLConnectionClass2; - - private String sWSDLRepository1; - - private String sWSDLRepository2; - - private String user1; - - private String password1; - - private String user2; - - private String password2; - - private JaspicPropertyManager() { - } - - /** - * This method returns the singleton instance of TSPropertyManager which - * provides access to all ts.jte properties. This is only called once by the - * test harness. - * - * @param env - * - TestEnvironment object from JavaTest - * @return TSPropertyManager - singleton property manager object - */ - public final static JaspicPropertyManager getJaspicPropertyManager( - TestEnvironment env) throws PropertyNotSetException { - jteMgr.setTestEnvironment(env); - return jteMgr; - } - - /** - * This method returns the singleton instance of JaspicPropertyManager which - * provides access to all ts.jte properties. This is only called by the init() - * method in ManualDeployment.java - * - * @param p - * - Properties object from JavaTest - * @return JaspicPropertyManager - singleton property manager object - */ - public final static JaspicPropertyManager getJaspicPropertyManager( - Properties p) throws PropertyNotSetException { - jteMgr.setJteProperties(p); - return jteMgr; - } - - public final static JaspicPropertyManager getJaspicPropertyManager() - throws PropertyNotSetException { - return jteMgr; - } - - /** - * This method is called by the test harness to retrieve all properties needed - * by a particular test. - * - * @param sPropKeys - * - Properties to retrieve - * @return Properties - property/value pairs - */ - public Properties getTestSpecificProperties(String[] sPropKeys) - throws PropertyNotSetException { - Properties pTestProps = super.getTestSpecificProperties(sPropKeys); - - // if the abstract propertymanager already loaded all props, just return - if (pTestProps.getProperty("all.props").equalsIgnoreCase("true")) { - return pTestProps; - } - - String sJtePropVal = ""; - // add all porting class props so the factories can work in the server - pTestProps.put("porting.ts.deploy.class.1", - getProperty("porting.ts.deploy.class.1")); - pTestProps.put("porting.ts.deploy.class.2", - getProperty("porting.ts.deploy.class.2")); - pTestProps.put("porting.ts.login.class.1", - getProperty("porting.ts.login.class.1")); - pTestProps.put("porting.ts.HttpsURLConnection.class.1", - getProperty("porting.ts.HttpsURLConnection.class.1")); - pTestProps.put("porting.ts.url.class.1", - getProperty("porting.ts.url.class.1")); - pTestProps.put("porting.ts.jms.class.1", - getProperty("porting.ts.jms.class.1")); - pTestProps.put("wsdlRepository1", getProperty("wsdlRepository1")); - pTestProps.put("wsdlRepository2", getProperty("wsdlRepository2")); - - pTestProps.put("javaee.level", getProperty("javaee.level", "component")); - - return pTestProps; - } -} diff --git a/install/jacc/LICENSE.md b/install/jacc/LICENSE.md deleted file mode 100644 index 5de3d1b40c..0000000000 --- a/install/jacc/LICENSE.md +++ /dev/null @@ -1,637 +0,0 @@ -# Eclipse Public License - v 2.0 - - THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE - PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION - OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT. - - 1. DEFINITIONS - - "Contribution" means: - - a) in the case of the initial Contributor, the initial content - Distributed under this Agreement, and - - b) in the case of each subsequent Contributor: - i) changes to the Program, and - ii) additions to the Program; - where such changes and/or additions to the Program originate from - and are Distributed by that particular Contributor. A Contribution - "originates" from a Contributor if it was added to the Program by - such Contributor itself or anyone acting on such Contributor's behalf. - Contributions do not include changes or additions to the Program that - are not Modified Works. - - "Contributor" means any person or entity that Distributes the Program. - - "Licensed Patents" mean patent claims licensable by a Contributor which - are necessarily infringed by the use or sale of its Contribution alone - or when combined with the Program. - - "Program" means the Contributions Distributed in accordance with this - Agreement. - - "Recipient" means anyone who receives the Program under this Agreement - or any Secondary License (as applicable), including Contributors. - - "Derivative Works" shall mean any work, whether in Source Code or other - form, that is based on (or derived from) the Program and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. - - "Modified Works" shall mean any work in Source Code or other form that - results from an addition to, deletion from, or modification of the - contents of the Program, including, for purposes of clarity any new file - in Source Code form that contains any contents of the Program. Modified - Works shall not include works that contain only declarations, - interfaces, types, classes, structures, or files of the Program solely - in each case in order to link to, bind by name, or subclass the Program - or Modified Works thereof. - - "Distribute" means the acts of a) distributing or b) making available - in any manner that enables the transfer of a copy. - - "Source Code" means the form of a Program preferred for making - modifications, including but not limited to software source code, - documentation source, and configuration files. - - "Secondary License" means either the GNU General Public License, - Version 2.0, or any later versions of that license, including any - exceptions or additional permissions as identified by the initial - Contributor. - - 2. GRANT OF RIGHTS - - a) Subject to the terms of this Agreement, each Contributor hereby - grants Recipient a non-exclusive, worldwide, royalty-free copyright - license to reproduce, prepare Derivative Works of, publicly display, - publicly perform, Distribute and sublicense the Contribution of such - Contributor, if any, and such Derivative Works. - - b) Subject to the terms of this Agreement, each Contributor hereby - grants Recipient a non-exclusive, worldwide, royalty-free patent - license under Licensed Patents to make, use, sell, offer to sell, - import and otherwise transfer the Contribution of such Contributor, - if any, in Source Code or other form. This patent license shall - apply to the combination of the Contribution and the Program if, at - the time the Contribution is added by the Contributor, such addition - of the Contribution causes such combination to be covered by the - Licensed Patents. The patent license shall not apply to any other - combinations which include the Contribution. No hardware per se is - licensed hereunder. - - c) Recipient understands that although each Contributor grants the - licenses to its Contributions set forth herein, no assurances are - provided by any Contributor that the Program does not infringe the - patent or other intellectual property rights of any other entity. - Each Contributor disclaims any liability to Recipient for claims - brought by any other entity based on infringement of intellectual - property rights or otherwise. As a condition to exercising the - rights and licenses granted hereunder, each Recipient hereby - assumes sole responsibility to secure any other intellectual - property rights needed, if any. For example, if a third party - patent license is required to allow Recipient to Distribute the - Program, it is Recipient's responsibility to acquire that license - before distributing the Program. - - d) Each Contributor represents that to its knowledge it has - sufficient copyright rights in its Contribution, if any, to grant - the copyright license set forth in this Agreement. - - e) Notwithstanding the terms of any Secondary License, no - Contributor makes additional grants to any Recipient (other than - those set forth in this Agreement) as a result of such Recipient's - receipt of the Program under the terms of a Secondary License - (if permitted under the terms of Section 3). - - 3. REQUIREMENTS - - 3.1 If a Contributor Distributes the Program in any form, then: - - a) the Program must also be made available as Source Code, in - accordance with section 3.2, and the Contributor must accompany - the Program with a statement that the Source Code for the Program - is available under this Agreement, and informs Recipients how to - obtain it in a reasonable manner on or through a medium customarily - used for software exchange; and - - b) the Contributor may Distribute the Program under a license - different than this Agreement, provided that such license: - i) effectively disclaims on behalf of all other Contributors all - warranties and conditions, express and implied, including - warranties or conditions of title and non-infringement, and - implied warranties or conditions of merchantability and fitness - for a particular purpose; - - ii) effectively excludes on behalf of all other Contributors all - liability for damages, including direct, indirect, special, - incidental and consequential damages, such as lost profits; - - iii) does not attempt to limit or alter the recipients' rights - in the Source Code under section 3.2; and - - iv) requires any subsequent distribution of the Program by any - party to be under a license that satisfies the requirements - of this section 3. - - 3.2 When the Program is Distributed as Source Code: - - a) it must be made available under this Agreement, or if the - Program (i) is combined with other material in a separate file or - files made available under a Secondary License, and (ii) the initial - Contributor attached to the Source Code the notice described in - Exhibit A of this Agreement, then the Program may be made available - under the terms of such Secondary Licenses, and - - b) a copy of this Agreement must be included with each copy of - the Program. - - 3.3 Contributors may not remove or alter any copyright, patent, - trademark, attribution notices, disclaimers of warranty, or limitations - of liability ("notices") contained within the Program from any copy of - the Program which they Distribute, provided that Contributors may add - their own appropriate notices. - - 4. COMMERCIAL DISTRIBUTION - - Commercial distributors of software may accept certain responsibilities - with respect to end users, business partners and the like. While this - license is intended to facilitate the commercial use of the Program, - the Contributor who includes the Program in a commercial product - offering should do so in a manner which does not create potential - liability for other Contributors. Therefore, if a Contributor includes - the Program in a commercial product offering, such Contributor - ("Commercial Contributor") hereby agrees to defend and indemnify every - other Contributor ("Indemnified Contributor") against any losses, - damages and costs (collectively "Losses") arising from claims, lawsuits - and other legal actions brought by a third party against the Indemnified - Contributor to the extent caused by the acts or omissions of such - Commercial Contributor in connection with its distribution of the Program - in a commercial product offering. The obligations in this section do not - apply to any claims or Losses relating to any actual or alleged - intellectual property infringement. In order to qualify, an Indemnified - Contributor must: a) promptly notify the Commercial Contributor in - writing of such claim, and b) allow the Commercial Contributor to control, - and cooperate with the Commercial Contributor in, the defense and any - related settlement negotiations. The Indemnified Contributor may - participate in any such claim at its own expense. - - For example, a Contributor might include the Program in a commercial - product offering, Product X. That Contributor is then a Commercial - Contributor. If that Commercial Contributor then makes performance - claims, or offers warranties related to Product X, those performance - claims and warranties are such Commercial Contributor's responsibility - alone. Under this section, the Commercial Contributor would have to - defend claims against the other Contributors related to those performance - claims and warranties, and if a court requires any other Contributor to - pay any damages as a result, the Commercial Contributor must pay - those damages. - - 5. NO WARRANTY - - EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT - PERMITTED BY APPLICABLE LAW, THE PROGRAM IS PROVIDED ON AN "AS IS" - BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR - IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF - TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR - PURPOSE. Each Recipient is solely responsible for determining the - appropriateness of using and distributing the Program and assumes all - risks associated with its exercise of rights under this Agreement, - including but not limited to the risks and costs of program errors, - compliance with applicable laws, damage to or loss of data, programs - or equipment, and unavailability or interruption of operations. - - 6. DISCLAIMER OF LIABILITY - - EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT - PERMITTED BY APPLICABLE LAW, NEITHER RECIPIENT NOR ANY CONTRIBUTORS - SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, - EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST - PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN - CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE - EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE - POSSIBILITY OF SUCH DAMAGES. - - 7. GENERAL - - If any provision of this Agreement is invalid or unenforceable under - applicable law, it shall not affect the validity or enforceability of - the remainder of the terms of this Agreement, and without further - action by the parties hereto, such provision shall be reformed to the - minimum extent necessary to make such provision valid and enforceable. - - If Recipient institutes patent litigation against any entity - (including a cross-claim or counterclaim in a lawsuit) alleging that the - Program itself (excluding combinations of the Program with other software - or hardware) infringes such Recipient's patent(s), then such Recipient's - rights granted under Section 2(b) shall terminate as of the date such - litigation is filed. - - All Recipient's rights under this Agreement shall terminate if it - fails to comply with any of the material terms or conditions of this - Agreement and does not cure such failure in a reasonable period of - time after becoming aware of such noncompliance. If all Recipient's - rights under this Agreement terminate, Recipient agrees to cease use - and distribution of the Program as soon as reasonably practicable. - However, Recipient's obligations under this Agreement and any licenses - granted by Recipient relating to the Program shall continue and survive. - - Everyone is permitted to copy and distribute copies of this Agreement, - but in order to avoid inconsistency the Agreement is copyrighted and - may only be modified in the following manner. The Agreement Steward - reserves the right to publish new versions (including revisions) of - this Agreement from time to time. No one other than the Agreement - Steward has the right to modify this Agreement. The Eclipse Foundation - is the initial Agreement Steward. The Eclipse Foundation may assign the - responsibility to serve as the Agreement Steward to a suitable separate - entity. Each new version of the Agreement will be given a distinguishing - version number. The Program (including Contributions) may always be - Distributed subject to the version of the Agreement under which it was - received. In addition, after a new version of the Agreement is published, - Contributor may elect to Distribute the Program (including its - Contributions) under the new version. - - Except as expressly stated in Sections 2(a) and 2(b) above, Recipient - receives no rights or licenses to the intellectual property of any - Contributor under this Agreement, whether expressly, by implication, - estoppel or otherwise. All rights in the Program not expressly granted - under this Agreement are reserved. Nothing in this Agreement is intended - to be enforceable by any entity that is not a Contributor or Recipient. - No third-party beneficiary rights are created under this Agreement. - - Exhibit A - Form of Secondary Licenses Notice - - "This Source Code may also be made available under the following - Secondary Licenses when the conditions for such availability set forth - in the Eclipse Public License, v. 2.0 are satisfied: {name license(s), - version(s), and exceptions or additional permissions here}." - - Simply including a copy of this Agreement, including this Exhibit A - is not sufficient to license the Source Code under Secondary Licenses. - - If it is not possible or desirable to put the notice in a particular - file, then You may include the notice in a location (such as a LICENSE - file in a relevant directory) where a recipient would be likely to - look for such a notice. - - You may add additional accurate notices of copyright ownership. - ---- - -## The GNU General Public License (GPL) Version 2, June 1991 - - Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 51 Franklin Street, Fifth Floor - Boston, MA 02110-1335 - USA - - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - Preamble - - The licenses for most software are designed to take away your freedom to - share and change it. By contrast, the GNU General Public License is - intended to guarantee your freedom to share and change free software--to - make sure the software is free for all its users. This General Public - License applies to most of the Free Software Foundation's software and - to any other program whose authors commit to using it. (Some other Free - Software Foundation software is covered by the GNU Library General - Public License instead.) You can apply it to your programs, too. - - When we speak of free software, we are referring to freedom, not price. - Our General Public Licenses are designed to make sure that you have the - freedom to distribute copies of free software (and charge for this - service if you wish), that you receive source code or can get it if you - want it, that you can change the software or use pieces of it in new - free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid anyone - to deny you these rights or to ask you to surrender the rights. These - restrictions translate to certain responsibilities for you if you - distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether gratis - or for a fee, you must give the recipients all the rights that you have. - You must make sure that they, too, receive or can get the source code. - And you must show them these terms so they know their rights. - - We protect your rights with two steps: (1) copyright the software, and - (2) offer you this license which gives you legal permission to copy, - distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain - that everyone understands that there is no warranty for this free - software. If the software is modified by someone else and passed on, we - want its recipients to know that what they have is not the original, so - that any problems introduced by others will not reflect on the original - authors' reputations. - - Finally, any free program is threatened constantly by software patents. - We wish to avoid the danger that redistributors of a free program will - individually obtain patent licenses, in effect making the program - proprietary. To prevent this, we have made it clear that any patent must - be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and - modification follow. - - TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION - - 0. This License applies to any program or other work which contains a - notice placed by the copyright holder saying it may be distributed under - the terms of this General Public License. The "Program", below, refers - to any such program or work, and a "work based on the Program" means - either the Program or any derivative work under copyright law: that is - to say, a work containing the Program or a portion of it, either - verbatim or with modifications and/or translated into another language. - (Hereinafter, translation is included without limitation in the term - "modification".) Each licensee is addressed as "you". - - Activities other than copying, distribution and modification are not - covered by this License; they are outside its scope. The act of running - the Program is not restricted, and the output from the Program is - covered only if its contents constitute a work based on the Program - (independent of having been made by running the Program). Whether that - is true depends on what the Program does. - - 1. You may copy and distribute verbatim copies of the Program's source - code as you receive it, in any medium, provided that you conspicuously - and appropriately publish on each copy an appropriate copyright notice - and disclaimer of warranty; keep intact all the notices that refer to - this License and to the absence of any warranty; and give any other - recipients of the Program a copy of this License along with the Program. - - You may charge a fee for the physical act of transferring a copy, and - you may at your option offer warranty protection in exchange for a fee. - - 2. You may modify your copy or copies of the Program or any portion of - it, thus forming a work based on the Program, and copy and distribute - such modifications or work under the terms of Section 1 above, provided - that you also meet all of these conditions: - - a) You must cause the modified files to carry prominent notices - stating that you changed the files and the date of any change. - - b) You must cause any work that you distribute or publish, that in - whole or in part contains or is derived from the Program or any part - thereof, to be licensed as a whole at no charge to all third parties - under the terms of this License. - - c) If the modified program normally reads commands interactively - when run, you must cause it, when started running for such - interactive use in the most ordinary way, to print or display an - announcement including an appropriate copyright notice and a notice - that there is no warranty (or else, saying that you provide a - warranty) and that users may redistribute the program under these - conditions, and telling the user how to view a copy of this License. - (Exception: if the Program itself is interactive but does not - normally print such an announcement, your work based on the Program - is not required to print an announcement.) - - These requirements apply to the modified work as a whole. If - identifiable sections of that work are not derived from the Program, and - can be reasonably considered independent and separate works in - themselves, then this License, and its terms, do not apply to those - sections when you distribute them as separate works. But when you - distribute the same sections as part of a whole which is a work based on - the Program, the distribution of the whole must be on the terms of this - License, whose permissions for other licensees extend to the entire - whole, and thus to each and every part regardless of who wrote it. - - Thus, it is not the intent of this section to claim rights or contest - your rights to work written entirely by you; rather, the intent is to - exercise the right to control the distribution of derivative or - collective works based on the Program. - - In addition, mere aggregation of another work not based on the Program - with the Program (or with a work based on the Program) on a volume of a - storage or distribution medium does not bring the other work under the - scope of this License. - - 3. You may copy and distribute the Program (or a work based on it, - under Section 2) in object code or executable form under the terms of - Sections 1 and 2 above provided that you also do one of the following: - - a) Accompany it with the complete corresponding machine-readable - source code, which must be distributed under the terms of Sections 1 - and 2 above on a medium customarily used for software interchange; or, - - b) Accompany it with a written offer, valid for at least three - years, to give any third party, for a charge no more than your cost - of physically performing source distribution, a complete - machine-readable copy of the corresponding source code, to be - distributed under the terms of Sections 1 and 2 above on a medium - customarily used for software interchange; or, - - c) Accompany it with the information you received as to the offer to - distribute corresponding source code. (This alternative is allowed - only for noncommercial distribution and only if you received the - program in object code or executable form with such an offer, in - accord with Subsection b above.) - - The source code for a work means the preferred form of the work for - making modifications to it. For an executable work, complete source code - means all the source code for all modules it contains, plus any - associated interface definition files, plus the scripts used to control - compilation and installation of the executable. However, as a special - exception, the source code distributed need not include anything that is - normally distributed (in either source or binary form) with the major - components (compiler, kernel, and so on) of the operating system on - which the executable runs, unless that component itself accompanies the - executable. - - If distribution of executable or object code is made by offering access - to copy from a designated place, then offering equivalent access to copy - the source code from the same place counts as distribution of the source - code, even though third parties are not compelled to copy the source - along with the object code. - - 4. You may not copy, modify, sublicense, or distribute the Program - except as expressly provided under this License. Any attempt otherwise - to copy, modify, sublicense or distribute the Program is void, and will - automatically terminate your rights under this License. However, parties - who have received copies, or rights, from you under this License will - not have their licenses terminated so long as such parties remain in - full compliance. - - 5. You are not required to accept this License, since you have not - signed it. However, nothing else grants you permission to modify or - distribute the Program or its derivative works. These actions are - prohibited by law if you do not accept this License. Therefore, by - modifying or distributing the Program (or any work based on the - Program), you indicate your acceptance of this License to do so, and all - its terms and conditions for copying, distributing or modifying the - Program or works based on it. - - 6. Each time you redistribute the Program (or any work based on the - Program), the recipient automatically receives a license from the - original licensor to copy, distribute or modify the Program subject to - these terms and conditions. You may not impose any further restrictions - on the recipients' exercise of the rights granted herein. You are not - responsible for enforcing compliance by third parties to this License. - - 7. If, as a consequence of a court judgment or allegation of patent - infringement or for any other reason (not limited to patent issues), - conditions are imposed on you (whether by court order, agreement or - otherwise) that contradict the conditions of this License, they do not - excuse you from the conditions of this License. If you cannot distribute - so as to satisfy simultaneously your obligations under this License and - any other pertinent obligations, then as a consequence you may not - distribute the Program at all. For example, if a patent license would - not permit royalty-free redistribution of the Program by all those who - receive copies directly or indirectly through you, then the only way you - could satisfy both it and this License would be to refrain entirely from - distribution of the Program. - - If any portion of this section is held invalid or unenforceable under - any particular circumstance, the balance of the section is intended to - apply and the section as a whole is intended to apply in other - circumstances. - - It is not the purpose of this section to induce you to infringe any - patents or other property right claims or to contest validity of any - such claims; this section has the sole purpose of protecting the - integrity of the free software distribution system, which is implemented - by public license practices. Many people have made generous - contributions to the wide range of software distributed through that - system in reliance on consistent application of that system; it is up to - the author/donor to decide if he or she is willing to distribute - software through any other system and a licensee cannot impose that choice. - - This section is intended to make thoroughly clear what is believed to be - a consequence of the rest of this License. - - 8. If the distribution and/or use of the Program is restricted in - certain countries either by patents or by copyrighted interfaces, the - original copyright holder who places the Program under this License may - add an explicit geographical distribution limitation excluding those - countries, so that distribution is permitted only in or among countries - not thus excluded. In such case, this License incorporates the - limitation as if written in the body of this License. - - 9. The Free Software Foundation may publish revised and/or new - versions of the General Public License from time to time. Such new - versions will be similar in spirit to the present version, but may - differ in detail to address new problems or concerns. - - Each version is given a distinguishing version number. If the Program - specifies a version number of this License which applies to it and "any - later version", you have the option of following the terms and - conditions either of that version or of any later version published by - the Free Software Foundation. If the Program does not specify a version - number of this License, you may choose any version ever published by the - Free Software Foundation. - - 10. If you wish to incorporate parts of the Program into other free - programs whose distribution conditions are different, write to the - author to ask for permission. For software which is copyrighted by the - Free Software Foundation, write to the Free Software Foundation; we - sometimes make exceptions for this. Our decision will be guided by the - two goals of preserving the free status of all derivatives of our free - software and of promoting the sharing and reuse of software generally. - - NO WARRANTY - - 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO - WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. - EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR - OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, - EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED - WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE - ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH - YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL - NECESSARY SERVICING, REPAIR OR CORRECTION. - - 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN - WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY - AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR - DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL - DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM - (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED - INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF - THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR - OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. - - END OF TERMS AND CONDITIONS - - How to Apply These Terms to Your New Programs - - If you develop a new program, and you want it to be of the greatest - possible use to the public, the best way to achieve this is to make it - free software which everyone can redistribute and change under these terms. - - To do so, attach the following notices to the program. It is safest to - attach them to the start of each source file to most effectively convey - the exclusion of warranty; and each file should have at least the - "copyright" line and a pointer to where the full notice is found. - - One line to give the program's name and a brief idea of what it does. - Copyright (C) - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2 of the License, or - (at your option) any later version. - - This program is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1335 USA - - Also add information on how to contact you by electronic and paper mail. - - If the program is interactive, make it output a short notice like this - when it starts in an interactive mode: - - Gnomovision version 69, Copyright (C) year name of author - Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type - `show w'. This is free software, and you are welcome to redistribute - it under certain conditions; type `show c' for details. - - The hypothetical commands `show w' and `show c' should show the - appropriate parts of the General Public License. Of course, the commands - you use may be called something other than `show w' and `show c'; they - could even be mouse-clicks or menu items--whatever suits your program. - - You should also get your employer (if you work as a programmer) or your - school, if any, to sign a "copyright disclaimer" for the program, if - necessary. Here is a sample; alter the names: - - Yoyodyne, Inc., hereby disclaims all copyright interest in the - program `Gnomovision' (which makes passes at compilers) written by - James Hacker. - - signature of Ty Coon, 1 April 1989 - Ty Coon, President of Vice - - This General Public License does not permit incorporating your program - into proprietary programs. If your program is a subroutine library, you - may consider it more useful to permit linking proprietary applications - with the library. If this is what you want to do, use the GNU Library - General Public License instead of this License. - ---- - -## CLASSPATH EXCEPTION - - Linking this library statically or dynamically with other modules is - making a combined work based on this library. Thus, the terms and - conditions of the GNU General Public License version 2 cover the whole - combination. - - As a special exception, the copyright holders of this library give you - permission to link this library with independent modules to produce an - executable, regardless of the license terms of these independent - modules, and to copy and distribute the resulting executable under - terms of your choice, provided that you also meet, for each linked - independent module, the terms and conditions of the license of that - module. An independent module is a module which is not derived from or - based on this library. If you modify this library, you may extend this - exception to your version of the library, but you are not obligated to - do so. If you do not wish to do so, delete this exception statement - from your version. diff --git a/install/jacc/bin/build.xml b/install/jacc/bin/build.xml deleted file mode 100644 index bd12ae940a..0000000000 --- a/install/jacc/bin/build.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/install/jacc/bin/certificates/README b/install/jacc/bin/certificates/README deleted file mode 100644 index 47bc5fda80..0000000000 --- a/install/jacc/bin/certificates/README +++ /dev/null @@ -1,14 +0,0 @@ -CTS Client certificate ----------------------- -This directory contains CTS client certificate stored in different file formats. - -1) cts_cert - This file is used for importing cts client cert - into a truststore . - -2) clientcert.jks - This file is used by the JSSE runtime - to identify CTS client's identity - -3) clientcert.p12 - This file contains cts client cert in pkcs12 format. - - -Note: All 3 files in this directory contains the same certificate named "cts" diff --git a/install/jacc/bin/certificates/clientcert.jks b/install/jacc/bin/certificates/clientcert.jks deleted file mode 100644 index 129260a522..0000000000 Binary files a/install/jacc/bin/certificates/clientcert.jks and /dev/null differ diff --git a/install/jacc/bin/certificates/clientcert.p12 b/install/jacc/bin/certificates/clientcert.p12 deleted file mode 100644 index 409e41e673..0000000000 Binary files a/install/jacc/bin/certificates/clientcert.p12 and /dev/null differ diff --git a/install/jacc/bin/certificates/cts_cert b/install/jacc/bin/certificates/cts_cert deleted file mode 100644 index 0c3863c852..0000000000 Binary files a/install/jacc/bin/certificates/cts_cert and /dev/null differ diff --git a/install/jacc/bin/deploy/glassfish.xml b/install/jacc/bin/deploy/glassfish.xml deleted file mode 100644 index 8acdefd5eb..0000000000 --- a/install/jacc/bin/deploy/glassfish.xml +++ /dev/null @@ -1,295 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ******************************************************* - Java EE PROFILE in use, Deploying EJB-based-JACC tests. - ******************************************************* - - - - - - - ******************************************************* - Web PROFILE in use, NOT deploying EJB-based-JACC tests. - ******************************************************* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -IMPORTANT: -You will need to restart the server for the new users to take effect. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/install/jacc/bin/deploy/noop.xml b/install/jacc/bin/deploy/noop.xml deleted file mode 100644 index b79f0273c0..0000000000 --- a/install/jacc/bin/deploy/noop.xml +++ /dev/null @@ -1,24 +0,0 @@ - - - - - - - - diff --git a/install/jacc/bin/initdb.xml b/install/jacc/bin/initdb.xml deleted file mode 100644 index e7272e65b1..0000000000 --- a/install/jacc/bin/initdb.xml +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/install/jacc/bin/sig-test-pkg-list.txt b/install/jacc/bin/sig-test-pkg-list.txt deleted file mode 100755 index ef5c3191b4..0000000000 --- a/install/jacc/bin/sig-test-pkg-list.txt +++ /dev/null @@ -1,24 +0,0 @@ -# -# Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 -# - -## -# This file contains a list of all the packages -# contained in the signature files for this -# deliverable. This file is used to exclude valid -# sub-packages from being verified when their -# parent package's signature is checked. -## -jakarta.security.jacc diff --git a/install/jacc/bin/sig-test.map b/install/jacc/bin/sig-test.map deleted file mode 100644 index 5f35714e8c..0000000000 --- a/install/jacc/bin/sig-test.map +++ /dev/null @@ -1,51 +0,0 @@ -# -# Copyright (c) 2018, 2021 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 -# - -############################################################### -# The signature test mapping file for the JACC TCK. This file -# should be formatted as a standard java properties file. The -# name is the package name and the value is the version of the -# package that should be tested by the signature tests. -# -# Note: Recording the signatures of a package includes all -# child packages. The signature test tool looks for -# the best signature file to use when playing back -# signatures. Meaning if we have a jakarta.servlet -# signature file and a jakarta.servlet.jsp signature file, -# the signature test tool will use the jakarta.servlet.jsp -# signature file to verify the jakarta.servlet.jsp package -# signatures even though the jakarta.servlet signature -# file contains the jakarta.servlet.jsp package signatures. -# The signatures are in both files (since the API Check -# tool records child package signatures and there does -# not seem to be a way to turn this feature off) but the -# jakarta.servlet.jsp signature file can vary independent -# of the jakarta.servlet signature file. -# -# Command used to record the JACC signatures in reflective mode -# -# cd to: $TS_HOME/src/com/sun/ts/tests/signaturetest -# -# run: $ANT_HOME/bin/ant -f record-build.xml \ -# -Dsig.source=$JAVAEE_HOME/lib/jakartaee.jar \ -# -Dmap.file=$TS_HOME/bin/sig-test.map record.sig.batch -# -############################################################### - -# Authorization -jakarta.security.jacc=3.0 - - diff --git a/install/jacc/bin/ts.jte b/install/jacc/bin/ts.jte deleted file mode 100644 index b7b17f08ab..0000000000 --- a/install/jacc/bin/ts.jte +++ /dev/null @@ -1,552 +0,0 @@ -# -# Copyright (c) 2008, 2021 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 -# - -######################################################################### -## -## JavaTest Environment file for Java Authorization Contract for Containers -## Standalone Test Suite (JACC - JSR 115) -## -## Environment specific properties in this file will likely -## have to be modified prior to running the JACC TCK. -## Instructions for modifying these properties are contained in this -## file. -## -## This file is processed by an external tool that helps generate the -## TCK documents. Therefore this file has a standard format that must -## be followed. This file is a standard Java Properties file with -## very specific comment formatting. Users can write property specific -## comments by using the property name and an ampersand (@). As an -## example the following comment applies to the foo.bar property: -## # @foo.bar - This is a comment pertaining to foo.bar -## # that spans multiple lines. -## This comment must be preceded by a single hash (#) charater and -## the property name must be prepended with an ampersand (@). The -## comment can appear anywhere in the ts.jte file. If users have -## comments that belong in ts.jte but DO NOT pertain to a particular -## property the user must start the comment with at least 2 hash (#) -## characters. The following is a valid non-property comment: -## ## A valid non-property comment -## ## that spans multiple lines. -######################################################################### - -######################################################################## -## Javatest batch mode work directory and report directory, and policy for -## handling existing work and report directories. These properties affects -## runclient and report targets, but not gui target. -## To disable generating test report, unset report.dir, or set it to "none" -## either here or from command line, as in the following command: -## ant runclient -Dreport.dir="none" -## -# @if.existing.work.report.dirs specifies how existing work.dir and -# report.dir will be handled, and it must be one of the following values: -# overwrite overwrites all content in work.dir and report.dir -# backup moves all content in work.dir and report.dir to -# work.dir_time_day_bak and report.dir_time_day_bak, -# respectively -# append reuses and preserves the existing work.dir and report.dir -# auto lets the build files decide which mode to use -# (overwrite, backup or append). the value is determined -# like this: -# if.existing.work.report.dirs == auto -# if in TCK workspace -# if.existing.work.report.dirs = overwrite -# else we are in a distribution bundle -# if.existing.work.report.dirs = append -# end if -# else -# if.existing.work.report.dirs = value in this file -# end if -######################################################################## -work.dir=/tmp/JTwork -report.dir=/tmp/JTreport -if.existing.work.report.dirs=auto - -######################################################################## -# @javatest.timeout.factor This property specifies the scale factor used by -# Javatest to adjust the time JavaTest will wait for a given test to -# complete before returning failure. For instance if the default test timeout -# is 5 minutes, this value will be multiplied by 5 minutes to determine -# the total timeout delay. Note: this value only works with Javatest's -# batch mode (runclient). When using the Javatest GUI users must change -# this timeout factor in the GUI. Configure -> Edit Configuration -> View -# -> choose Standard Values -> select tab Execution -> set Time Factor. -######################################################################## -javatest.timeout.factor=1.0 - -## Settings for Vendor JACC Implementation -jacc.home=/sun/glassfish4/glassfish -jacc.host=localhost - -######################################################################## -# @orb.port The port number the vendor implementation is listening -# to for service requests. -######################################################################## -orb.port=3699 - - -########################################################################### -# @endorsed.dirs If using JavaSE 6 or above and you provide newer versions -# of technologies than those contained in Java SE 6, verify -# that the property endorsed.dirs is set to the location of -# the VI api jars for those technologies you wish to -# overrride. For example, JavaSE 6 contains an -# implementation of JAXWS 2.0 which will conflict with -# JAXWS 2.1, therefore this property would need to be set -# so that JAXWS 2.1 would be used during the building of -# tests and during test execution. -# -########################################################################### -endorsed.dirs=${jacc.home}/modules/endorsed - -######################################################################## -# The following properties are implementation specific and are needed -# to set information specific to your jacc provider. -######################################################################## -s1as.admin.user=admin -s1as.admin.passwd= -s1as.admin.host=${jacc.host} -s1as.admin.port=4848 -s1as.admin=${jacc.home}/bin/asadmin -s1as.server=server -s1as.domain.dir=${jacc.home}/domains -s1as.domain.name=domain1 -s1as.domain=${s1as.domain.dir}/${s1as.domain.name} -s1as.asenv.loc=${jacc.home}/config -s1as.imqbin.loc=${jacc.home}/imq/bin -s1as.lib=${jacc.home}/lib -s1as.imq.share.lib=${jacc.home}/imq/lib -s1as.jvm.options=-Doracle.jdbc.J2EE13Compliant=true -s1as.java.endorsed.dirs=${endorsed.dirs} -s1as.applicationRoot=c: - -############################################################### -# @extension.dir - The extension directory for the app server under test. -# -# Note: App server vendors will need to set this to their -# app server's extension directory. The config.vi -# target will copy the library jars(jacctck.jar,tsharness.jar) -# to this location. -############################################################### -extension.dir=${s1as.domain}/lib - -############################################################################## -# @sjsas.master.password -- Used as default password for keystore & truststore -# Defaults to changeit. -############################################################################## -sjsas.master.password=changeit - -############################################################### -# @instance.listenerName - Default value for the iiop listener -# for your instance. Users will -# most likely not need to change this. -############################################################### -instance.listenerName=orb-listener-1 - - -############################################################### -## When installing TCK/RI on Windows, users must install the TCK and -## the RI on the same drive. Also note that you should never -## specify drive letters in any path defined in this properties -## file. -############################################################### -## Users must set this property when running on Windows. The -## appropriate value on Windows is a semi-colon (;). If you are -## not running on Windows leave this property set to its default -## value of colon (:) for other . -############################################################### -pathsep=: - -############################################################### -## The directory separator for the platform. User should not change -## this property. -############################################################### -dirsep=/ - -############################################################### -# @ts.display -- location to display TCK output on Unix -############################################################### -ts.display=:0.0 - -############################################################### -# @tz - your local timezone. For valid values, consult your -# Operating System documentation. -############################################################### -tz=US/Eastern - - -############################################################### -## Configure the behavior of whether tables will be created when -## ant init.database is invoked. -# -# NOTE: The JACC Specification permits -# DDL generation to be supported by an implementation but -# it is not required. -# -# @create.cmp.tables -# - When set to false, the persistence provider -# is responsible for creating tables -# -# - When set to true, init.datbaseName will -# create the tables used by the persistence provider -# -############################################################### -create.cmp.tables=true - -############################################################### -# -# The sql for the tables are contained in: -# -# $TS_HOME/[databaseName]/sql/[databaseName].ddl.persistence.sql -# -# @databaseName -# Defines which database will be used for certification. -# This property will be used to determine the corresponding sql -# to intialize and can be one of the following: -# -# - derby -# - mysql -# - pointbase -# - sybase -# - db2 -# - mssqlserver -# - oracle -# - postgresql -# -# If using a database other than above, you need to create -# your own DDL files but can use these files for reference of what -# tables are required. -# -############################################################### -databaseName=derby - -############################################################### -# @jdbc.lib.class.path - This property is used by the -# database.classes properties to point to -# where the JDBC drivers live. -############################################################### -jdbc.lib.class.path=${jacc.home}/javadb/lib -# -############################################################### -## -## Info to be Used for DataBase Initialization -## -############################################################### -database.dbName=derbyDB -database.server=${jacc.host} -database.port=1527 -database.user=cts1 -database.passwd=cts1 -database.url=jdbc:derby://${database.server}:${database.port}/${database.dbName};create=true -database.driver=org.apache.derby.jdbc.ClientDriver -database.classes=${jdbc.lib.class.path}/derbyclient.jar${pathsep}${jdbc.lib.class.path}/derbyshared.jar${pathsep}${jdbc.lib.class.path}/derbytools.jar -database.dataSource=org.apache.derby.jdbc.ClientDataSource -database.properties=DatabaseName\=\"${database.dbName}\":user\=${database.user}:password\=${database.passwd}:serverName\=${database.server}:portNumber=${database.port} - -############################################################### -## Schema locations for Persistence xml files. -## Used for xml validation when building tests. -############################################################### -alt.schema.dir=${lib.dir}/schemas - -############################################################### -## Classpath properties required by the JACC TCK: -# @jacc.classes -- Classes required by RI -# @ts.run.classpath -- Classes needed for test run -# @ts.harness.classpath -- Classes required by javatest -# @ts.classpath -- Classes used to build the Persistence tests -# @ts.lib.classpath -- Classes used to build cts.jar -############################################################### - -ri.lib=${jacc.home}/modules -lib.dir=${ts.home}/lib - -jacc.classes=${ri.lib}/jakarta.authorization-api.jar:${ri.lib}/jakarta.security.auth.message-api.jar:${ri.lib}/common-util.jar:${ri.lib}/container-common.jar:${ri.lib}/jakarta.annotation-api.jar:${ri.lib}/jakarta.resource-api.jar:${ri.lib}/jmxremote_optional-repackaged.jar:${ri.lib}/ldapbp-repackaged.jar:${ri.lib}/security.jar:${ri.lib}/web-core.jar:${ri.lib}/web-glue.jar:${ri.lib}/websecurity.jar:${ri.lib}/jakarta.servlet-api.jar:${ri.lib}/jakarta.ejb-api.jar:${ri.lib}/jakarta.persistence.jar:${ri.lib}/jakarta.transaction-api.jar:${ri.lib}/jakarta.jms-api.jar:${ri.lib}/jakarta.servlet.jsp-api.jar - -ts.run.classpath=${ts.home}/classes:${database.classes}:${jacc.classes} - -ts.harness.classpath=${lib.dir}/tsharness.jar:${lib.dir}/sigtest.jar:${lib.dir}/commons-logging-1.1.3.jar:${lib.dir}/commons-httpclient-3.1.jar:${ts.run.classpath}:${lib.dir}/javatest.jar:${ant.home}/lib/ant.jar - -#classpath used for building JACC tests only (DO NOT MODIFY) -ts.classpath=${ts.harness.classpath}:${jacc.classes} - -######################################################################## -## Common environment for both ts_unix and ts_win32 -# -# @command.testExecute - This command is used to execute any test -# clients which are not run inside an -# application client container. For example, -# any URL clients or standalone java clients -# would be executed with this command. Some -# test directories which make use of this command -# are servlet and jsp. -# -######################################################################## -command.testExecute=com.sun.ts.lib.harness.ExecTSTestCmd \ - CLASSPATH=${ts.harness.classpath}:\ - ${JAVA_HOME}/../lib/tools.jar \ - DISPLAY=${ts.display} \ - HOME="${user.home}" \ - windir=${windir} \ - SYSTEMROOT=${SYSTEMROOT} \ - ${JAVA_HOME}/bin/java \ - -Dcts.tmp=$harness.temp.directory \ - -Dlog.file.location=${log.file.location} \ - -Djava.security.policy=${bin.dir}/harness.policy \ - -Dcom.sun.aas.installRoot=${jacc.home} \ - -Djava.protocol.handler.pkgs=javax.net.ssl \ - -Djavax.net.ssl.keyStore=${bin.dir}/certificates/clientcert.jks \ - -Djavax.net.ssl.keyStorePassword=changeit \ - -Djavax.net.ssl.trustStore=${jacc.home}/domains/domain1/config/cacerts.jks \ - -Ddeliverable.class=${deliverable.class} $testExecuteClass $testExecuteArgs - - -######################################################################### -## Environment for ts_unix -## test execution command inherit from common environment -## defined above: testExecute. -## If you need to override them, uncomment them in the -## following section. -######################################################################### -env.ts_unix.menu=true -##env.ts_unix.command.testExecute= - -######################################################################## -## Environment for ts_win32 -## test execution commands inherit from common environment -## defined above: testExecute. -## If you need to override them, uncomment them in the -## following section. -######################################################################## -env.ts_win32.menu=true -##env.ts_win32.command.testExecute= - -######################################################################### -# @jimage.dir: This property specifies the directory where Java 11+ -# modules will be expanded by the jimage tool for use -# in sigTestClasspath -# @sigTestClasspath: This property must be set when running signature -# tests. This property should be set to a list of -# jar files and/or directories which contain your -# Java Persistence and Java SE classes. Paths must be -# separated by the appropriate path separator -# (';' windows, ':' Unixes). -######################################################################### -jimage.dir=${ts.home}/tmp/jdk-bundles - -sigTestClasspath=${jacc.home}/modules/jakarta.authorization-api.jar:${jacc.home}/modules/jakarta.security.auth.message-api.jar${pathsep}${jimage.dir}/java.base${pathsep}${jimage.dir}/java.rmi${pathsep}${jimage.dir}/java.sql${pathsep}${jimage.dir}/java.naming - - -######################################################################## -## These properties are used by the harness. "harness.log.port" -## specifies the port that server components use to send logging -## output back to JavaTest. If the default port # is not available -## on the machine running JavaTest, then you can set it here. -## -## "harness.log.traceflag" is used to turn on/off verbose debugging output -## for the tests. -## -## "harness.executeMode" is used to run the harness in the following modes -## of execution: -## 0 - default (deploy, run, undeploy) -## 1 - deploy only -## 2 - run only -## 3 - undeploy only -## 4 - deploy and run only -## -## -## @harness.socket.retry.count - denotes the number of time we should -## attempt to create a server socket when intilizing a test -## client. The socket is used for logging purposes. -## -######################################################################## -harness.temp.directory=${ts.home}/tmp -harness.log.port=2000 -harness.log.traceflag=true -harness.executeMode=0 -harness.log.delayseconds=1 -harness.socket.retry.count=10 - -############################################################### -## These properties must be set to tell the Test harness the -## class names of your porting class implementations. -# -# @porting.ts.url.class.1 VI of -# com.sun.ts.lib.porting.TSURLInterface -############################################################### -porting.ts.url.class.1=com.sun.ts.lib.implementation.sun.common.SunRIURL - -################################################################### -# @log.file.location This property is used by JACC tests to create -# and analyze provider logs. Specify a log directory -# -################################################################### -log.file.location=${jacc.home}/domains/domain1/logs - -##################################################################### -## These properties must specify the host and port of the web server, -## in which the servlets and JSPs are deployed. -# -# @webServerHost hostname for the Vendor's Web Server -# @webServerPort port number of the Vendor's Web Server -##################################################################### -webServerHost=${jacc.host} -webServerPort=8080 - -######################################################################### -## The following properties must be set before running any security -## related tests. The properties user, password, authuser, authpassword, -## and nobodyuser must be set. -## -## The value for user, password, authuser, and authpassword need to be set -## exactly as they are set in the container/server. -# -# @user User defined to exercise rolemapping feature -# @password Associated password for the user -# @authuser User defined to exercise rolemapping feature -# @authpassword Associated password for the authuser -######################################################################### -user=j2ee -password=j2ee -authuser=javajoe -authpassword=javajoe - -############################################################### -# @securedWebServicePort must be set to run ssl tests -# server's secured webservice port. -############################################################### -securedWebServicePort=8181 - -################################################################### -################################################################### -################################################################### -## PROPERTIES USERS WILL NOT HAVE TO SET ARE BELOW -################################################################### -################################################################### -################################################################### - -##build level -##1: compile only -##2: compile and build component archives (e.g., jar's, war's) -##3: compile and build component and application archives -##default is set to 3 -build.level=2 - -############################################################### -## These properties must be set to tell the Test harness the -## class names of your porting class implementations. By default -## both property sets below point to Sun RI specific classes. To## run interoperability tests, the ".2" set of properties should -## always point to Sun RI classes. The ".1" set should point to## implementations that work in your specific Java EE environment. -# -# @porting.ts.url.class.1 VI of -# com.sun.ts.lib.porting.TSURLInterface -# @porting.ts.HttpsURLConnection.class.1 VI of -# com.sun.ts.lib.porting.TSHttpsURLConnectionInterface -############################################################### -porting.ts.url.class.1=com.sun.ts.lib.implementation.sun.common.SunRIURL -porting.ts.HttpsURLConnection.class.1=com.sun.ts.lib.implementation.sun.javaee.SunRIHttpsURLConnection - -##Porting class names for Sun RI Java EE Implementation #2 (must be Sun's RI) -porting.ts.url.class.2=com.sun.ts.lib.implementation.sun.common.SunRIURL -porting.ts.HttpsURLConnection.class.2=com.sun.ts.lib.implementation.sun.javaee.SunRIHttpsURLConnection - - -############################################################### -## JPA Deliverable Class -## DO NOT CHANGE THIS PROPERTY -############################################################### -deliverable.class=com.sun.ts.lib.deliverable.jacc.JACCDeliverable - -####################################################################### -## platform.mode is used to tell the enviroment we are in standalone -## mode -## DO NOT CHANGE THIS PROPERTY -###################################################################### -platform.mode=standalone - -####################################################################### -## Location of ts_home -## DO NOT CHANGE THIS PROPERTY -###################################################################### - -ts_home=${ts.home} - -################################################################### -## Deliverables wanting ts.* packaging tasks to add extension list -## attributes to the manifest files must set this property to true. -################################################################### -#create.manifest.extension.entries= - -###################################################################### -## Deliverables must set this property to the name of the deliverable -## specific library jar file (iff create.manifest.extension.entries -## is set to true) -###################################################################### -tslib.name=jacctck - -######################################################################## -## Level of Vendor Java EE Implementation -# @javaee.level The level of Java EE support for the implementation -# test. This level is used to determine Java EE support -# when deploying archives - whether ears are supported, -# etc. Currently 2 values are supported: -# -# full - for full Java EE Platform support -# web - for Java EE Web Profile [plus optional tech.] -######################################################################## -javaee.level=web - - -#################################################################### -# Implementation Property Settings for Vendor and RI -# -# The jacctck provides support for glassfish implementation out of the box. -# -# Here are the common properties that need to be defined for the common -# implementation functionality: -# -# @impl.vi This property must be set to the Vendor implementation -# under test. -# @impl.vi.deploy.dir This property must be set to the deploy directory for -# the Vendor implementation. -# @impl.vi.host This property must be set to the webserver host where -# the Vendor implementation is running. -# @impl.vi.port This property must be set to the webserver port where -# the Vendor implementation is running. -# @impl.ri This property must be set to the RI implementation -# under test. -# @impl.ri.deploy.dir This property must be set to the deploy directory for -# the RI implementation. -# @impl.ri.host This property must be set to the webserver host where -# the RI implementation is running. -# @impl.ri.port This property must be set to the webserver port where -# the RI implementation is running. -# -# @impl.deploy.timeout.multiplier The time it will wait for deployment to -# succeed or fail -#################################################################### -impl.vi=glassfish -impl.vi.deploy.dir=${s1as.domain}/autodeploy -impl.vi.host=${webServerHost} -impl.vi.port=${webServerPort} - -impl.ri=glassfish -impl.ri.deploy.dir=${s1as.domain}/autodeploy -impl.ri.host=${webServerHost} -impl.ri.port=${webServerPort} - -impl.deploy.timeout.multiplier=30 - - diff --git a/install/jacc/bin/ts.jtx b/install/jacc/bin/ts.jtx deleted file mode 100644 index 800f6d8b92..0000000000 --- a/install/jacc/bin/ts.jtx +++ /dev/null @@ -1,16 +0,0 @@ -# -# Copyright (c) 2008, 2018 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 -# - diff --git a/install/jacc/bin/xml/templates/password.template b/install/jacc/bin/xml/templates/password.template deleted file mode 100644 index deef01c4e9..0000000000 --- a/install/jacc/bin/xml/templates/password.template +++ /dev/null @@ -1,3 +0,0 @@ -AS_ADMIN_MASTERPASSWORD=@sjsas.master.password@ -AS_ADMIN_PASSWORD=@sjsas.admin.password@ -AS_ADMIN_USERPASSWORD=@user.password@ diff --git a/install/jacc/bin/xml/vi.xml b/install/jacc/bin/xml/vi.xml deleted file mode 100755 index 6766664add..0000000000 --- a/install/jacc/bin/xml/vi.xml +++ /dev/null @@ -1,167 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/install/jacc/docs/ReleaseNotes-authorization-2.1.html b/install/jacc/docs/ReleaseNotes-authorization-2.1.html deleted file mode 100644 index df96ce0af8..0000000000 --- a/install/jacc/docs/ReleaseNotes-authorization-2.1.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - - Jakarta Authorization TCK Release Notes - - - -
-

Jakarta EE Authorization Technology Compatibility Kit, Version 2.1

-

Release Notes, May 2022

-
-

Kit Contents

-

The Jakarta EE Authorization, Version 2.1 Technology Compatibility Kit - (TCK) includes the following items:

-
    -
  • Jakarta EE Authorization TCK tests for signature, API, and - End-to-End test
  • -
      -
    • A signature test checks that all of the public - APIs are supported in the Jakarta EE Authorization Version 2.1 - implementation that is being tested
    • -
    • API tests for all of the public APIs under the jakarta.security.jacc - package
    • -
    • End-To-End tests that demonstrate compliance with - the Jakarta EE Authorization 2.1 Specification
    • -
    -
  • Jakarta EE Authorization TCK Users Guide
  • -
-
-

Platform Notes

-

The Jakarta EE Authorization TCK tests have been built with JDK 11 - and tested with JDK 11 and JDK 17.

-

The Jakarta EE Authorization TCK tests have been run on the following - platforms:

-
    -
  • CentOS Linux 7
  • -
  • Alpine Linux v3.12
  • -
-

The Jakarta EE Authorization TCK tests have been run against the Jakarta - EE Authorization 2.1 Compatible Implementation (CI), Eclipse GlassFish 7.0 -

-

Jakarta Enterprise Beans was formerly known as Enterprise Java Beans and - abbreviated EJB. References to EJB below refer to Jakarta Enterprise - Beans. Use of this term, as commands, switches, or keywords have not been - revised.

-
-

Installing, Setting Up, and Running the - Jakarta EE Authorization TCK

-

Refer to the Jakarta EE Authorization TCK 2.1 User's Guide - (HTML, - PDF) - for complete instructions on installing, setting up, and running the - Jakarta EE Authorization TCK.

-

The online version of the JT Harness version 5.0 documentation is - available here.

-
-

Jakarta EE Authorization TCK Requirements, Facts, and Figures

-

The Jakarta EE Authorization TCK requires a minimum of 103 MB of free - disk space:

-
  • WARs: 6
  • -
  • Total tests: 34 -
  • - -

    There are multiple levels of compliance available for Jakarta EE - Authorization certification. Jakarta EE Authorization allows for - certification of the following containers: Web Container, Jakarta - Enterprise Beans Container, or Both. The standalone Jakarta EE - Authorization TCK only concerns itself with Web Container tests and - possibly some Jakarta Enterprise Beans-lite tests (which could be run in a - Web Profile environment). There are keywords available which can be - supplied on the command line which allow isolating the tests for a given - level of certification. (For more on keywords, see the Jakarta EE - Authorization 2.1 TCK User Guide). The list of keywords available for - Jakarta EE Authorization 2.1 TCK is as follows:

    -
      -
    • keyword jacc_web : used to run Web Container tests
    • -
    • keyword jacc_ejb : used to run Jakarta Enterprise - Beans Container tests
    • -
    • keyword jacc_web_profile : used to run WEB and - Jakarta Enterprise Beans Lite Container tests in Web Profile environment -
    • -
    • keyword jacc : used to run all Jakarta EE - Authorization standalone TCK tests
    • -
    -
    -

    Status Information

    -

    Exclude List

    -
    -

    You can find the exclude list in the Jakarta EE Authorization bundle in - <TS_HOME>/bin/ts.jtx. Since the list can change over - time, please be sure to get the latest exclude list from the Jakarta EE - Authorization Specification Web site: https://jakarta.ee/specifications/authorization/2.1/.

    -
    -
    -

    Known Problems and Workarounds

    -

    Running the Jakarta EE Authorization TCK Against Jakara EE compatible - implementation on Windows

    -
    -

    When configuring and running the Jakarta EE Authorization TCK against - the CI on Windows, please make sure to install all related software - (Java SE 11/17, the CI, the Jakarta EE Authorization TCK, etc.) on the same - drive (for example, C:). If you want to install on a drive - other than C:, please be sure to change the following - properties in <TS_HOME>/bin/ts.jte:

    -
    s1as.applicationRoot=c:
    -
    -
    -

    -
    Copyright 2013, 2022 Oracle and/or its affiliates. All - rights reserved.
    -

    - - diff --git a/install/jacc/docs/assertions/api/JACCJavaDocAssertions.html b/install/jacc/docs/assertions/api/JACCJavaDocAssertions.html deleted file mode 100644 index 12c4c8ae80..0000000000 --- a/install/jacc/docs/assertions/api/JACCJavaDocAssertions.html +++ /dev/null @@ -1,799 +0,0 @@ - - - - - -JavaDoc Assertion Detail - - -
    -
    -

    Jakarta Authorization
    2.0
    - JavaDoc Assertion Detail -

    -
    - - - - - - - - - - - -
    TotalsTotalActiveDeprecatedRemoved
    - # of Assertions - 626200
    - # of Required Assertions - 626200
    - # of Optional Assertions - 0000
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDReturnMethod/FieldDescriptionRequiredDeprecatedTestable
    JACC:JAVADOC:1EJBMethodPermissionjakarta.security.jacc.EJBMethodPermission.EJBMethodPermission
    - - ( - String - ,
    String - ) -
    - Creates a new EJBMethodPermission with the specified name and actions. - The name contains the value of the ejb-name element corresponding to an EJB in the application's deployment descriptor. The actions contains a methodSpec. The syntax of the actions parameter is defined as follows: methodNameSpec ::= methodName | emptyString methodInterface ::= Home | LocalHome | Remote | Local | ServiceEndpoint methodInterfaceSpec ::= methodInterface | emptyString methodParams ::= typeName | methodParams comma typeName methodParamsSpec ::= emptyString | methodParams methodSpec ::= null | methodNameSpec | methodNameSpec comma methodInterface | methodNameSpec comma methodInterfaceSpec comma methodParamsSpec A null or empty string methodSpec indicates that the permission applies to all methods of the EJB. A methodSpec with a methodNameSpec of the empty string matches all methods of the EJB that match the methodInterface and methodParams elements of the methodSpec. A methodSpec with a methodInterfaceSpec of the empty string matches all methods of the EJB that match the methodNameSpec and methodParams elements of the methodSpec. A methodSpec without a methodParamsSpec matches all methods of the EJB that match the methodNameSpec and methodInterface elements of the methodSpec. Each typeName appearing in methodParams must be the fully-qualified Java type name of a parameter of the target method. The order of the typeNames in methodParams must match the order of occurence of the corresponding parameters in the method signature of the target method(s). A methodSpec with an empty methodParamsSpec matches all 0 argument methods of the EJB that match the methodNameSpec and methodInterfaceSpec elements of the methodSpec. - true -
    -
    true
    JACC:JAVADOC:2EJBMethodPermissionjakarta.security.jacc.EJBMethodPermission.EJBMethodPermission
    - - ( - String - ,
    String - ,
    String - ,
    String[] - ) -
    - Creates a new EJBMethodPermission with name corresponding to the EJBName and actions composed from methodName, methodInterface, and methodParams. - - true -
    -
    true
    JACC:JAVADOC:3EJBMethodPermissionjakarta.security.jacc.EJBMethodPermission.EJBMethodPermission
    - - ( - String - ,
    String - ,
    Method - ) -
    - Creates a new EJBMethodPermission with name corresponding to the EJBName and actions composed from methodInterface, and the Method object. - A container uses this constructor prior to checking if a caller has permission to call the method of an EJB. - true -
    -
    true
    JACC:JAVADOC:4booleanjakarta.security.jacc.EJBMethodPermission.equals
    - - ( - Object - ) -
    - Checks two EJBMethodPermission objects for equality. - EJBMethodPermission objects are equivalent if they have case sensitive equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - true -
    -
    true
    JACC:JAVADOC:5Stringjakarta.security.jacc.EJBMethodPermission.getActions
    -
    - Returns a String containing a canonical representation of the actions of this EJBMethodPermission. - The Canonical form of an EJBMethodPermission is described by the following syntax description. methodNameSpec ::= methodName | emptyString methodInterface ::= Home | LocalHome | Remote | Local | ServiceEndpoint methodInterfaceSpec ::= methodInterface | emptyString methodParams ::= typeName | methodParams comma typeName methodParamsSpec ::= emptyString | methodParams methodSpec ::= null | methodNameSpec | methodNameSpec comma methodInterface | methodNameSpec comma methodInterfaceSpec comma methodParamsSpec - true -
    -
    true
    JACC:JAVADOC:6intjakarta.security.jacc.EJBMethodPermission.hashCode
    -
    - Returns the hash code value for this EJBMethodPermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value every time it is called on a EJBMethodPermission object. The value returned by hashCode for a particular EJBMethodPermission need not remain consistent from one execution of an application to another. If two EJBMethodPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:7booleanjakarta.security.jacc.EJBMethodPermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this EJBMethodPermission. - For this to be the case, The argument must be an instanceof EJBMethodPermission with name equivalent to that of this EJBMethodPermission, and the methods to which the argument permission applies (as defined in its actions) must be a subset of the methods to which this EJBMethodPermission applies (as defined in its actions) The name and actions comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:8EJBRoleRefPermissionjakarta.security.jacc.EJBRoleRefPermission.EJBRoleRefPermission
    - - ( - String - ,
    String - ) -
    - Creates a new EJBRoleRefPermission with the specified name and actions. - true -
    -
    true
    JACC:JAVADOC:9booleanjakarta.security.jacc.EJBRoleRefPermission.equals
    - - ( - Object - ) -
    - Checks two EJBRoleRefPermission objects for equality. - EJBRoleRefPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - true -
    -
    true
    JACC:JAVADOC:10Stringjakarta.security.jacc.EJBRoleRefPermission.getActions
    -
    - Returns a canonical String representation of the actions of this EJBRoleRefPermission. - - true -
    -
    true
    JACC:JAVADOC:11intjakarta.security.jacc.EJBRoleRefPermission.hashCode
    -
    - Returns the hash code value for this EJBRoleRefPermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value, every time it is called on a EJBRoleRefPermission object. The value returned by hashCode for a particular EJBRoleRefPermission need not remain consistent from one execution of an application to another. If two EJBRoleRefPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:12booleanjakarta.security.jacc.EJBRoleRefPermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this EJBRoleRefPermission. - For this to be the case, The argument must be an instanceof EJBRoleRefPermission with name equivalent to that of this EJBRoleRefPermission, and with the role reference equivalent to that of this EJBRoleRefPermission applies. The name and actions comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:13voidjakarta.security.jacc.PolicyConfiguration.addToExcludedPolicy
    - - ( - PermissionCollection - ) -
    - Used to add excluded policy statements to this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:14voidjakarta.security.jacc.PolicyConfiguration.addToExcludedPolicy
    - - ( - Permission - ) -
    - Used to add a single excluded policy statement to this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:15voidjakarta.security.jacc.PolicyConfiguration.addToRole
    - - ( - String - ,
    PermissionCollection - ) -
    - Used to add permissions to a named role in this PolicyConfiguration. - If the named Role does not exist in the PolicyConfiguration, it is created as a result of the call to this function. It is the job of the Policy provider to ensure that all the permissions added to a role are granted to principals mapped to the role. - true -
    -
    true
    JACC:JAVADOC:16voidjakarta.security.jacc.PolicyConfiguration.addToRole
    - - ( - String - ,
    Permission - ) -
    - Used to add a single permission to a named role in this PolicyConfiguration. - If the named Role does not exist in the PolicyConfiguration, it is created as a result of the call to this function. It is the job of the Policy provider to ensure that all the permissions added to a role are granted to principals mapped to the role. - true -
    -
    true
    JACC:JAVADOC:17voidjakarta.security.jacc.PolicyConfiguration.addToUncheckedPolicy
    - - ( - PermissionCollection - ) -
    - Used to add unchecked policy statements to this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:18voidjakarta.security.jacc.PolicyConfiguration.addToUncheckedPolicy
    - - ( - Permission - ) -
    - Used to add a single unchecked policy statement to this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:19voidjakarta.security.jacc.PolicyConfiguration.commit
    - - ( - - ) -
    - Causes all policy statements to be deleted from this PolicyConfiguration and sets its internal state such that any additional operations attempted on the PolicyConfiguration will be rejected and cause an UnsupportedOperationException to be thrown. - This operation has no affect on any linked PolicyConfigurations other than removing any links involving the deleted PolicyConfiguration. - true -
    -
    true
    JACC:JAVADOC:20voidjakarta.security.jacc.PolicyConfiguration.delete
    -
    - - This method is used to set to inService the state of the policy context whose interface is this Policy- - Configuration Object. Only those policy contexts whose state is inService will be included in the policy - contexts processed by the Policy.refresh method. A policy context whose state is inService may be - returned to the open state by calling the getPolicyConfiguration method of the PolicyConfiguration factory - with the policy context identifier of the policy context. - When the state of a policy context is inService, calling any method other than commit, delete, get- - ContextID, or inService on its PolicyConfiguration Object will cause an UnsupportedOperationException - to be thrown. - -true -
    -
    true
    JACC:JAVADOC:21Stringjakarta.security.jacc.PolicyConfiguration.getContextID
    -
    - This method returns this object's policy context identifier. - true -
    -
    true
    JACC:JAVADOC:22booleanjakarta.security.jacc.PolicyConfiguration.inService
    -
    - Creates a relationship between this configuration and another such that they share the same principal-to-role mappings. - PolicyConfigurations are linked to apply a common principal-to-role mapping to multiple seperately manageable PolicyConfigurations, as is required when an application is composed of multiple modules. Note that the policy statements which comprise a role, or comprise the excluded or unchecked policy collections in a PolicyConfiguration are unaffected by the configuration being linked to another. - true -
    -
    true
    JACC:JAVADOC:23voidjakarta.security.jacc.PolicyConfiguration.linkConfiguration
    - - ( - PolicyConfiguration - ) -
    - This method is used to determine if the policy context whose interface is this PolicyConfiguration Object is - in the inService state. - - true -
    -
    true
    JACC:JAVADOC:24voidjakarta.security.jacc.PolicyConfiguration.removeExcludedPolicy
    -
    - Used to remove any excluded policy statements from this PolicyConfiguration. - true -
    -
    true
    JACC:JAVADOC:25voidjakarta.security.jacc.PolicyConfiguration.removeRole
    - - ( - String - ) -
    - Used to remove a role and all its permissions from this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:26voidjakarta.security.jacc.PolicyConfiguration.removeUncheckedPolicy
    -
    - Used to remove any unchecked policy statements from this PolicyConfiguration. - true -
    -
    true
    JACC:JAVADOC:27booleanjakarta.security.jacc.PolicyConfigurationFactory.contains
    - - ( - String - ) -
    - This method determines if a PolicyConfiguration with policy context identifier equivalent to the argument contextID, already exists in the Policy provider associated with the factory. - - true -
    -
    true
    JACC:JAVADOC:28PolicyConfigurationjakarta.security.jacc.PolicyConfigurationFactory.getPolicyConfiguration
    - - ( - String - ,
    boolean - ) -
    - This method is used to obtain an instance of the provider specific class that implements the PolicyConfiguration interface and that corresponds to one policy configuration within a provider. - The methods of the PolicyConfiguration interface are used to define the policy statements of the associated policy configuration. For a given value of policy context identifier, this method must always return the same instance of PolicyConfiguration and there must be at most one actual instance of a PolicyConfiguration with a given policy context identifier (during a process context). - true -
    -
    true
    JACC:JAVADOC:29PolicyConfigurationFactoryjakarta.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationFactory
    -
    - This static method uses a system property to find and instantiate (via a public constructor) a provider specific factory implementation class. - The name of the provider specific factory implementation class is obtained from the value of the system property, jakarta.security.jacc.PolicyConfigurationFactory.provider - true -
    -
    true
    JACC:JAVADOC:30PolicyConfigurationFactoryjakarta.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationFactory
    -
    throws - ClassNotFoundException
    -
    when the class named by the system property could not be found including because the value of the system property has not been set.true -
    -
    true
    JACC:JAVADOC:31PolicyConfigurationFactoryjakarta.security.jacc.PolicyConfigurationFactory.PolicyConfigurationFactory
    -
    -
    -
    true -
    -
    true
    JACC:JAVADOC:32booleanjakarta.security.jacc.PolicyConfigurationFactory.inService
    -
    - Authorization protected method that may be used by a Policy provider to activate the PolicyContextHandler registered to the context object key and cause it to return the corresponding policy context object from the container. - When a handler is activated by this method, it passes to the handler the context object key and the handler data associated with the calling thread. - true -
    -
    true
    JACC:JAVADOC:33Objectjakarta.security.jacc.PolicyContext.getContext
    - - ( - String - ) -
    -
    -
    true -
    -
    true
    JACC:JAVADOC:34Stringjakarta.security.jacc.PolicyContext.getContextID
    -
    - This static method returns the value of the policy context identifier associated with the thread on which the accessor is called. - - true -
    -
    true
    JACC:JAVADOC:35Setjakarta.security.jacc.PolicyContext.getHandlerKeys
    -
    - This method may be used to obtain the keys that identify the container specific context handlers registered by the container. - true -
    -
    true
    JACC:JAVADOC:36voidjakarta.security.jacc.PolicyContext.registerHandler
    - - ( - String - ,
    PolicyContextHandler - ,
    boolean - ) -
    - Authorization protected method used to register a container specific PolicyContext handler. - A handler may be registered to handle multiple keys, but at any time, at most one handler may be registered for a key. - true -
    -
    true
    JACC:JAVADOC:37voidjakarta.security.jacc.PolicyContext.setContextID
    - - ( - String - ) -
    - Authorization protected method used to modify the value of the policy context identifier associated with the thread on which this method is called. - - true -
    -
    true
    JACC:JAVADOC:38voidjakarta.security.jacc.PolicyContext.setHandlerData
    - - ( - Object - ) -
    - Authorization protected method that may be used to associate a thread-scoped handler data object with the PolicyContext. - The handler data object will be made available to handlers, where it can serve to supply or bind the handler to invocation scoped state within the container. - true -
    -
    true
    JACC:JAVADOC:39Objectjakarta.security.jacc.PolicyContextHandler.getContext
    - - ( - String - ,
    Object - ) -
    - This public method is used by the PolicyContext class to activate the handler and obtain from it the the context object identified by the (case-sensitive) key. - In addition to the key, the handler will be activated with the handler data value associated within the PolicyContext class with the thread on which the call to this method is made. Note that the policy context identifier associated with a thread is available to the handler by calling PolicyContext.getContextID(). - true -
    -
    true
    JACC:JAVADOC:40String[]jakarta.security.jacc.PolicyContextHandler.getKeys
    -
    - This public method returns the keys identifying the context objects supported by the handler. - The value of each key supported by a handler must be a non-null String value. - true -
    -
    true
    JACC:JAVADOC:41booleanjakarta.security.jacc.PolicyContextHandler.supports
    - - ( - String - ) -
    - This public method returns a boolean result indicating whether or not the handler supports the context object identified by the (case-sensitive) key value. - true -
    -
    true
    JACC:JAVADOC:42intjakarta.security.jacc.WebResourcePermission.compareTo
    - - ( - Object - ) -
    - Determines whether this WebResourcePermission is less than, equal to, or greater than the specified object, and returns a negative integer, zero, or a positive integer respectively. - The behavior of this method must conform to the specification of the CompareTo method of interface Comparable. This method is used to sort WebResourcePermissions according to Servlet's path matching rules, and as necessary to implement best match for Servlet constraint selection and enforcement. WebResourcePermissions are sorted first by URL Pattern type. The sorting by URL Pattern type is done such that exact patterns (those not ending with * or /, or beginning with *.) sort less than path prefix patterns (those ending with /*), path prefix patterns sort less than extension patterns (those beginning with *.), and such that extension patterns sort less than the universal pattern /). Path prefix patterns are sorted first by pattern depth; with deeper patterns sorting less than shallower patterns. Same depth path prefix patterns are sorted by case sensitive lexical comparison of the same depth nodes, beginning with the root node, and continuing until a difference is found. Within pattern types other than path prefix patterns, same type patterns are sorted to case sensitive lexical order. Additional sorting by actions of pattern equivalent permissions is optional. - true -
    -
    true
    JACC:JAVADOC:43booleanjakarta.security.jacc.WebResourcePermission.equals
    - - ( - Object - ) -
    - Checks two WebResourcePermission objects for equality. - WebResourcePermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - true -
    -
    true
    JACC:JAVADOC:44Stringjakarta.security.jacc.WebResourcePermission.getActions
    -
    - Returns a canonical String representation of the actions of this WebResourcePermission. - WebResourcePermission actions are canonicalized by sorting the HTTP methods into lexical order. - true -
    -
    true
    JACC:JAVADOC:45intjakarta.security.jacc.WebResourcePermission.hashCode
    -
    - Returns the hash code value for this WebResourcePermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value, every time it is called on a WebResourcePermission object. The value returned by hashCode for a particular WebResourcePermission need not remain consistent from one execution of an application to another. If two WebResourcePermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:46booleanjakarta.security.jacc.WebResourcePermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this WebResourcePermission. - For this to be the case, The argument must be an instanceof WebResourcePermission with name matched by this WebResourcePermission (according to the servlet matching rules), and the HTTP methods to which the argument permission applies (as defined in its actions) must be a subset of the HTTP methods to which this WebResourcePermission applies (as defined in its actions). The servlet matching rules are used to determine if the name of this WebResourcePermission matches the name of the argument permission. The names match if the values of the URL pattern portions of their names are related as follows: their URL patterns are lexically equivalent, or the URL pattern of this WebResourcePermission is a path-prefix pattern (that is, it ends with /*), and the path-prefix pattern (minus the last 2 characters) is an exact match for a prefix of the URL pattern of the argument permission, or the URL pattern of this WebResourcePermission is an extension pattern (that is, it begins with *.) and the substring of the extension pattern beginning with the . and extending to the end of the pattern, is an exact match for the end of the URL pattern of the argument permission. the URL pattern of this WebResourcePermission is the special pattern containing only the default character / (may be more than one /) which matches all other URL patterns. All of the comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:47WebResourcePermissionjakarta.security.jacc.WebResourcePermission.WebResourcePermission
    - - ( - String - ,
    String - ) -
    - Creates a new WebResourcePermission with the specified name and actions. - The name contains a URL Pattern (as defined in the Java Servlet Specification). The URLPattern identifies the web resources to which the permission applies. The actions parameter contains a comma seperated list of HTTP methods. The syntax of the actions parameter is defined as follows: HTTPMethod ::= GET | POST | PUT | DELETE | HEAD | OPTIONS | TRACE HTTPMethodList ::= HTTPMethod | HTTPMethodList comma HTTPMethod HTTPMethodSpec ::= null | HTTPMethodList If duplicates occur in the HTTPMethodSpec they must be eliminated by the permission constructor. A null or empty string HTTPMethodSpec indicates that the permission applies to all HTTP methods at the resources identified by the URL pattern. - true -
    -
    true
    JACC:JAVADOC:48WebResourcePermissionjakarta.security.jacc.WebResourcePermission.WebResourcePermission
    - - ( - String - ,
    String[] - ) -
    - Creates a new WebResourcePermission with name corresponding to the URLPattern, and actions composed from the array of HTTP methods. - true -
    -
    true
    JACC:JAVADOC:49WebResourcePermissionjakarta.security.jacc.WebResourcePermission.WebResourcePermission
    - - ( - HttpServletRequest - ) -
    - Creates a new WebResourcePermission from the HttpServletRequest object. - A container uses this constructor prior to checking if a caller has permission to perform a servlet request. - true -
    -
    true
    JACC:JAVADOC:50booleanjakarta.security.jacc.WebRoleRefPermission.equals
    - - ( - Object - ) -
    - Checks two WebRoleRefPermission objects for equality. - WebRoleRefPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). The name and actions comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:51Stringjakarta.security.jacc.WebRoleRefPermission.getActions
    -
    - Returns a canonical String representation of the actions of this WebRoleRefPermission. - - true -
    -
    true
    JACC:JAVADOC:52intjakarta.security.jacc.WebRoleRefPermission.hashCode
    -
    - Returns the hash code value for this WebRoleRefPermission. - The properties of the returned hash code must be as follows: During the lifetime of an Java application, the hashCode method must return the same integer value, every time it is called on a WebRoleRefPermission object. The value returned by hashCode for a particular WebRoleRefPermission need not remain consistent from one execution of an application to another. If two WebRoleRefPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:53booleanjakarta.security.jacc.WebRoleRefPermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this WebRoleRefPermission. - For this to be the case, The argument must be an instanceof WebRoleRefPermission with name equivalent to this WebRoleRefPermission, and with role reference equivalent to this WebRoleRefPermission (as defined in their actions). The comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:54WebRoleRefPermissionjakarta.security.jacc.WebRoleRefPermission.WebRoleRefPermission
    - - ( - String - ,
    String - ) -
    - Creates a new WebRoleRefPermission with the specified name and actions. - - true -
    -
    true
    JACC:JAVADOC:55intjakarta.security.jacc.WebUserDataPermission.compareTo
    - - ( - Object - ) -
    - Determines whether this WebUserDataPermission is less than, equal to, or greater than the specified object, and returns a negative integer, zero, or a positive integer respectively. - The behavior of this method must conform to the specification of the CompareTo method of interface Comparable. This method is used to sort WebUserDataPermissions according to Servlet's path matching rules, and as necessary to implement best match for Servlet constraint selection and enforcement. WebUserDataPermissions are sorted first by URL Pattern type. The sorting by URL Pattern type is done such that exact patterns (those not ending with * or /, or beginning with *.) sort less than path prefix patterns (those ending with /*), path prefix patterns sort less than extension patterns (those beginning with *.), and such that extension patterns sort less than the universal pattern /). Path prefix patterns are sorted first by pattern depth; with deeper patterns sorting less than shallower patterns. Same depth path prefix patterns are sorted by case sensitive lexical comparison of the same depth nodes, beginning with the root node, and continuing until a difference is found. Within pattern types other than path prefix patterns, same type patterns are sorted to case sensitive lexical order. Additional sorting by actions of pattern equivalent permissions is optional. - true -
    -
    true
    JACC:JAVADOC:56booleanjakarta.security.jacc.WebUserDataPermission.equals
    - - ( - Object - ) -
    - Checks two WebUserDataPermission objects for equality. - WebUserDataPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - true -
    -
    true
    JACC:JAVADOC:57Stringjakarta.security.jacc.WebUserDataPermission.getActions
    -
    - Returns a canonical String representation of the actions of this WebUserDataPermission. - WebUserDataPermission actions are canonicalized by sorting the HTTP methods and transport Types into lexical order. - true -
    -
    true
    JACC:JAVADOC:58intjakarta.security.jacc.WebUserDataPermission.hashCode
    -
    - Returns the hash code value for this WebUserDataPermission. - The properties of the returned hash code must be as follows: During the lifetime of an Java application, the hashCode method shall return the same integer value every time it is called on a WebUserDataPermission object. The value returned by hashCode for a particular EJBMethod permission need not remain consistent from one execution of an application to another. If two WebUserDataPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:59booleanjakarta.security.jacc.WebUserDataPermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this WebUserDataPermission. - For this to be the case, The argument must be an instanceof WebUserDataPermission with name matched by this WebUserDataPermission (according to the servlet matching rules), and the HTTP methods to which the argument permission applies (as defined in its actions) must be a subset of the HTTP methods to which this WebUserDataPermission applies (as defined in its actions), and the transport types to which the argument permission applies (as defined in its actions) must be a subset of the Transport types to which this WebUserDataPermission applies (as defined in its actions). The servlet matching rules are used to determine if the name of this WebUserDataPermission matches the name of the argument permission. The names match if the values of the URL pattern portions of their names are related as follows: their URL patterns are lexically equivalent, or the URL pattern of this WebUserDataPermission is a path-prefix pattern (that is, it ends with /*), and the path-prefix pattern (minus the last 2 characters) is an exact match for a prefix of the URL pattern of the argument permission, or the URL pattern of this WebUserDataPermission is an extension pattern (that is, it begins with *.) and the substring of the extension pattern beginning with the . and extending to the end of the pattern, is an exact match for the end of the URL pattern of the argument permission. the URL pattern of this WebUserDataPermission is the special pattern containing only the default character / (there may be more than one /) which matches all other URL patterns. All of the comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:60WebUserDataPermissionjakarta.security.jacc.WebUserDataPermission.WebUserDataPermission
    - - ( - String - ,
    String - ) -
    - Creates a new WebUserDataPermission with the specified name and actions. - The name contains a URL Pattern (as defined in the Java Servlet Specification). The URL Pattern identifies the web resources to which the permission applies. The actions parameter contains a comma separated list of HTTP methods followed by a comma separated list of transport protection types. The syntax of the actions parameter is defined as follows: HTTPMethod ::= Get | POST | PUT | DELETE | HEAD | OPTIONS | TRACE - HTTPMethodList ::= HTTPMethod | HTTPMethodList comma HTTPMethod - HTTPMethodSpec ::= emptyString | HTTPMethodList - transportType ::= CLEAR | INTEGRAL | CONFIDENTIAL | UNCONSTRAINED - transportTypeList ::= transportType | transportTypeList comma transportType - transportTypeSpec ::= emptyString | transportTypeList - actions ::= null | HTTPMethodSpec | HTTPMethodSpec colon transportTypeSpec - -If duplicates occur in either the HTTPMethodSpec or transportTypeSpec, they must be eliminated by the permission constructor. An empty string HTTPMethodSpec is a shorthand for a List containing all the possible HTTP methods. An empty string transportTypeSpec is a shorthand for a TransportTypeList containing the transportType value UNCONSTRAINED. A transportType of UNCONSTRAINED indicates that the associated HTTP methods at the web resources identified by the URL pattern may be accessed over any transport. The transportType UNCONSTRAINED is overridden by any other transportType associated with an equivalent URLPattern. - - true -
    -
    true
    JACC:JAVADOC:61WebUserDataPermissionjakarta.security.jacc.WebUserDataPermission.WebUserDataPermission
    - - ( - String - ,
    String[] - ,
    String[] - ) -
    - Creates a new WebUserDataPermission with name corresponding to the URLPattern, and actions composed from the array of HTTP methods and the array of transport types. - - true -
    -
    true
    JACC:JAVADOC:62WebUserDataPermissionjakarta.security.jacc.WebUserDataPermission.WebUserDataPermission
    - - ( - HttpServletRequest - ) -
    - Creates a new WebUserDataPermission from the HttpServletRequest object. - A container uses this constructor prior to checking if a caller has permission to perform a servlet request. - true -
    -
    true
    - - diff --git a/install/jacc/docs/assertions/spec/JACCSpecAssertions.html b/install/jacc/docs/assertions/spec/JACCSpecAssertions.html deleted file mode 100644 index c06a563a8f..0000000000 --- a/install/jacc/docs/assertions/spec/JACCSpecAssertions.html +++ /dev/null @@ -1,1721 +0,0 @@ - - - - - -Specification Assertion Detail - - -
    -
    -

    Jakarta Authorization
    2.0
    - Specification Assertion Detail -

    -
    - - - - - - - - - - - -
    TotalsTotalActiveDeprecatedRemoved
    - # of Assertions - 136123013
    - # of Required Assertions - 127116011
    - # of Optional Assertions - 9702
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:211.4Legacytrue -
    -
    falsetechnologyactivetrue
    JACC:SPEC:311.4Legacyfalse -
    -
    falsetechnologyactivefalse
    JACC:SPEC:411.4Each Policy provider that satisfies this contract must perform or -delegate to another provider all the permission evaluations -requested via its interface in the JRE; not just those made by the -container to implement J2EE security functionality. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:511.4Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:611.4Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:711.4Each provider must satisfy all of the authorization requirements of - the EJB and Servlet specifications corresponding to the target - platform. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:811.4In the case of Servlet resources, the provider must be able to - associate a distinct policy context with each context root - (including context roots created to support virtual hosting) - hosted by the server. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:911.4In protecting Servlet resources, a provider must select the policy -statements that apply to a request according to the constraint -matching and servlet mapping rules defined by the Servlet -specification. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1011.4To support this contract in a Servlet environment, a container or its -deployment tools must create policy statements as necessary to -support Servlet's default role-ref semantic. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1111.4This contract must support providers that are unable to determine, -before returning from Policy.getPermissions(), all the permissions -that pertain to a subject/protection domain. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1211.4For a container to support this contract, it must execute in an -environment controlled by a J2SE security manager. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1311.4The evaluation of a permission corresponding to a resource must -identify the context of the resource's use such that different policy -can be applied to a resource used in different contexts (that is, -applications or instances of an application). - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1422.1The security property policy.provider may be used to replace the default -java.security.Policy implementation class. Similarly, the security -property auth.policy.provider may be used to replace the default -javax.security.auth.Policy implementation class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1522.5Each JRE of an application server must be provided with classes that implement -the PolicyConfigurationFactory class and PolicyConfiguration -interface. These classes must be compatible with the Policy implementation class -installed for use by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1622.5If the provider is seeking to replace the Policy implementation used by the -JRE, then the JRE must be provided with an environment specific Policy -implementation class. If the JRE is running a J2SE 1.4 security environment, then -it must be provided with an implementation of the java.security.Policy -class. If the JRE is running a J2SE 1.3 security environment, it must be provided -with an implementation of the javax.security.auth.Policy class (that is, -a JAAS Policy object). - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1722.5A replacement Policy object must assume responsibility for performing all -policy decisions within the JRE in which it is installed that are requested by way -of the Policy interface that it implements. A replacement Policy object may -accomplish this by delegating non-jakarta.security.jacc policy decisions to -the corresponding default system Policy implementation class. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1822.5A replacement -Policy object that relies in this way on the corresponding default Policy -implementation class must identify itself in its installation instructions as a -delegating Policy provider. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1922.5The standard security properties mechanism for replacing a default system -Policy implementation (see Section 2.1, Policy Implementation Class) should -not be used to replace a default system Policy provider with a delegating Policy -provider. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:2022.6A J2SE 1.4 provider may support replacement of -the JAAS Policy object if and only if all jakarta.security.jacc policy decisions -performed by the replacement JAAS Policy object return the same result as when -the java.security.Policy interface is used. To satisfy this requirement, the -replacement JAAS Policy object must be compatible with the implementations of -PolicyConfigurationFactory and PolicyConfiguration interface -provided for use with the java.security.Policy implementation class. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2122.7An application server or container must bundle or install the -jakarta.security.jacc standard extension. This package must include the -abstract jakarta.security.jacc.PolicyConfigurationFactory class, -the jakarta.security.jacc.PolicyConfiguration and -jakarta.security.jacc.PolicyContextHandler interfaces, and -implementations of the -jakarta.security.jacc.PolicyContextException exception, the -jakarta.security.jacc Permission classes, and the -jakarta.security.jacc.PolicyContext utility class. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:2222.7To enable delegation of non-jakarta.security.jacc policy decisions to -default system Policy providers, all application servers must implement the -following Policy replacement algorithm. - -For each JRE of a J2EE 1.4 application server, if the system property -jakarta.security.jacc.policy.provider is defined, the application server must -construct an instance of the class identified by the system property, -confirm that the resulting object is an instance of java.security.Policy, -and set, by calling the java.security.Policy.setPolicy, the resulting -object as the corresponding Policy object used by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2322.7For each JRE of a J2EE 1.4 application server, if the system property -jakarta.security.jacc.policy.provider is defined, the application -server must construct an instance of the class identified by the system property, -confirm that the resulting object is an instance of java.security.Policy, -and set, by calling the java.security.Policy.setPolicy method, the -resulting object as the corresponding Policy object used by the JRE. - -An application server that chooses to support this contract in a J2SE 1.3 -environment must perform the policy replacement algorithm described above -when the system property -jakarta.security.jacc.auth.policy.provider is defined. That is, -for each JRE of the application server, the server must construct an instance of the -class identified by the system property, confirm that the resulting object is an -instance of javax.security.auth.Policy, and set, by calling -javax.security.auth.Policy.setPolicy method, the resulting object -as the corresponding Policy object used by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2422.7.1A J2EE 1.3 application -server must install or bundle, such that it is used by every JRE of the application -server, a javax.security.auth.SubjectDomainCombiner whose -combine method returns protection domains constructed using the permission -collections returned by javax.security.auth.Policy.getPermisions. -It is recommended that this requirement also be satisfied by J2EE 1.4 application -servers in the case where javax.security.auth.Policy is being used (in -backward compatibility mode) by the SubjectDomainCombiner. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2533.1The getPolicyConfigurationFactory method must be used in every JRE -to which the components of the application or module are being deployed to find -or instantiate PolicyConfigurationFactory objects. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2633.1The getPolicyConfiguration method of the factories must be used to -find or instantiate PolicyConfiguration objects corresponding to the -application or modules being deployed. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2733.1The declarative authorization policy statements derived from application or -module deployment descriptor(s) must be translated to create instances of the -corresponding jakarta.security.jacc Permission classes. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2833.1Methods of the PolicyConfiguration interface must be used with the -permissions resulting from the translation to create policy statements within the -PolicyConfiguration objects. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2933.1The PolicyConfiguration objects must be linked such that the same -principal-to-role mapping will be applied to all the modules of the application. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3033.1Independent of this specification, Jakarta EE deployment tools must translate and -complete the declarative policy statements appearing in deployment descriptors -into a form suitable for securing applications on the platform. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:3133.1.1.1A policy context is in one of three states and all -implementations of the PolicyConfiguration interface must implement the state -semantics defined in this section. - -- open -A policy context in the open state must be available for configuration by any -of the methods of the PolicyConfiguration interface. A policy context in the -open state must not be assimilated at Policy.refresh into the policy statements -used by the Policy provider in performing its access decisions. - -- inService -A policy context in the inService state must be assimilated at Policy.refresh -into the policy statements used by its provider. When a provider's refresh -method is called, it must assimilate only policy contexts that are in the inService -state and it must ensure that the policy statements put into service for -each policy context are only those defined in the context at the time of the call -to refresh. A policy context in the inService state must be unavailable for -additional configuration. A policy context in the inService state must be transitioned -to the open state when it is returned as a result of a call to getPolicy- -Configuration. A policy context is transitioned to the inService state by -calling the commit method, and only a policy context in the open state may be -transitioned to the inService state. - -- deleted -A policy context in the deleted state must be unavailable for configuration and -it must be unavailable for assimilation into its associated Provider. A policy -context in the deleted state must be transitioned to the open state when it is -returned as a result of a call to getPolicyConfiguration. A policy context is -transitioned to the deleted state by calling the delete method. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:3233.1.2A servlet container is responsible -for mapping the target name or address information of an HTTP request to the -appropriate hostname. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3333.1.3A reference to a PolicyConfiguration object must be obtained by calling the -getPolicyConfiguration method on the -PolicyConfigurationFactory implementation class of the provider -configured into the container. The policy context identifier used in the call to the -getPolicyConfiguration method must be a String composed as -described in Section 3.1.2, Servlet Policy Context Identifiers, on page 18. The -value true must be passed as the second parameter in the call to -getPolicyConfiguration to ensure that any and all policy statements are -removed from the policy context associated with the returned -PolicyConfiguration. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3433.1.3.1A WebResourcePermission and a WebUserDataPermission object must be -instantiated for each distinct url-pattern occurring in the securityconstraint -elements that contain an auth-constraint naming no roles (i.e -an excluding auth-constraint). The permissions must be constructed using -the qualified (as defined in Qualified URL Pattern Names) pattern as their name -and with actions defined by the union of the HTTP methods named or implied -by all of the collections containing the pattern and occurring in a constraint with -an excluding auth-constraint. The constructed permissions must be added to -the excluded policy statements by calling the addToExcludedPolicy method -on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3533.1.3.1A WebResourcePermission must be instantiated for each distinct combination -in the cross-product of url-pattern and role-name occurring in the -security-constraint elements that contain an auth-constraint -naming roles. When an auth-constraint names the reserved role-name, -"*", all of the patterns in the containing security-constraint must be -combined with all of the roles defined in the web application. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3633.1.3.1Each WebResourcePermission object must be constructed using the qualified pattern as -its name and with actions defined by the union of the HTTP methods named or -implied by the collections containing the pattern and occurring in a constraint that -names (or implies via "*") the role to which the permission is being added. The -resulting permissions must be added to the corresponding roles by calling the -addToRole method on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3733.1.3.1 The -resulting permissions must be added to the corresponding roles by calling the -addToRole method on the PolicyConfiguration object. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:3833.1.3.1A WebResourcePermission must be instantiated for each distinct urlpattern -occurring in the security-constraint elements that do not -contain an auth-constraint. Each WebResourcePermission object must be -constructed using the qualified pattern as its name and with actions defined by the -union of the HTTP methods named or implied by the collections containing the -pattern and occurring in a security-constraint without an authconstraint. -The resulting permissions must be added to the unchecked policy -statements by calling the addToUncheckedPolicy method on the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3933.1.3.1The WebResourcePermission objects resulting from -the translation of a security-constraint that does not contain an authconstraint -must be added to the unchecked policy statements by calling -addToUncheckedPolicy on the PolicyConfiguration object. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:4033.1.3.1The -WebResourcePermission objects resulting from the translation of a securityconstraint -containing an auth-constraint that named no roles must be -added to the excluded policy statements by calling addToExcludedPolicy on -the PolicyConfiguration object. - false -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:4133.1.3.1A WebUserDataPermission must be instantiated for each distinct combination -of url-pattern and acceptable connection type resulting from the processing -of the security-constraint elements that do not contain an excluding -auth-constraint. The mapping of security-constraint to acceptable -connection type must be as defined in Mapping Transport Guarantee to Connection -Type. Each WebUserDataPermission object must be constructed using the -qualified pattern as its name and with actions defined by appending a -representation of the acceptable connection type to the union of the HTTP -methods named or implied by the collections containing the pattern and occurring -in a security-constraint that maps to the connection type and that does not -contain an excluding auth-constraint. The resulting permissions must be -added to the unchecked policy statements by calling the -addToUncheckedPolicy method on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4233.1.3.1A transport-guarantee (in a user-data-constraint) of NONE, or a -security-constraint without a user-data-constraint, indicates that -the associated URL patterns and HTTP methods may be accessed over any -(including an unprotected) transport. A transport-guarantee of -INTEGRAL indicates that acceptable connections are those deemed by the -container to be integrity protected. A transport-guarantee of -CONFIDENTIAL indicates that acceptable connections are those deemed by the -container to be protected for confidentiality. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4333.1.3.2For each security-role-ref appearing in the deployment descriptor a -corresponding WebRoleRefPermission must be created. The name used in the -construction of each WebRoleRefPermission must be the servlet-name in -whose context the security-role-ref is defined. The actions used to -construct the permission must be the value of the role-name (that is the -reference), appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4433.1.3.2The deployment tools must call the addToRole method on the - PolicyConfiguration object to add the WebRoleRefPermission object - resulting from the translation to the role identified in the role-link - appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4533.1.3.2For each servlet element in the deployment descriptor a WebRoleRefPermission must -be created for each security-role whose name does not appear as the rolename -in a security-role-ref within the servlet element. Each such -WebRoleRefPermission must be created with action (that is, reference) -corresponding to the role-name and added to the role with the same name (as -the reference) by calling the addToRole method on the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12833.1.3.2 - If the any authenticated user role-name, **, occurs in an auth-constraint, - a WebResourcePermission must also be added to the ** role. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12933.1.3.2 - A WebResourcePermission must be instantiated for each distinct combination - in the cross-product of url-pattern and role-name occurring in the - security-constraint elements that contain an auth-constraint - naming roles. When an auth-constraint names the reserved role-name, - "*", all of the patterns in the containing security-constraint must be - combined with all of the roles defined in the web application; which must - not include the role "**" unless the application has defined an - application role named "**". - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:13033.1.3.3 - If the any authenticated user role-name, **, does not appear in a - security-role-ref within the servlet, a WebRoleRefPermission must also be added for it. - The name of each such WebRoleRefPermission must be the servlet-name - of the corresponding servlet element. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:13133.1.3.3 - For each security-role defined in the deployment descriptor and the - any uthenticated user role, **, an additional WebRoleRefPermission - must be added to the corresponding role by calling the addToRole method - on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:13233.1.3.2 - A WebResourcePermission and a WebUserDataPermission must be obtained - for each url-pattern in the deployment descriptor and the default pattern, "/", - that is not combined by the web-resource-collection elements of the - deployment descriptor with every possible HTTP method value. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:13333.1.3.2 - If a deny uncovered HTTP methods semantic is in effect for the web module associated with the - PolicyContext, the resulting permissions must be added to the excluded policy - statements by calling the addToExcludedPolicy method on the - PolicyConfiguration object. Otherwise, the permissions must be added to - the unchecked policy statements by calling the addToUncheckedPolicy - method on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:13433.1.5.1 - These addToRole calls must be made for any role-name used in the method- - permision which may include the role-name **; which, by default, is mapped to - any authenticated user. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:13533.1.5.3 - If the any authenticated user role-name, **, does not appear in a - security-role-ref within the element, a EJBRoleRefPermission must also - be added for it. The name of each such EJBRoleRefPermission must be the value of the ejb-name - element within the element in which the security-role-ref elements could - otherwise occur. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:13633.2 - For the any authenticated user role, **, and unless an - application specific mapping has been established for this role, the provider must - ensure that all permissions added to the role are granted to any authenticated user. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4633.1.4an application server must establish EJB policy -context identifiers sufficient to differentiate all instances of the deployment of an -EJB jar on the application server, or on any other application server with which -the server may share the same policy statement repository. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:4733.1.5.1An EJBMethodPermission object must be created for each role-name or -unchecked element contained in each method-permission element -appearing in the deployment descriptor. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4833.1.5.1The name of each EJBMethodPermission -must be the ejb-name as defined in the method element of the methodpermission -element. The actions used in the permission construction must be -obtained by translating the contents of the method element into a method -specification according to the methodSpec syntax defined in the documentation of -the EJBMethodPermission class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4933.1.5.1If the method-permission element contains the unchecked element, -then the deployment tools must call the addToUncheckedPolicy method to -add the permission resulting from the translation to the -PolicyConfiguration object. - -Alternatively, if the method-permission -element contains one or more role-name elements, then the deployment tools -must call the addToRole method to add each of the permissions resulting from -the translation to the corresponding role of the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5033.1.5.2An EJBMethodPermission object must be created for each method element -occurring in the exclude-list element of the deployment descriptor. The -name and actions of each EJBMethodPermission must be established as described -in Section 3.1.5.1, Translating EJB method-permission Elements. -The deployment tools must use the addToExcludedPolicy method to add -the EJBMethodPermission objects resulting from the translation of the -exclude-list to the excluded policy statements of the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5133.1.5.3For each security-role-ref element appearing in the deployment -descriptor, a corresponding EJBRoleRefPermission must be created. The name of -each EJBRoleRefPermission must be obtained as described for -EJBMethodPermission objects. The actions used to construct the permission must -be the value of the role-name (that is the reference), appearing in the -security-role-ref. The deployment tools must call the addToRole -method on the PolicyConfiguration object to add a policy statement -corresponding to the EJBRoleRefPermission to the role identified in the rolelink -appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5233.1.6The application server's deployment tools must translate the declarative -authorization policy appearing in the application or module deployment -descriptor(s) into policy statements within the Policy providers used by the -containers to which the components of the application or module are being -deployed. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5333.1.6When a module is deployed, its policy context must be linked to the policy -context of every other module with which it must share the same principal-to-role -mapping. When an application is deployed, the policy contexts of every module of -the application must be linked to the policy contexts of every other module of the -application with which it shares a common Policy provider. Policy contexts are -linked by calling the linkConfiguration method on the PolicyConfiguration -objects of the provider. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5433.1.6Once the translation, linking, and committing has occurred, a call must be -made to Policy.refresh on the Policy provider used by each of the containers -to which the application or module is being deployed. The calls to -Policy.refresh must occur before the containers will accept requests for the -deployed resources. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5533.1.6The policy context identifiers corresponding to the deployed application or -module must be recorded in the application server so that they can be used by -containers to establish the policy context as required by Section 4.6, Setting the -Policy Context of the Policy Decision and Enforcement Subcontract, and such -that the Deployer may subsequently remove or modify the corresponding policy -contexts as a result of the undeployment or redeployment of the application. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5633.1.7A -deployment tool indicates that a policy context is to be removed from service -either by calling getPolicyConfiguration with the identifier of the policy context -on the provider's PolicyConfigurationFactory or by calling delete on the -corresponding PolicyConfiguration object. If the getPolicyConfiguration method -is used, the value true should be passed as the second argument to cause the -corresponding policy statements to be deleted from the context. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5733.1.7To ensure that there is not a period during undeployment when the removal of -policy statements on application components renders what were protected -components unprotected, the application server must stop accepting requests for -the application's components before undeploying an application or module. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5833.1.7After the policy -contexts are marked for removal from service, a call must be made to -Policy.refresh on all of the Policy providers from which at least one module -of the application or module was marked for removal from service. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5933.1.7To facilitate redeployment to an existing policy configuration, container -deployment tools may also support a mode in which they do not delete the -PolicyConfiguration objects associated with the application or module -being undeployed. - false -
    -
    falsetechnologyremovedfalse
    JACC:SPEC:6033.1.8Containers are not required to deploy to an existing policy configuration. -Containers that chose to provide this functionality must satisfy the following -requirements. -To associate an application or module with an existing set of linked policy -contexts, the identifiers of the existing policy contexts must be applied by the -relevant containers in fulfilling their obligations as defined in the Policy Decision -and Enforcement Subcontract. The policy contexts should be verified for -existence, by calling the inService method of the -PolicyConfigurationFactory of the Policy providers of the relevant -containers. The deployment tools must call Policy.refresh on the Policy -provider of each of the relevant containers, and the containers must not accept -requests for the deployed resources until these calls have completed. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6133.1.9Containers are not required to implement redeployment functionality.false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:6233.1.9Containers -that chose to provide this functionality must satisfy the following requirements. - -To ensure redeployment does not create a situation where the removal of -policy statements on application components renders what were protected -components unprotected, the application server must stop accepting requests for -the application's components before redeployment begins. The application server -must not resume processing requests for the application's components until after -the calls to Policy.refresh, described below, have completed. - -To redeploy a module, the deployment tools must indicate at all of the Policy -providers to which the module is to be redeployed that the policy context -associated with the module is to be removed from service. If the module is to be -redeployed to the same policy context at a provider, all policy statements must be -removed from the policy context at the provider. - -After the policy contexts have been marked for removal from service and emptied of policy statements (as -necessary), the deployment tools must translate the declarative authorization -policy appearing in the module's deployment descriptor into PolicyConfiguration -objects within the Policy providers at which the module is being redeployed. - - After the translation, the PolicyConfiguration objects must be linked, as -necessary, to the policy context of every other module in the same provider with -which the module must share the same principal-to-role mappings. - -After the module is linked, the commit method must be called on the -PolicyConfiguration objects. After commit has been called, a call must be -made to Policy.refresh on the Policy provider used by each of the containers -to which the module has been redeployed. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6333.2the provider must include an implementation of the -jakarta.security.jacc.PolicyConfigurationFactory class along -with a matched implementation of a class that implements the -jakarta.security.jacc.PolicyConfiguration interface. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6433.2In addition to -providing a PolicyConfiguration interface for integration with the -application server deployment tools, the provider must also include a -management interface for policy administrators to use to grant the collections of -permissions that comprise roles, to principals. This interface need not be -standardized. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:6533.2The provider must ensure that all of the permissions added to a role in a policy -context are granted to any principal mapped to the role by the policy -administrator. The provider must ensure that the same principal-to-role mappings -are applied to all linked policy contexts. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6633.2The provider must ensure that excluded policy statements take precedence -over overlapping unchecked policy statements, and that both excluded and -unchecked policy statements take precedence over overlapping role based policy -statements. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6733.3The getPolicyConfigurationFactory, and inService methods of the -abstract factory class, -jakarta.security.jacc.PolicyConfigurationFactory, must throw a -SecurityException when called by an AccessControlContext that has not been -granted the setPolicy SecurityPermission. -The getPolicyConfiguration method of all implementations of the -PolicyConfigurationFactory abstract class must throw a -SecurityException when called by an AccessControlContext that has not been -granted the setPolicy SecurityPermission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6833.3All of the public methods of all of the concrete implementations of the -PolicyConfiguration interface must throw a SecurityException when called -by an AccessControlContext that has not been granted the setPolicy -SecurityPermission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6933.3In cases where a required permission is not held by a caller, the -implementation must return without changing the state of the policy statement -repository. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:7033.3The containers of an application server must be granted the getPolicy -SecurityPermission and the setPolicy SecurityPermission. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:7144.1.1The Servlet container must construct (or reuse) a WebUserDataPermission object -using the request URI minus the context path as the name and with actions -composed from the HTTP method of the request and a protection value describing -the transport layer protection of the connection on which the request arrived. -The protection value used in the permission construction must be -determined as follows: - - If the request arrived on a connection deemed by the container to be protected -for confidentiality, a protection value of :CONFIDENTIAL must be used. -- If the request arrived on a connection deemed by the container to be protected -for integrity (but not confidentiality), a protection value of :INTEGRAL must be used. -- If the request arrived on a connection deemed by the container to be unprotected, - the actions used in the permission construction must contain only the HTTP - method of the request. - -The Servlet container must use one of the methods described in Section 4.7, -Checking AccessControlContext Independent Grants to test if access to the -resource using the method and connection type encapsulated in the -WebUserDataPermission is permitted. If a SecurityException is thrown in the -permission determination, it must be caught, and the result of the determination -must be that access to the resource using the method and connection type is not -permitted. If access is not permitted, the request must be redirected as defined by -the Servlet Specification. If access is permitted, the request must be subjected to a -pre-dispatch decision. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7244.1.2The Servlet container must construct (or reuse) a WebResourcePermission object -using the request URI minus the context path as the name and with actions -corresponding to the HTTP method of the request. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7344.1.2If a SecurityException is thrown in the permission determination, it -must be caught, and the result of the determination must be that the permission is -not granted to the caller. The Servlet container may only dispatch the request to -the web resource if theWebResourcePermission is determined to be granted to the -caller. Otherwise the request must be rejected with the appropriate HTTP error -message as defined by the Servlet Specification. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7444.1.2Before it dispatches a call to a web resource, the container must associate with -the call thread an AccessControlContext containing the principals of (only) the -target component runAs identity (as defined in Section 4.5, Component runAs -Identity). - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7544.1.3When a call is made from a web resource to isUserInRole(String -roleName) the implementation of this method must construct (or reuse) a -WebRoleRefPermission object using the servlet-name of the calling web resource -as the name and with actions equal to the roleName used in the call. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7644.1.3If a -SecurityException is thrown in the permission determination, it must be caught, -and the result of the determination must be that the permission is not granted to -the caller. If it is determined that the WebRoleRefPermission has been granted to -the caller, isUserInRole must return true. Otherwise the return value must be false. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7744.2.2The policy statements of the identified PolicyConfiguration are filtered to -select the set of statements that refer to a permission of the same type as the -checked permission and that have as their name the url-pattern that is the bestmatch -to the name of the checked permission. The algorithm for determining the -best matching url-pattern is described in Section 4.2.2.1, Servlet URL-Pattern -Matching Rules. The resulting policy statements are then reduced to the set -whose actions match the actions of the checked permission. If the resulting set is -empty, the evaluation may terminate, and the result of the evaluation must be that -the checked permission is determined to be unconstrained and thus implicitly -granted. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:7844.2.2If the resulting set is not empty, and it contains one or more excluded policy -statements, the evaluation may terminate and the checked permission must be -determined not to be granted. - -Otherwise, if the set contains one or more unchecked policy statements, -the evaluation may terminate and the checked permission must be -determined to be granted. If the resulting set contained neither -excluded or unchecked policy statements, then the access control context may -only be determined to have been granted the checked permission if it has been -accorded a permission with name equal to the best-matching pattern, and with -actions equal to the actions of the checked permission. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:7944.2.2.1URL pattern matching must be guided by pattern type such that exact patterns -(those not ending with * or /, or beginning with *.) must match better than -path prefix patterns (those ending with /*) - - and such that path prefix patterns must match better than extension patterns - (those beginning with *.), - - and suchthat extension patterns must match better than the universal pattern /). - -Among path prefix matches, longer string length patterns must match better than shorter -patterns. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8044.3EJB containers must enforce the authorization policies established for EJB -resources as a result of the deployment of application modules containing EJB -resources. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8144.3.1The EJB container must construct (or reuse) an EJBMethodPermission object with -name corresponding to the ejb-name of the target resource. The actions used in the -permission construction must completely specify the method of the EJB by -identifying the method interface, method name, and method signature as defined -for a methodSpec in the documentation of the EJBMethodPermission class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8244.3.1If a SecurityException is -thrown in the permission determination, it must be caught, and the result of the -determination must be that the permission is not granted to the caller. The EJB -container may only dispatch the request to the EJB resource, if the -EJBMethodPermission is determined to be granted to the caller. Otherwise the -request must be rejected with the appropriate RMISecurityException, as defined -by the EJB specification. -Before it dispatches a call to an EJB, the container must associate with the call -thread an AccessControlContext containing the principals of only the target EJB -runAs identity (as defined in Section 4.5, Component runAs Identity). - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8344.3.2When an EJB makes a call to isCallerInRole(String roleName) the -implementation of this method must construct (or reuse) an -EJBRoleRefPermission object using the ejb-name of the EJB making the call as -the name and with the value of the roleName as actions. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8444.3.2If a -SecurityException is thrown in the permission determination, it must be caught, -and the result of the determination must be that the permission is not granted to -the caller. If it is determined that the EJBRoleRefPermission has been granted to -the caller, then isCallerInRole must return true. Otherwise the return value must -be false. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8544.4.1The policy statements of the PolicyConfiguration identified by calling the -getContextID method on the PolicyContext utility class must be tested to -determine if they match the permission being evaluated. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8644.4.1If one or more excluded -policy statements match the checked permission, the evaluation may terminate -and the checked permission must be determined not to be granted. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8744.4.1 if one or more unchecked policy statements match the checked permission, the -checked permission must be determined to be granted independent of access -control context. If neither of the excluded or unchecked comparisons yield a -match, then the access control context may only be determined to have been -granted the checked permission if a matching permission has been accorded to the -access control context. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8844.4.2An excluded or unchecked policy statement matches a checked permission if the -policy statement satisfies the rules for matching a granted permission to the -checked permission. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8944.4.2A granted EJBMethodPermission matches a checked EJBMethodPermission -if their names are equivalent, and if the method specification in the actions of the -grnted permission matches the method specification in the actions of the che?ked -permission (as described in the definition of the EJBMethodPermission class). - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:9044.4.2One or more granted EJBRoleRefPermission objects match a checked -EJBRoleRefPermission if their names and actions are equivalent to the name of -the checked permission. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:9144.5By default (and unless otherwise specified in the EJB or Servlet -specifications), components are configured such that they are assigned the identity -of their caller (such as it is) as their runAs identity. Alternatively, a Deployer may -choose to assign an environment specific identity as a component runAs identity. -In this case, the container must establish the specified identity as the component -runAs identity independent of the identity of the component caller. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9244.5When a Deployer configures an environment specific component identity -based on a deployment descriptor specification that the component run with an -identity mapped to a role, those responsible for defining the principal-to-role -mapping must ensure that the specified identity is mapped to the role. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9344.5A container establishes a component's runAs identity by associating an -AccessControlContext with the component's thread of execution. The container -must ensure that the AccessControlContext includes a SubjectDomainCombiner; -and the container must protect the AccessControlContext associated with a -running component such that, by default, the component is not granted -permissions sufficient to modify the AccessControlContext. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9444.6A policy context identifier is set on a thread by calling the setContextID method -on the PolicyContext utility class. The value of a thread policy context identifier -is null until the setContextID method is called. Before invoking policy to evaluate -a transport guarantee or to perform a pre-dispatch decision, and before -dispatching into a Servlet or EJB component, a container must ensure that the -thread policy context identifier identifies the policy context corresponding -to the instance of the module or application for which the operation is being -performed. -Containers must be granted the setPolicy SecurityPermission independent -of policy context identifier (or in all policy contexts) as they need this permission -to set the policy context identifier. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9544.6.1This specification requires that containers register policy context handlers with -the PolicyContext utility class such that Policy providers can invoke these -handlers to obtain additional context to apply in their access decisions. Policy -context handlers are objects that implement the PolicyContextHandler interface. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9644.6.1All of the required context handlers must -return the value null when activated outside of the scope of a container's -processing of a component request. Policy providers must not call methods on or -modify the objects returned by the context handlers if these actions will cause the -container to fail in its processing of the associated request.. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9744.6.1.1All EJB and Servlet containers must register a PolicyContextHandler whose -getContext method returns a javax.security.auth.Subject object when invoked with -the key javax.security.auth.Subject.container. When this handler is activated -as the result of a policy decision performed by a container before dispatch -into a component, this handler must return a Subject containing the principals - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9844.6.1.2All EJB containers must register a PolicyContextHandler whose getContext -method returns a jakarta.xml.soap.SOAPMessage object when invoked with the -key jakarta.xml.soap.SOAPMessage. If the request being processed by the -container arrived as a SOAP request at the ServiceEndpoint method interface, the -container must return the SOAP message object when this handler is activated. -Otherwise, this handler must return the value null. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9944.6.1.3All Servlet containers must register a PolicyContextHandler whose getContext -method returns a jakarta.servlet.http.HttpServletRequest object when invoked with -the key jakarta.servlet.http.HttpServletRequest. When this handler is activated, -the container must return the HttpServletRequest object corresponding to the -component request being processed by the container. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10044.6.1.4All EJB containers must register a PolicyContextHandler whose getContext -method returns a jakarta.ejb.EnterpriseBean object when invoked with the key -jakarta.ejb.EnterpriseBean. When this handler is activated, the container must -return the EnterpriseBean object corresponding to theEJB component request being -processed by the container. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10144.6.1.5All EJB containers must register a PolicyContextHandler whose getContext -method returns an array of objects (Object[]) containing the arguments of the EJB -method invocation (in the same order as they appear in the method signature) -when invoked with the key jakarta.ejb.arguments. The context handler must -return the value null when called in the context of a SOAP request that arrived at -the ServiceEndpoint method interface. Otherwise, the context handler must return -the array of objects corresponding to the parameters of the EJB component -invocation. If there are no parameters in the method signature, the context handler -must return an empty array of Object (i.e. Object[0]). - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10244.7 A container must use one of the following techniques to check an instance of a -permission for which policy is defined independent of AccessControlContext. - -- The container calls AccessControlContext.checkPermission with -the permission being checked as argument. The call to checkPermission -may be made on any AccessControlContext. If checkPermission throws -an AccessControlException, the permission is not granted. Otherwise the -permission is granted. - -- The container calls AccessController.checkPermission with the -permission being checked. The value of the current thread?s -AccessControlContext is irrelevant in the access determination. If -checkPermission throws an AccessControlException, the checked -permission is not granted. Otherwise the permission is not granted. - -- The container calls SecurityManager.checkPermission with the -permission being checked. If checkPermission throws an -AccessControlException, the checked permission is not granted. Otherwise the -permission is granted. - -- The container calls Policy.implies with two arguments; the -permission being checked and a ProtectionDomain that need not be -constructed with principals. The checked permission is granted if -Policy.implies returns true. Otherwise, the permission is not granted. - -- The container calls -java.security.Policy.getPermissions with a ProtectionDomain -that need not be constructed with principals. The container must call the -implies method on the returned PermissionCollection using the permission -being checked as argument. The checked permission is granted if the -PermissionCollection implies it. Otherwise, the permission is not granted. This -technique is supported but not recommended. - -Prior to using any of the techniques described in this section, the container -must have established a policy context identifier as defined in Section 4.6, -Setting the Policy Context. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10344.8A container must determine if the caller has been granted a permission by -evaluating the permission in the context of an AccessControlContext, -ProtectionDomain, or Subject containing the principals of (only) the caller. If the -caller's identity has been asserted or vouched for by a trusted authority (other than -the caller), the principals of the authority must not be included in the principals of -the caller.A container must use one of the following techniques to determine if a -permission has been granted to the caller. - -The container calls AccessControlContext.checkPermission with -the permission as argument. The call to checkPermission must be made on -an AccessControlContext that contains the principals of the caller. If -checkPermission throws an AccessControlException, the permission is not -granted to the caller. Otherwise the permission is granted. - -The container calls AccessController.checkPermission with the -permission as argument. The AccessControlContext associated with the thread -on which the call to checkPermission is made must contain the principals -of the caller. If checkPermission throws an AccessControlException, the -permission is not granted to the caller. Otherwise the permission is granted. - -The container calls SecurityManager.checkPermission with the -permission as argument. The AccessControlContext associated with the thread -on which the call to checkPermission is made must contain the principals -of the caller. If checkPermission throws an AccessControlException, the -permission is not granted to the caller. Otherwise the permission is granted. - -The container calls Policy.implies with two arguments; the -permission being checked and a ProtectionDomain constructed with the -principals of the caller. The boolean result returned by Policy.implies -indicates whether or not the permission has been granted to the caller. - -The container calls -java.security.Policy.getPermissions with an argument -ProtectionDomain that was constructed with the principals of the caller. The -container must call the implies method on the returned -PermissionCollection using the permission being checked as argument. If the -PermissionCollection implies the permission being tested, the permission has -been granted to the caller. Otherwise it has not. This technique is supported but -not recommended. - - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10444.9A Policy provider must return that a tested permission has not been granted if it -acquires a non-null policy context identifier by calling getContextID on the -PolicyContext class and the inService method of the -PolicyConfigurationFactory associated with the provider would return -false if called with the policy context identifier. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10544.10A Policy provider must include the policy statements of the default policy -context in every access determination it performs.A Policy provider that either -does not call PolicyContext.getContexdID, or does so and acquires the identifier -of the default policy context, must use only the policy statements of the default -policy context to perform its access determination. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10644.11To be compatible with this contract, all of the JRE of an application -server must perform all of the policy decisions defined by this contract by -interacting with the java.security.Policy instance available in the JRE -via the java.security.Policy.getPolicy method. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10744.11Legacy - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10822.7Once an application server has used either of the system properties defined in -this section to replace a Policy object used by a JRE, the application server must -not use setPolicy to replace the corresponding Policy object of the running JRE -again. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10944.2.1A Policy provider must use the combined policy statements of the default policy -context (as defined in Section 4.10, Default Policy Context) and of the policy -context identified by calling PolicyContext.getContextID to determine if they -imply the permission being checked. If one or more excluded policy statements -imply the checked permission, the evaluation may terminate and the checked -permission must be determined not to be granted. Otherwise, if one or more -unchecked policy statements imply the checked permission, the checked -permission must be determined to be granted independent of -AccessControlContext. If the status of the checked permission is not resolved by -the excluded and unchecked evaluations, it must be determined if a permission -that implies the checked permission has been granted to the -AccessControlContext being tested for the permission. The checked permission -may only be determined to be granted if a permission that implies the checked -permission has been granted to the AccessControlContext. Otherwise the -permission must be determined not to be granted. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11044.2.1.1The URLPatternSpec syntax is defined as -follows: -URLPatternList ::= URLPattern | URLPatternList colon URLPattern -URLPatternSpec ::= URLPattern | URLPattern colon URLPatternList -name ::= URLPatternSpec -Given this syntax, A reference URLPatternSpec matches an argument -URLPatternSpec if all of the following are true. -- The first URLPattern in the argument URLPatternSpec is matched by the first -URLPattern in the reference URLPatternSpec. --The first URLPattern in the argument URLPatternSpec is NOT matched by -any URLPattern in the URLPatternList of the reference URLPatternSpec. -- If the first URLPattern in the argument URLPatternSpec matches the first -URLPattern in the reference URLPatternSpec, then every URLPattern in the -URLPatternList of the reference URLPatternSpec must be matched by a -URLPattern in the URLPatternList of the argument URLPatternSpec. -The comparisons described above are case sensitive, and all matching is -according to the rules defined in Section 3.1.3.3, Servlet URL-Pattern Matching -Rules. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11144.2.1.2A reference WebResourcePermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebResourcePermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11244.2.1.3A reference WebRoleRefPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebRoleRefPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The actions (i.e role reference) of the argument permission is equivalent to the -actions (i.e role reference) of the reference permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11344.2.1.4A reference WebUserDataPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebUserDataPermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -- The transportType in the actions of the reference permission either corresponds -to the value "NONE", or equals the transportType in the actions of the -argument permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11344.2.1.4 A reference WebUserDataPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebUserDataPermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, ?Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -- The transportType in the actions of the reference permission either corresponds -to the value "NONE", or equals the transportType in the actions of the -argument permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11444.4.1A Policy provider must employ the policy decision semantics described in -Section 4.2.1, Servlet Policy Decision Semantics in the Processing of EJB -Policy decisions. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11544.4.1.1A reference EJBMethodPermission implies an argument permission, if all of the -following are true. -- The argument permission is an instanceof EJBMethodPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The methods to which the argument permission applies (as defined in its actions) -must be a subset of the methods to which the reference permission applies -(as defined in its actions). This rule is satisfied if all of the following -conditions are met. -- The method name of the reference permission is null, the empty -string, or equivalent to the method name of the argument -permission. -- The method interface of the reference permission is null, the empty -string, or equivalent to the method interface of the argument -permission. -- The method parameter type list of the reference permission is null, -the empty string, or equivalent to the method parameter type list of -the argument permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11644.4.1.2A reference EJBRoleRefPermission implies an argument permission, if all of the -following are true. -- The argument permission is an instanceof EJBRoleRefPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The actions (i.e role reference) of the argument permission is equivalent to the -actions (i.e role reference) of the reference permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11733.1.3.1A WebResourcePermission and a WebUserDataPermission must be -instantiated for each url-pattern in the deployment descriptor and the default -pattern, "/", that is not combined by the web-resource-collection elements -of the deployment descriptor with every HTTP method value. The permission -objects must be constructed using the qualified pattern as their name and with -actions defined by the subset of the HTTP methods that do not occur in -combination with the pattern.The resulting permissions must be added to the -unchecked policy statements by calling the addToUncheckedPolicy method -on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11833.1.3.1The WebResourcePermission and WebUserDataPermission objects resulting -from the translation of a Servlet deployment descriptor must be constructed with -name produced by qualifying the URL pattern. The rules for qualifying a URL -pattern are dependent on the rules for determining if one URL pattern matches -another as defined in Section 3.1.3.3, Servlet URL-Pattern Matching Rules, and -are described as follows: - -- If the pattern is a path prefix pattern, it must be qualified by every path-prefix -pattern in the deployment descriptor matched by and different from the pattern -being qualified. The pattern must also be qualified by every exact pattern -appearing in the deployment descriptor that is matched by the pattern being -qualified. - -- If the pattern is an extension pattern, it must be qualified by every path-prefix -pattern appearing in the deployment descriptor and every exact pattern in the -deployment descriptor that is matched by the pattern being qualified. - -- If the pattern is the default pattern, "/", it must be qualified by every other pattern -except the default pattern appearing in the deployment descriptor. - -- If the pattern is an exact pattern, its qualified form must not contain any qualifying -patterns. - -URL patterns are qualified by appending to their String representation, a -colon separated representation of the list of patterns that qualify the pattern. -Duplicates must not be included in the list of qualifying patterns, and any -qualifying pattern matched by another qualifying pattern may be dropped from -the list. -QualifyingPatternList ::= - empty string | colon QualifyingPattern | - QualifyingPatternList colon QualifyingPattern - QualifiedPattern ::= Pattern QualifyingPatternList - -Any pattern, qualified by a pattern that matches it, is overridden and made -irrelevant (in the translation) by the qualifying pattern. Specifically, all extension -patterns and the default pattern are made irrelevant by the presence of the path -prefix pattern "/*" in a deployment descriptor. Patterns qualified by the "/*" -pattern violate the URLPatternSpec constraints of WebResourcePermission and -WebUserDataPermission names and must be rejected by the corresponding -permission constructors. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11933.1.3.1This URL pattern matches another pattern if they are related, by case sensitive -comparison, as follows: -- their pattern values are String equivalent, or -- this pattern is the path-prefix pattern "/*", or -- this pattern is a path-prefix pattern (that is, it starts with "/" and ends with -"/*") and the other pattern starts with the substring of this pattern, minus its -last 2 characters, and the next character of the other pattern, if there is one, is -"/", or -- this pattern is an extension pattern (that is, it starts with "*.") and the other -pattern ends with this pattern, or -- this pattern is the special default pattern, "/", which matches all other patterns. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12033.1.6After the PolicyConfiguration objects are linked, the commit method -must be called on all the PolicyConfiguration objects to place them in -service such that their policy statements will be assimilated by the corresponding -Policy providers. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:12111.5 - The following list defines changes to this contract that - apply to containers running without a Java SE SecurityManager. - - 1. The restrictions defined in Section 3.3, Permission to - Configure Policy need not be enforced. Also, the - containers of the application server must not be - denied permission to perform any operation that would - have been permitted in the presence of a SecurityManager. - - 2. Such containers are not required (before dispatching a - call) to associate an AccessControlContext with the call - thread (as otherwise required by Section 4.1.3, - Pre-dispatch Decision and Section 4.3.1, - EJB Pre-dispatch Decision). - - 3. When performing the operations defined in Section 4.7, - Checking AccessControlContext Independent Grants and in - Section 4.8, Checking the Caller for a Permission, - such containers must not employ the - SecurityManager.checkPermission and - AccessControlContext.checkPermission techniques defined - in these sections. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:12233.0 - This subcontract also applies to the translation of - authorization policy annotations that have an equivalent - representation in Jakarta EE deployment descriptor policy - constructs(i.e security-constraint, method-permission, - security-role-ref, and exclude-list elements) - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12333.1 - Independent of this specification, Jakarta EE deployment tools must translate and complete the declarative policy - statements appearing in deployment descriptors into a form suitable for securing applications on the platform. - These deployment tools must combine policy annotations in Java code with policy statements appearing in deployment - descriptors to yield complete representations of authorization policy suitable for securing applications on the platform. - The rules for combining authorization policy annotations with declarative policy statements are described in the - Jakarta Enterprise Beans, Jakarta Servlet, and Jakarta EE platform specifications. Independent of whether annotations - factor in the translation, the resulting policy statements may differ in form from the policy statements appearing - in the deployment descriptors. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12433.1.2 - When an application is composed of multiple web modules, a separate - policy context must be defined per module. This is necessary to ensure - that url-pattern based and servlet name based policy statements - configured for one module do not interfere with those configured - for another. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12533.1.4 - When an application is composed of multiple EJB jars, no two jars - that share at least one ejb-name value in common may share the same - policy context identifiers. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:12644.1.1 - Permission Names for Transport and Pre-Dispatch Decisions - The name of the permission checked in a transport or pre-dispatch - decision must be the value that would result from applying the Servlet - welcome file processing rules to the unqualified request URI minus the - context path. - - For the special case where this transformation of the request URI - yields the URLPattern /, the empty string URLPattern, , must be - used as the permission name. The welcome file processing rules are - defined in the Servlet specification. For the special case where the - empty string must be substituted for the / pattern in the permission - evaluation, all target related processing (including servlet mapping, - filter mapping, and form based login processing) must be performed - using the original pattern, /. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12744.6.1.4 - The EnterpriseBean object must only be returned when this handler - is activated within the scope of a container's processing of a - business method of the EJB Remote, Local, or ServiceEndpoint - interfaces of the EnterpriseBean object. The value null must be - returned if the bean implementation class does not implement the - jakarta.ejb.EnterpriseBean interface. - true -
    -
    falsetechnologyactivefalse
    - - diff --git a/install/jacc/docs/index.html b/install/jacc/docs/index.html deleted file mode 100755 index c9e9d0a774..0000000000 --- a/install/jacc/docs/index.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - Welcome to the Jakarta Authorization TCK, - - -
    -

    Welcome to the Jakarta EE Authorization Technology Compatibility Kit, - Version 2.1

    -

    Your Starting Point

    -
    -
    -

    Jakarta EE Authorization TCK 2.1 Documentation

    -

    The Jakarta EE Authorization Technology - Compatibility Kit (TCK) 2.1 documentation includes the - following:

    -
      -
    • -

      The Jakarta EE - Authorization TCK 2.1 Release Notes provides late-breaking - information about the Jakarta EE Authorization TCK, Version 2.1.

      -
    • -
    • -

      The Jakarta EE Authorization 2.1 Technology Compatibility Kit - User's Guide (HTML, - PDF) - provides the information you need to install, configure, and run the - Jakarta EE Authorization TCK. The User's Guide also contains the rules - you need to pass for certification.

      -
    • -
    • -

      The Javadoc - Assertion List lists all the javadoc assertions from Jakarta EE - Authorization 2.1 Specification.

      -
    • -
    • -

      The Specification - Assertion List lists all the specification assertions from - Jakarta EE Authorization 2.1 Specification.

      -
    • -
    -

    JT Harness Documentation

    -

    The online version of the JT Harness version 5.0 documentation is - available here.

    -
    -

    -
    Copyright 2013, 2022 Oracle and/or its affiliates. All - rights reserved.
    -

    - - diff --git a/install/jacc/other/testsuite.jtt b/install/jacc/other/testsuite.jtt deleted file mode 100644 index 516bd2df61..0000000000 --- a/install/jacc/other/testsuite.jtt +++ /dev/null @@ -1,3 +0,0 @@ -name=Java Persistence API Technology Compatibility Kit Version 1.0 -classpath=$TS_HOME/lib/tsharness.jar -testsuite=com.sun.ts.lib.harness.TS diff --git a/install/jacc/other/vehicle.properties b/install/jacc/other/vehicle.properties deleted file mode 100644 index 99c9a9cba3..0000000000 --- a/install/jacc/other/vehicle.properties +++ /dev/null @@ -1,45 +0,0 @@ -# -# Copyright (c) 2018 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 -# - -# A properties file to determine whether a test directory is service test -# directory, and if so the vehicles in which the tests should be run. -# -# An entry key is a test directory relative to the testsuite root (i.e., -# ${TS_HOME}/src) with unix file separator (forward slash). An entry value -# is a list of vehilce names separated by a space. Although other reasonable -# delimiters may also work, a single space is recommended for consistency. -# Acceptable vehicle names allowed in this standlone TCK are: -# - standalone -# -# This file may be modified for debugging purpose only. When testing for -# compatibility certification, the original version of this file must be -# used. Do NOT make modifications without maintaining a backup copy. -# -com/sun/ts/tests/jacc/web = standalone -com/sun/ts/tests/jacc/ejb/mr = ejblitesecuredjsp - -# If any test (sub-)directories that have been covered by entries above -# are not service test directories, list them in exclude.dir. It shoule -# arise rarely, and one possible senario could be: -# com/sun/ts/tests/foo is listed above as servicve tests, but later a -# non-service test dir com/sun/ts/tests/foo/non_service_tests is added, -# and you do not want to list a large number of subdirectories of foo -# in this properties file. -# If you get into this situation often, start questioning the test design -# The syntax: exclude.dir = com/sun/ts/tests/foo/non_service_test com/sun/ -# ts/tests/bar/non_service_test com/sun/ts/tests/buz/non_service_test -# -exclude.dir = diff --git a/install/jakartaee/bin/build.xml b/install/jakartaee/bin/build.xml index cc36f36c39..5dd669aec9 100644 --- a/install/jakartaee/bin/build.xml +++ b/install/jakartaee/bin/build.xml @@ -53,24 +53,8 @@ com/sun/ts/tests/jaxws/wsi/constants, com/sun/ts/tests/webservices12, com/sun/ts/tests/webservices13, - com/sun/ts/tests/websocket, - com/sun/ts/tests/securityapi"/> + com/sun/ts/tests/websocket"/> - - @@ -660,26 +644,6 @@ - - - - - - - - - - - - - - - - - - - - @@ -731,9 +695,6 @@ - @@ -779,28 +740,6 @@ - - - - - - @@ -819,7 +758,6 @@ - @@ -830,77 +768,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /cts.java.security -# -# The alternative to using this file is to directly put the properties -# from this file directly into JAVA_HOME/jre/lib/security/java.security -# - - -# authconfigprovider.factory: -# This property is used by the JSR-196 (JASPIC) Technology tests, so that -# the JASPIC tests can specify that the appserver use a non-default -# authconfigprovider. -# -authconfigprovider.factory=com.sun.ts.tests.jaspic.tssv.config.TSAuthConfigFactory diff --git a/install/jakartaee/bin/ts.jte b/install/jakartaee/bin/ts.jte index 199ad73d41..8c819a2497 100644 --- a/install/jakartaee/bin/ts.jte +++ b/install/jakartaee/bin/ts.jte @@ -148,9 +148,9 @@ javatest.timeout.factor=1 # technologies. # Known optional technologies for Web Profile include: # "jaxr", "connector", "jaxb", -# "jms", "javamail", "jacc", "jaspic", "wsmd" -# ex 1/ javaee.level=web connector jms jacc -# ex 2/ javaee.level=web jaspic +# "jms", "javamail", "wsmd" +# ex 1/ javaee.level=web connector jms +# ex 2/ javaee.level=web # ex 3/ javaee.level=web jms connector # ex 4/ etc... # @@ -184,7 +184,7 @@ javatest.timeout.factor=1 # (see comments for optional.tech.packages.to.ignore below) # ############################################################################### -#javaee.level=web connector jaxws jaxb javamail jacc jaspic wsmd +#javaee.level=web connector jaxws jaxb javamail wsmd javaee.level=full @@ -2160,22 +2160,6 @@ jaxrs_impl_name=jersey # This section contains all properties that are specific to JSR-196 Tests. # All default values are specific to GlassFish. # -# @servlet.is.jsr115.compatible This property is used by JASPIC tests -# to determine if the servlet container is a jsr 115 compatible -# container. (true = compatible to JSR 115, false = not compatible.) -# -# @soap.is.jsr115.compatible This may used by JASPIC tests to -# determin if the SOAP container is JSR 115 compatible. This is -# only used when running SOAP profile tests. -# -# @provider.configuration.file -# This property is used by JASPIC tests to configure TestSuite's -# AuthConfig Provider and points at an xml file which is used -# to register the JASPIC test providers into the current -# ACF. This file contaiins known/expected test provider info. -# Only app-context-id element can be edited to suit the -# impl under test. -# # @schema.file.location # This points to the directory that the provider-configuration.xsd # file will live. The provider-configuration.xsd is used to @@ -2206,25 +2190,11 @@ jaxrs_impl_name=jersey # using this property we enable the appclient container's # logging level to INFO # -# @vendor.authconfig.factory -# This property specifies vendor's authconfig factory class -# this will be used by JASPIC tests to register TestSuite's -# provider in Vendor's AuthConfig Factory. -# -# For example for SJSAS RI this value is -# -# vendor.authconfig.factory= -# com.sun.enterprise.security.jmac.config.GFAuthConfigFactory -# ########################################################################## -servlet.is.jsr115.compatible=true -soap.is.jsr115.compatible=false -provider.configuration.file=${javaee.home}/domains/domain1/config/ProviderConfiguration.xml schema.file.location=${javaee.home}/lib/schemas logical.hostname.servlet=server logical.hostname.soap=localhost appclient.log.output=true -vendor.authconfig.factory=com.sun.enterprise.security.jmac.config.GFAuthConfigFactory ########################################################################## # @servlet_waittime: Time in seconds to wait after HttpSession expires diff --git a/install/jakartaee/bin/ts.jtx b/install/jakartaee/bin/ts.jtx index 399fd3fbb9..c6b8e75742 100644 --- a/install/jakartaee/bin/ts.jtx +++ b/install/jakartaee/bin/ts.jtx @@ -68,12 +68,3 @@ com/sun/ts/tests/jpa/core/annotations/mapkeyenumerated/Client.java#elementCollec com/sun/ts/tests/jpa/core/annotations/mapkeytemporal/Client.java#elementCollectionTest_from_pmservlet com/sun/ts/tests/jpa/core/annotations/mapkeytemporal/Client.java#elementCollectionTest_from_stateless3 - -################ -# Security API -################ - -# -# -com/sun/ts/tests/securityapi/idstore/noidstore/Client.java#testIdentityStoreValidate_noIDStore -com/sun/ts/tests/securityapi/ham/sam/delegation/Client.java#testSAMDelegatesHAM diff --git a/install/jakartaee/bin/xml/impl/glassfish/javaee_vi.xml b/install/jakartaee/bin/xml/impl/glassfish/javaee_vi.xml index 6d1b043f7a..b370165f7c 100644 --- a/install/jakartaee/bin/xml/impl/glassfish/javaee_vi.xml +++ b/install/jakartaee/bin/xml/impl/glassfish/javaee_vi.xml @@ -96,21 +96,6 @@ - - - - - - - - - - - - - - - diff --git a/install/jakartaee/bin/xml/initldap.xml b/install/jakartaee/bin/xml/initldap.xml deleted file mode 100644 index ade4936ab7..0000000000 --- a/install/jakartaee/bin/xml/initldap.xml +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/internal/docs/jacc/JACCJavaDocAssertions.xml b/internal/docs/jacc/JACCJavaDocAssertions.xml deleted file mode 100644 index 440424f52c..0000000000 --- a/internal/docs/jacc/JACCJavaDocAssertions.xml +++ /dev/null @@ -1,846 +0,0 @@ - - - - - -60 -1 -JACC -JACC -Jakarta Authorization -2.0 - - -1 - - Creates a new EJBMethodPermission with the specified name and actions. - The name contains the value of the ejb-name element corresponding to an EJB in the application's deployment descriptor. The actions contains a methodSpec. The syntax of the actions parameter is defined as follows: methodNameSpec ::= methodName | emptyString methodInterface ::= Home | LocalHome | Remote | Local | ServiceEndpoint methodInterfaceSpec ::= methodInterface | emptyString methodParams ::= typeName | methodParams comma typeName methodParamsSpec ::= emptyString | methodParams methodSpec ::= null | methodNameSpec | methodNameSpec comma methodInterface | methodNameSpec comma methodInterfaceSpec comma methodParamsSpec A null or empty string methodSpec indicates that the permission applies to all methods of the EJB. A methodSpec with a methodNameSpec of the empty string matches all methods of the EJB that match the methodInterface and methodParams elements of the methodSpec. A methodSpec with a methodInterfaceSpec of the empty string matches all methods of the EJB that match the methodNameSpec and methodParams elements of the methodSpec. A methodSpec without a methodParamsSpec matches all methods of the EJB that match the methodNameSpec and methodInterface elements of the methodSpec. Each typeName appearing in methodParams must be the fully-qualified Java type name of a parameter of the target method. The order of the typeNames in methodParams must match the order of occurence of the corresponding parameters in the method signature of the target method(s). A methodSpec with an empty methodParamsSpec matches all 0 argument methods of the EJB that match the methodNameSpec and methodInterfaceSpec elements of the methodSpec. - -jakarta.security.jacc -EJBMethodPermission - - -java.lang.String -java.lang.String - - - - -2 - - Creates a new EJBMethodPermission with name corresponding to the EJBName and actions composed from methodName, methodInterface, and methodParams. - - -jakarta.security.jacc -EJBMethodPermission - - -java.lang.String -java.lang.String -java.lang.String -java.lang.String[] - - - - -3 - - Creates a new EJBMethodPermission with name corresponding to the EJBName and actions composed from methodInterface, and the Method object. - A container uses this constructor prior to checking if a caller has permission to call the method of an EJB. - -jakarta.security.jacc -EJBMethodPermission - - -java.lang.String -java.lang.String -java.lang.reflect.Method - - - - -4 - - Checks two EJBMethodPermission objects for equality. - EJBMethodPermission objects are equivalent if they have case sensitive equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - -jakarta.security.jacc -EJBMethodPermission - - -java.lang.Object - - - - -5 - - Returns a String containing a canonical representation of the actions of this EJBMethodPermission. - The Canonical form of an EJBMethodPermission is described by the following syntax description. methodNameSpec ::= methodName | emptyString methodInterface ::= Home | LocalHome | Remote | Local | ServiceEndpoint methodInterfaceSpec ::= methodInterface | emptyString methodParams ::= typeName | methodParams comma typeName methodParamsSpec ::= emptyString | methodParams methodSpec ::= null | methodNameSpec | methodNameSpec comma methodInterface | methodNameSpec comma methodInterfaceSpec comma methodParamsSpec - -jakarta.security.jacc -EJBMethodPermission - - - -6 - - Returns the hash code value for this EJBMethodPermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value every time it is called on a EJBMethodPermission object. The value returned by hashCode for a particular EJBMethodPermission need not remain consistent from one execution of an application to another. If two EJBMethodPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - -jakarta.security.jacc -EJBMethodPermission - - - -7 - - Determines if the argument Permission is implied by this EJBMethodPermission. - For this to be the case, The argument must be an instanceof EJBMethodPermission with name equivalent to that of this EJBMethodPermission, and the methods to which the argument permission applies (as defined in its actions) must be a subset of the methods to which this EJBMethodPermission applies (as defined in its actions) The name and actions comparisons described above are case sensitive. - -jakarta.security.jacc -EJBMethodPermission - - -java.security.Permission - - - - -8 - - Creates a new EJBRoleRefPermission with the specified name and actions. - -jakarta.security.jacc -EJBRoleRefPermission - - -java.lang.String -java.lang.String - - - - -9 - - Checks two EJBRoleRefPermission objects for equality. - EJBRoleRefPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - -jakarta.security.jacc -EJBRoleRefPermission - - -java.lang.Object - - - - -10 - - Returns a canonical String representation of the actions of this EJBRoleRefPermission. - - -jakarta.security.jacc -EJBRoleRefPermission - - - -11 - - Returns the hash code value for this EJBRoleRefPermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value, every time it is called on a EJBRoleRefPermission object. The value returned by hashCode for a particular EJBRoleRefPermission need not remain consistent from one execution of an application to another. If two EJBRoleRefPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - -jakarta.security.jacc -EJBRoleRefPermission - - - -12 - - Determines if the argument Permission is implied by this EJBRoleRefPermission. - For this to be the case, The argument must be an instanceof EJBRoleRefPermission with name equivalent to that of this EJBRoleRefPermission, and with the role reference equivalent to that of this EJBRoleRefPermission applies. The name and actions comparisons described above are case sensitive. - -jakarta.security.jacc -EJBRoleRefPermission - - -java.security.Permission - - - - -13 - - Used to add excluded policy statements to this PolicyConfiguration. - - -jakarta.security.jacc -PolicyConfiguration - - -java.security.PermissionCollection - - - - -14 - - Used to add a single excluded policy statement to this PolicyConfiguration. - - -jakarta.security.jacc -PolicyConfiguration - - -java.security.Permission - - - - -15 - - Used to add permissions to a named role in this PolicyConfiguration. - If the named Role does not exist in the PolicyConfiguration, it is created as a result of the call to this function. It is the job of the Policy provider to ensure that all the permissions added to a role are granted to principals mapped to the role. - -jakarta.security.jacc -PolicyConfiguration - - -java.lang.String -java.security.PermissionCollection - - - - -16 - - Used to add a single permission to a named role in this PolicyConfiguration. - If the named Role does not exist in the PolicyConfiguration, it is created as a result of the call to this function. It is the job of the Policy provider to ensure that all the permissions added to a role are granted to principals mapped to the role. - -jakarta.security.jacc -PolicyConfiguration - - -java.lang.String -java.security.Permission - - - - -17 - - Used to add unchecked policy statements to this PolicyConfiguration. - - -jakarta.security.jacc -PolicyConfiguration - - -java.security.PermissionCollection - - - - -18 - - Used to add a single unchecked policy statement to this PolicyConfiguration. - - -jakarta.security.jacc -PolicyConfiguration - - -java.security.Permission - - - - -19 - - Causes all policy statements to be deleted from this PolicyConfiguration and sets its internal state such that any additional operations attempted on the PolicyConfiguration will be rejected and cause an UnsupportedOperationException to be thrown. - This operation has no affect on any linked PolicyConfigurations other than removing any links involving the deleted PolicyConfiguration. - - -jakarta.security.jacc -PolicyConfiguration - - - - - - - -20 - - - This method is used to set to inService the state of the policy context whose interface is this Policy- - Configuration Object. Only those policy contexts whose state is inService will be included in the policy - contexts processed by the Policy.refresh method. A policy context whose state is inService may be - returned to the open state by calling the getPolicyConfiguration method of the PolicyConfiguration factory - with the policy context identifier of the policy context. - When the state of a policy context is inService, calling any method other than commit, delete, get- - ContextID, or inService on its PolicyConfiguration Object will cause an UnsupportedOperationException - to be thrown. - - -jakarta.security.jacc -PolicyConfiguration - - - -21 - - This method returns this object's policy context identifier. - - -jakarta.security.jacc -PolicyConfiguration - - - -22 - - Creates a relationship between this configuration and another such that they share the same principal-to-role mappings. - PolicyConfigurations are linked to apply a common principal-to-role mapping to multiple seperately manageable PolicyConfigurations, as is required when an application is composed of multiple modules. Note that the policy statements which comprise a role, or comprise the excluded or unchecked policy collections in a PolicyConfiguration are unaffected by the configuration being linked to another. - - -jakarta.security.jacc -PolicyConfiguration - - - -23 - - This method is used to determine if the policy context whose interface is this PolicyConfiguration Object is - in the inService state. - - - -jakarta.security.jacc -PolicyConfiguration - - -jakarta.security.jacc.PolicyConfiguration - - - - -24 - - Used to remove any excluded policy statements from this PolicyConfiguration. - -jakarta.security.jacc -PolicyConfiguration - - - -25 - - Used to remove a role and all its permissions from this PolicyConfiguration. - - -jakarta.security.jacc -PolicyConfiguration - - -java.lang.String - - - - -26 - - Used to remove any unchecked policy statements from this PolicyConfiguration. - -jakarta.security.jacc -PolicyConfiguration - - - -27 - - This method determines if a PolicyConfiguration with policy context identifier equivalent to the argument contextID, already exists in the Policy provider associated with the factory. - - -jakarta.security.jacc -PolicyConfigurationFactory - - -java.lang.String - - - - -28 - - This method is used to obtain an instance of the provider specific class that implements the PolicyConfiguration interface and that corresponds to one policy configuration within a provider. - The methods of the PolicyConfiguration interface are used to define the policy statements of the associated policy configuration. For a given value of policy context identifier, this method must always return the same instance of PolicyConfiguration and there must be at most one actual instance of a PolicyConfiguration with a given policy context identifier (during a process context). - -jakarta.security.jacc -PolicyConfigurationFactory - - -java.lang.String -boolean - - - - -29 - - This static method uses a system property to find and instantiate (via a public constructor) a provider specific factory implementation class. - The name of the provider specific factory implementation class is obtained from the value of the system property, jakarta.security.jacc.PolicyConfigurationFactory.provider - -jakarta.security.jacc -PolicyConfigurationFactory - - - -30 -when the class named by the system property could not be found including because the value of the system property has not been set. -jakarta.security.jacc -PolicyConfigurationFactory - -java.lang.ClassNotFoundException - - - -31 - - -jakarta.security.jacc -PolicyConfigurationFactory - - - -32 - - Authorization protected method that may be used by a Policy provider to activate the PolicyContextHandler registered to the context object key and cause it to return the corresponding policy context object from the container. - When a handler is activated by this method, it passes to the handler the context object key and the handler data associated with the calling thread. - - -jakarta.security.jacc -PolicyConfigurationFactory - - -java.lang.String - - - -33 - - - - - -jakarta.security.jacc -PolicyContext - - -java.lang.String - - - - -34 - - This static method returns the value of the policy context identifier associated with the thread on which the accessor is called. - - -jakarta.security.jacc -PolicyContext - - - -35 - - This method may be used to obtain the keys that identify the container specific context handlers registered by the container. - -jakarta.security.jacc -PolicyContext - - - -36 - - Authorization protected method used to register a container specific PolicyContext handler. - A handler may be registered to handle multiple keys, but at any time, at most one handler may be registered for a key. - -jakarta.security.jacc -PolicyContext - - -java.lang.String -jakarta.security.jacc.PolicyContextHandler -boolean - - - - -37 - - Authorization protected method used to modify the value of the policy context identifier associated with the thread on which this method is called. - - -jakarta.security.jacc -PolicyContext - - -java.lang.String - - - - -38 - - Authorization protected method that may be used to associate a thread-scoped handler data object with the PolicyContext. - The handler data object will be made available to handlers, where it can serve to supply or bind the handler to invocation scoped state within the container. - -jakarta.security.jacc -PolicyContext - - -java.lang.Object - - - - -39 - - This public method is used by the PolicyContext class to activate the handler and obtain from it the the context object identified by the (case-sensitive) key. - In addition to the key, the handler will be activated with the handler data value associated within the PolicyContext class with the thread on which the call to this method is made. Note that the policy context identifier associated with a thread is available to the handler by calling PolicyContext.getContextID(). - -jakarta.security.jacc -PolicyContextHandler - - -java.lang.String -java.lang.Object - - - - -40 - - This public method returns the keys identifying the context objects supported by the handler. - The value of each key supported by a handler must be a non-null String value. - -jakarta.security.jacc -PolicyContextHandler - - - -41 - - This public method returns a boolean result indicating whether or not the handler supports the context object identified by the (case-sensitive) key value. - -jakarta.security.jacc -PolicyContextHandler - - -java.lang.String - - - - -42 - - Determines whether this WebResourcePermission is less than, equal to, or greater than the specified object, and returns a negative integer, zero, or a positive integer respectively. - The behavior of this method must conform to the specification of the CompareTo method of interface Comparable. This method is used to sort WebResourcePermissions according to Servlet's path matching rules, and as necessary to implement best match for Servlet constraint selection and enforcement. WebResourcePermissions are sorted first by URL Pattern type. The sorting by URL Pattern type is done such that exact patterns (those not ending with * or /, or beginning with *.) sort less than path prefix patterns (those ending with /*), path prefix patterns sort less than extension patterns (those beginning with *.), and such that extension patterns sort less than the universal pattern /). Path prefix patterns are sorted first by pattern depth; with deeper patterns sorting less than shallower patterns. Same depth path prefix patterns are sorted by case sensitive lexical comparison of the same depth nodes, beginning with the root node, and continuing until a difference is found. Within pattern types other than path prefix patterns, same type patterns are sorted to case sensitive lexical order. Additional sorting by actions of pattern equivalent permissions is optional. - -jakarta.security.jacc -WebResourcePermission - - -java.lang.Object - - - - -43 - - Checks two WebResourcePermission objects for equality. - WebResourcePermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - -jakarta.security.jacc -WebResourcePermission - - -java.lang.Object - - - - -44 - - Returns a canonical String representation of the actions of this WebResourcePermission. - WebResourcePermission actions are canonicalized by sorting the HTTP methods into lexical order. - -jakarta.security.jacc -WebResourcePermission - - - -45 - - Returns the hash code value for this WebResourcePermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value, every time it is called on a WebResourcePermission object. The value returned by hashCode for a particular WebResourcePermission need not remain consistent from one execution of an application to another. If two WebResourcePermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - -jakarta.security.jacc -WebResourcePermission - - - -46 - - Determines if the argument Permission is implied by this WebResourcePermission. - For this to be the case, The argument must be an instanceof WebResourcePermission with name matched by this WebResourcePermission (according to the servlet matching rules), and the HTTP methods to which the argument permission applies (as defined in its actions) must be a subset of the HTTP methods to which this WebResourcePermission applies (as defined in its actions). The servlet matching rules are used to determine if the name of this WebResourcePermission matches the name of the argument permission. The names match if the values of the URL pattern portions of their names are related as follows: their URL patterns are lexically equivalent, or the URL pattern of this WebResourcePermission is a path-prefix pattern (that is, it ends with /*), and the path-prefix pattern (minus the last 2 characters) is an exact match for a prefix of the URL pattern of the argument permission, or the URL pattern of this WebResourcePermission is an extension pattern (that is, it begins with *.) and the substring of the extension pattern beginning with the . and extending to the end of the pattern, is an exact match for the end of the URL pattern of the argument permission. the URL pattern of this WebResourcePermission is the special pattern containing only the default character / (may be more than one /) which matches all other URL patterns. All of the comparisons described above are case sensitive. - -jakarta.security.jacc -WebResourcePermission - - -java.security.Permission - - - - -47 - - Creates a new WebResourcePermission with the specified name and actions. - The name contains a URL Pattern (as defined in the Java Servlet Specification). The URLPattern identifies the web resources to which the permission applies. The actions parameter contains a comma seperated list of HTTP methods. The syntax of the actions parameter is defined as follows: HTTPMethod ::= GET | POST | PUT | DELETE | HEAD | OPTIONS | TRACE HTTPMethodList ::= HTTPMethod | HTTPMethodList comma HTTPMethod HTTPMethodSpec ::= null | HTTPMethodList If duplicates occur in the HTTPMethodSpec they must be eliminated by the permission constructor. A null or empty string HTTPMethodSpec indicates that the permission applies to all HTTP methods at the resources identified by the URL pattern. - -jakarta.security.jacc -WebResourcePermission - - -java.lang.String -java.lang.String - - - - -48 - - Creates a new WebResourcePermission with name corresponding to the URLPattern, and actions composed from the array of HTTP methods. - -jakarta.security.jacc -WebResourcePermission - - -java.lang.String -java.lang.String[] - - - - -49 - - Creates a new WebResourcePermission from the HttpServletRequest object. - A container uses this constructor prior to checking if a caller has permission to perform a servlet request. - -jakarta.security.jacc -WebResourcePermission - - -HttpServletRequest - - - - -50 - - Checks two WebRoleRefPermission objects for equality. - WebRoleRefPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). The name and actions comparisons described above are case sensitive. - -jakarta.security.jacc -WebRoleRefPermission - - -java.lang.Object - - - - -51 - - Returns a canonical String representation of the actions of this WebRoleRefPermission. - - -jakarta.security.jacc -WebRoleRefPermission - - - -52 - - Returns the hash code value for this WebRoleRefPermission. - The properties of the returned hash code must be as follows: During the lifetime of an Java application, the hashCode method must return the same integer value, every time it is called on a WebRoleRefPermission object. The value returned by hashCode for a particular WebRoleRefPermission need not remain consistent from one execution of an application to another. If two WebRoleRefPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - -jakarta.security.jacc -WebRoleRefPermission - - - -53 - - Determines if the argument Permission is implied by this WebRoleRefPermission. - For this to be the case, The argument must be an instanceof WebRoleRefPermission with name equivalent to this WebRoleRefPermission, and with role reference equivalent to this WebRoleRefPermission (as defined in their actions). The comparisons described above are case sensitive. - -jakarta.security.jacc -WebRoleRefPermission - - -java.security.Permission - - - - -54 - - Creates a new WebRoleRefPermission with the specified name and actions. - - -jakarta.security.jacc -WebRoleRefPermission - - -java.lang.String -java.lang.String - - - - -55 - - Determines whether this WebUserDataPermission is less than, equal to, or greater than the specified object, and returns a negative integer, zero, or a positive integer respectively. - The behavior of this method must conform to the specification of the CompareTo method of interface Comparable. This method is used to sort WebUserDataPermissions according to Servlet's path matching rules, and as necessary to implement best match for Servlet constraint selection and enforcement. WebUserDataPermissions are sorted first by URL Pattern type. The sorting by URL Pattern type is done such that exact patterns (those not ending with * or /, or beginning with *.) sort less than path prefix patterns (those ending with /*), path prefix patterns sort less than extension patterns (those beginning with *.), and such that extension patterns sort less than the universal pattern /). Path prefix patterns are sorted first by pattern depth; with deeper patterns sorting less than shallower patterns. Same depth path prefix patterns are sorted by case sensitive lexical comparison of the same depth nodes, beginning with the root node, and continuing until a difference is found. Within pattern types other than path prefix patterns, same type patterns are sorted to case sensitive lexical order. Additional sorting by actions of pattern equivalent permissions is optional. - -jakarta.security.jacc -WebUserDataPermission - - -java.lang.Object - - - - -56 - - Checks two WebUserDataPermission objects for equality. - WebUserDataPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - -jakarta.security.jacc -WebUserDataPermission - - -java.lang.Object - - - - -57 - - Returns a canonical String representation of the actions of this WebUserDataPermission. - WebUserDataPermission actions are canonicalized by sorting the HTTP methods and transport Types into lexical order. - -jakarta.security.jacc -WebUserDataPermission - - - -58 - - Returns the hash code value for this WebUserDataPermission. - The properties of the returned hash code must be as follows: During the lifetime of an Java application, the hashCode method shall return the same integer value every time it is called on a WebUserDataPermission object. The value returned by hashCode for a particular EJBMethod permission need not remain consistent from one execution of an application to another. If two WebUserDataPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - -jakarta.security.jacc -WebUserDataPermission - - - -59 - - Determines if the argument Permission is implied by this WebUserDataPermission. - For this to be the case, The argument must be an instanceof WebUserDataPermission with name matched by this WebUserDataPermission (according to the servlet matching rules), and the HTTP methods to which the argument permission applies (as defined in its actions) must be a subset of the HTTP methods to which this WebUserDataPermission applies (as defined in its actions), and the transport types to which the argument permission applies (as defined in its actions) must be a subset of the Transport types to which this WebUserDataPermission applies (as defined in its actions). The servlet matching rules are used to determine if the name of this WebUserDataPermission matches the name of the argument permission. The names match if the values of the URL pattern portions of their names are related as follows: their URL patterns are lexically equivalent, or the URL pattern of this WebUserDataPermission is a path-prefix pattern (that is, it ends with /*), and the path-prefix pattern (minus the last 2 characters) is an exact match for a prefix of the URL pattern of the argument permission, or the URL pattern of this WebUserDataPermission is an extension pattern (that is, it begins with *.) and the substring of the extension pattern beginning with the . and extending to the end of the pattern, is an exact match for the end of the URL pattern of the argument permission. the URL pattern of this WebUserDataPermission is the special pattern containing only the default character / (there may be more than one /) which matches all other URL patterns. All of the comparisons described above are case sensitive. - -jakarta.security.jacc -WebUserDataPermission - - -java.security.Permission - - - - -60 - - Creates a new WebUserDataPermission with the specified name and actions. - The name contains a URL Pattern (as defined in the Java Servlet Specification). The URL Pattern identifies the web resources to which the permission applies. The actions parameter contains a comma separated list of HTTP methods followed by a comma separated list of transport protection types. The syntax of the actions parameter is defined as follows: HTTPMethod ::= Get | POST | PUT | DELETE | HEAD | OPTIONS | TRACE - HTTPMethodList ::= HTTPMethod | HTTPMethodList comma HTTPMethod - HTTPMethodSpec ::= emptyString | HTTPMethodList - transportType ::= CLEAR | INTEGRAL | CONFIDENTIAL | UNCONSTRAINED - transportTypeList ::= transportType | transportTypeList comma transportType - transportTypeSpec ::= emptyString | transportTypeList - actions ::= null | HTTPMethodSpec | HTTPMethodSpec colon transportTypeSpec - -If duplicates occur in either the HTTPMethodSpec or transportTypeSpec, they must be eliminated by the permission constructor. An empty string HTTPMethodSpec is a shorthand for a List containing all the possible HTTP methods. An empty string transportTypeSpec is a shorthand for a TransportTypeList containing the transportType value UNCONSTRAINED. A transportType of UNCONSTRAINED indicates that the associated HTTP methods at the web resources identified by the URL pattern may be accessed over any transport. The transportType UNCONSTRAINED is overridden by any other transportType associated with an equivalent URLPattern. - - -jakarta.security.jacc -WebUserDataPermission - - -java.lang.String -java.lang.String - - - - -61 - - Creates a new WebUserDataPermission with name corresponding to the URLPattern, and actions composed from the array of HTTP methods and the array of transport types. - - -jakarta.security.jacc -WebUserDataPermission - - -java.lang.String -java.lang.String[] -java.lang.String[] - - - - -62 - - Creates a new WebUserDataPermission from the HttpServletRequest object. - A container uses this constructor prior to checking if a caller has permission to perform a servlet request. - -jakarta.security.jacc -WebUserDataPermission - - -HttpServletRequest - - - - - diff --git a/internal/docs/jacc/JACCSpecAssertions.xml b/internal/docs/jacc/JACCSpecAssertions.xml deleted file mode 100644 index 7f61e79fc3..0000000000 --- a/internal/docs/jacc/JACCSpecAssertions.xml +++ /dev/null @@ -1,1927 +0,0 @@ - - - - - - 137 - 136 - JACC - JACC - Jakarta Authorization - 2.0 - - - - -
    -
    -
    -
    -
    - - - - -
    -
    -
    -
    -
    -
    -
    -
    - - - - -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    - - - - -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    - - - - - - - 2 - Legacy - - container - - - 3 - Legacy - - container - - - 4 - Each Policy provider that satisfies this contract must perform or delegate to another provider - all the permission evaluations requested via its interface in the JRE; not just those made by the container to - implement Jakarta EE security functionality. - - - provider - - - 5 - Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - - - container - - - 6 - Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - - - provider - - - 7 - Each provider must satisfy all of the authorization requirements of - the EJB and Servlet specifications corresponding to the target - platform. - - - provider - - - 8 - In the case of Servlet resources, the provider must be able to - associate a distinct policy context with each context root - (including context roots created to support virtual hosting) - hosted by the server. - - - provider - - - 9 - In protecting Servlet resources, a provider must select the policy -statements that apply to a request according to the constraint -matching and servlet mapping rules defined by the Servlet -specification. - - - provider - - - 10 - To support this contract in a Servlet environment, a container or its -deployment tools must create policy statements as necessary to -support Servlet's default role-ref semantic. - - - container - - - 11 - This contract must support providers that are unable to determine, -before returning from Policy.getPermissions(), all the permissions -that pertain to a subject/protection domain. - - - container - - - 12 - For a container to support this contract, it must execute in an -environment controlled by a J2SE security manager. - - - container - - - 13 - The evaluation of a permission corresponding to a resource must -identify the context of the resource's use such that different policy -can be applied to a resource used in different contexts (that is, -applications or instances of an application). - - - container - - - 14 - The security property policy.provider may be used to replace the default -java.security.Policy implementation class. Similarly, the security -property auth.policy.provider may be used to replace the default -javax.security.auth.Policy implementation class. - - - container - - - 15 - Each JRE of an application server must be provided with classes that implement -the PolicyConfigurationFactory class and PolicyConfiguration -interface. These classes must be compatible with the Policy implementation class -installed for use by the JRE. - - - container - - - 16 - If the provider is seeking to replace the Policy implementation used by the -JRE, then the JRE must be provided with an environment specific Policy -implementation class. If the JRE is running a J2SE 1.4 security environment, then -it must be provided with an implementation of the java.security.Policy -class. If the JRE is running a J2SE 1.3 security environment, it must be provided -with an implementation of the javax.security.auth.Policy class (that is, -a JAAS Policy object). - - - provider - - - 17 - A replacement Policy object must assume responsibility for performing all -policy decisions within the JRE in which it is installed that are requested by way -of the Policy interface that it implements. A replacement Policy object may -accomplish this by delegating non-jakarta.security.jacc policy decisions to -the corresponding default system Policy implementation class. - - - provider - - - 18 - A replacement -Policy object that relies in this way on the corresponding default Policy -implementation class must identify itself in its installation instructions as a -delegating Policy provider. - - - provider - - - 19 - The standard security properties mechanism for replacing a default system -Policy implementation (see Section 2.1, Policy Implementation Class) should -not be used to replace a default system Policy provider with a delegating Policy -provider. - - - provider - - - 20 - A J2SE 1.4 provider may support replacement of -the JAAS Policy object if and only if all jakarta.security.jacc policy decisions -performed by the replacement JAAS Policy object return the same result as when -the java.security.Policy interface is used. To satisfy this requirement, the -replacement JAAS Policy object must be compatible with the implementations of -PolicyConfigurationFactory and PolicyConfiguration interface -provided for use with the java.security.Policy implementation class. - - - provider - - - 21 - An application server or container must bundle or install the -jakarta.security.jacc standard extension. This package must include the -abstract jakarta.security.jacc.PolicyConfigurationFactory class, -the jakarta.security.jacc.PolicyConfiguration and -jakarta.security.jacc.PolicyContextHandler interfaces, and -implementations of the -jakarta.security.jacc.PolicyContextException exception, the -jakarta.security.jacc Permission classes, and the -jakarta.security.jacc.PolicyContext utility class. - - - container - - - 22 - To enable delegation of non-jakarta.security.jacc policy decisions to -default system Policy providers, all application servers must implement the -following Policy replacement algorithm. - -For each JRE of a Jakarta EE 9 or later version Jakarta EE application server, if the system property -jakarta.security.jacc.policy.provider is defined, the application server must -construct an instance of the class identified by the system property, -confirm that the resulting object is an instance of java.security.Policy, -and set, by calling the java.security.Policy.setPolicy, the resulting -object as the corresponding Policy object used by the JRE. - - - container - - - 23 - For each JRE of a Jakarta EE 9 or later version Jakarta EE application server, if the system property -jakarta.security.jacc.policy.provider is defined, the application -server must construct an instance of the class identified by the system property, -confirm that the resulting object is an instance of java.security.Policy, -and set, by calling the java.security.Policy.setPolicy method, the -resulting object as the corresponding Policy object used by the JRE. - - - container - - - 24 - Legacy assertion no longer holds - - - container - - - 25 - The getPolicyConfigurationFactory method must be used in every JRE -to which the components of the application or module are being deployed to find -or instantiate PolicyConfigurationFactory objects. - - - tools - - - 26 - The getPolicyConfiguration method of the factories must be used to -find or instantiate PolicyConfiguration objects corresponding to the -application or modules being deployed. - - - tools - - - 27 - The declarative authorization policy statements derived from application or -module deployment descriptor(s) must be translated to create instances of the -corresponding jakarta.security.jacc Permission classes. - - - tools - - - 28 - Methods of the PolicyConfiguration interface must be used with the -permissions resulting from the translation to create policy statements within the -PolicyConfiguration objects. - - - tools - - - 29 - The PolicyConfiguration objects must be linked such that the same -principal-to-role mapping will be applied to all the modules of the application. - - - tools - - - 30 - Independent of this specification, Jakarta EE deployment tools must translate and -complete the declarative policy statements appearing in deployment descriptors -into a form suitable for securing applications on the platform. - - - tools - - - 31 - A policy context is in one of three states and all -implementations of the PolicyConfiguration interface must implement the state -semantics defined in this section. - -- open -A policy context in the open state must be available for configuration by any -of the methods of the PolicyConfiguration interface. A policy context in the -open state must not be assimilated at Policy.refresh into the policy statements -used by the Policy provider in performing its access decisions. - -- inService -A policy context in the inService state must be assimilated at Policy.refresh -into the policy statements used by its provider. When a provider's refresh -method is called, it must assimilate only policy contexts that are in the inService -state and it must ensure that the policy statements put into service for -each policy context are only those defined in the context at the time of the call -to refresh. A policy context in the inService state must be unavailable for -additional configuration. A policy context in the inService state must be transitioned -to the open state when it is returned as a result of a call to getPolicy- -Configuration. A policy context is transitioned to the inService state by -calling the commit method, and only a policy context in the open state may be -transitioned to the inService state. - -- deleted -A policy context in the deleted state must be unavailable for configuration and -it must be unavailable for assimilation into its associated Provider. A policy -context in the deleted state must be transitioned to the open state when it is -returned as a result of a call to getPolicyConfiguration. A policy context is -transitioned to the deleted state by calling the delete method. - - - tools - - - 32 - A servlet container is responsible -for mapping the target name or address information of an HTTP request to the -appropriate hostname. - - - container - - - 33 - A reference to a PolicyConfiguration object must be obtained by calling the -getPolicyConfiguration method on the -PolicyConfigurationFactory implementation class of the provider -configured into the container. The policy context identifier used in the call to the -getPolicyConfiguration method must be a String composed as -described in Section 3.1.2, Servlet Policy Context Identifiers, on page 18. The -value true must be passed as the second parameter in the call to -getPolicyConfiguration to ensure that any and all policy statements are -removed from the policy context associated with the returned -PolicyConfiguration. - - - tools - - - 34 - A WebResourcePermission and a WebUserDataPermission object must be -instantiated for each distinct url-pattern occurring in the securityconstraint -elements that contain an auth-constraint naming no roles (i.e -an excluding auth-constraint). The permissions must be constructed using -the qualified (as defined in Qualified URL Pattern Names) pattern as their name -and with actions defined by the union of the HTTP methods named or implied -by all of the collections containing the pattern and occurring in a constraint with -an excluding auth-constraint. The constructed permissions must be added to -the excluded policy statements by calling the addToExcludedPolicy method -on the PolicyConfiguration object. - - - tools - - - 35 - A WebResourcePermission must be instantiated for each distinct combination -in the cross-product of url-pattern and role-name occurring in the -security-constraint elements that contain an auth-constraint -naming roles. When an auth-constraint names the reserved role-name, -"*", all of the patterns in the containing security-constraint must be -combined with all of the roles defined in the web application. - - - tools - - - 36 - Each WebResourcePermission object must be constructed using the qualified pattern as -its name and with actions defined by the union of the HTTP methods named or -implied by the collections containing the pattern and occurring in a constraint that -names (or implies via "*") the role to which the permission is being added. The -resulting permissions must be added to the corresponding roles by calling the -addToRole method on the PolicyConfiguration object. - - - tools - - - 37 - The -resulting permissions must be added to the corresponding roles by calling the -addToRole method on the PolicyConfiguration object. - - - tools - - - 38 - A WebResourcePermission must be instantiated for each distinct urlpattern -occurring in the security-constraint elements that do not -contain an auth-constraint. Each WebResourcePermission object must be -constructed using the qualified pattern as its name and with actions defined by the -union of the HTTP methods named or implied by the collections containing the -pattern and occurring in a security-constraint without an authconstraint. -The resulting permissions must be added to the unchecked policy -statements by calling the addToUncheckedPolicy method on the -PolicyConfiguration object. - - - tools - - - 39 - The WebResourcePermission objects resulting from -the translation of a security-constraint that does not contain an authconstraint -must be added to the unchecked policy statements by calling -addToUncheckedPolicy on the PolicyConfiguration object. - - - tools - - - 40 - The -WebResourcePermission objects resulting from the translation of a securityconstraint -containing an auth-constraint that named no roles must be -added to the excluded policy statements by calling addToExcludedPolicy on -the PolicyConfiguration object. - - - tools - - - 41 - A WebUserDataPermission must be instantiated for each distinct combination -of url-pattern and acceptable connection type resulting from the processing -of the security-constraint elements that do not contain an excluding -auth-constraint. The mapping of security-constraint to acceptable -connection type must be as defined in Mapping Transport Guarantee to Connection -Type. Each WebUserDataPermission object must be constructed using the -qualified pattern as its name and with actions defined by appending a -representation of the acceptable connection type to the union of the HTTP -methods named or implied by the collections containing the pattern and occurring -in a security-constraint that maps to the connection type and that does not -contain an excluding auth-constraint. The resulting permissions must be -added to the unchecked policy statements by calling the -addToUncheckedPolicy method on the PolicyConfiguration object. - - - tools - - - 42 - A transport-guarantee (in a user-data-constraint) of NONE, or a -security-constraint without a user-data-constraint, indicates that -the associated URL patterns and HTTP methods may be accessed over any -(including an unprotected) transport. A transport-guarantee of -INTEGRAL indicates that acceptable connections are those deemed by the -container to be integrity protected. A transport-guarantee of -CONFIDENTIAL indicates that acceptable connections are those deemed by the -container to be protected for confidentiality. - - - tools - - - 43 - For each security-role-ref appearing in the deployment descriptor a -corresponding WebRoleRefPermission must be created. The name used in the -construction of each WebRoleRefPermission must be the servlet-name in -whose context the security-role-ref is defined. The actions used to -construct the permission must be the value of the role-name (that is the -reference), appearing in the security-role-ref. - - - tools - - - 44 - The deployment tools must call the addToRole method on the - PolicyConfiguration object to add the WebRoleRefPermission object - resulting from the translation to the role identified in the role-link - appearing in the security-role-ref. - - - tools - - - 45 - For each servlet element in the deployment descriptor a WebRoleRefPermission must -be created for each security-role whose name does not appear as the rolename -in a security-role-ref within the servlet element. Each such -WebRoleRefPermission must be created with action (that is, reference) -corresponding to the role-name and added to the role with the same name (as -the reference) by calling the addToRole method on the -PolicyConfiguration object. - - - tools - - - 128 - - If the any authenticated user role-name, **, occurs in an auth-constraint, - a WebResourcePermission must also be added to the ** role. - - - - -This assumes there is no role explicitly defined in DD for "**" but - there must be a WebResourcePermission added to the ** role. - -To test, create DD entry, add "**" for auth-constraint, deploy and - validate a WebResourcePermission was added to the "**" role. - (added as part of JACC 1.5 ) - - - - 129 - - A WebResourcePermission must be instantiated for each distinct combination - in the cross-product of url-pattern and role-name occurring in the - security-constraint elements that contain an auth-constraint - naming roles. When an auth-constraint names the reserved role-name, - "*", all of the patterns in the containing security-constraint must be - combined with all of the roles defined in the web application; which must - not include the role "**" unless the application has defined an - application role named "**". - - - - -This is MR that added onto assertion ID 35. - -Test same as assertion 35 - except do not define an app role named "**" so - that we can validate there was no role "**" included in the combination of - all roles + all security constraint patterns. - (added as part of JACC 1.5 ) - - - - 130 - - If the any authenticated user role-name, **, does not appear in a - security-role-ref within the servlet, a WebRoleRefPermission must also be added for it. - The name of each such WebRoleRefPermission must be the servlet-name - of the corresponding servlet element. - - - - - similar to assertion id 43 but this assertion adds a bit more to it as - (added as part of JACC 1.5 ) - - - - 131 - - For each security-role defined in the deployment descriptor and the - any uthenticated user role, **, an additional WebRoleRefPermission - must be added to the corresponding role by calling the addToRole method - on the PolicyConfiguration object. - - - - (added as part of JACC 1.5 ) - - - - 132 - - A WebResourcePermission and a WebUserDataPermission must be obtained - for each url-pattern in the deployment descriptor and the default pattern, "/", - that is not combined by the web-resource-collection elements of the - deployment descriptor with every possible HTTP method value. - - - - (added as part of JACC 1.5 to support deny-uncovered-methods) - assertion id 117 was origianally covering this but some of that assertion was - removed for this MR. This MR removes the following from assertion 117: - "The resulting permissions must be added to the unchecked policy - statements by calling the addToUncheckedPolicy method on the - PolicyConfiguration object." - - - - 133 - - If a deny uncovered HTTP methods semantic is in effect for the web module associated with the - PolicyContext, the resulting permissions must be added to the excluded policy - statements by calling the addToExcludedPolicy method on the - PolicyConfiguration object. Otherwise, the permissions must be added to - the unchecked policy statements by calling the addToUncheckedPolicy - method on the PolicyConfiguration object. - - - - (added as part of JACC 1.5 to support deny-uncovered-methods) - - - - 134 - - These addToRole calls must be made for any role-name used in the method- - permision which may include the role-name **; which, by default, is mapped to - any authenticated user. - - - - (added as part of JACC 1.5 to support any authenticated user for ejbs) - - - - 135 - - If the any authenticated user role-name, **, does not appear in a - security-role-ref within the element, a EJBRoleRefPermission must also - be added for it. The name of each such EJBRoleRefPermission must be the value of the ejb-name - element within the element in which the security-role-ref elements could - otherwise occur. - - - - (added as part of JACC 1.5 to support any authenticated user for ejbs) - - - - 136 - - For the any authenticated user role, **, and unless an - application specific mapping has been established for this role, the provider must - ensure that all permissions added to the role are granted to any authenticated user. - - - - (added as part of JACC 1.5 to support any authenticated user) - - - - 46 - an application server must establish EJB policy -context identifiers sufficient to differentiate all instances of the deployment of an -EJB jar on the application server, or on any other application server with which -the server may share the same policy statement repository. - - - tools - - - 47 - An EJBMethodPermission object must be created for each role-name or -unchecked element contained in each method-permission element -appearing in the deployment descriptor. - - - tools - - - 48 - The name of each EJBMethodPermission -must be the ejb-name as defined in the method element of the methodpermission -element. The actions used in the permission construction must be -obtained by translating the contents of the method element into a method -specification according to the methodSpec syntax defined in the documentation of -the EJBMethodPermission class. - - - tools - - - 49 - If the method-permission element contains the unchecked element, -then the deployment tools must call the addToUncheckedPolicy method to -add the permission resulting from the translation to the -PolicyConfiguration object. - -Alternatively, if the method-permission -element contains one or more role-name elements, then the deployment tools -must call the addToRole method to add each of the permissions resulting from -the translation to the corresponding role of the PolicyConfiguration object. - - - tools - - - 50 - An EJBMethodPermission object must be created for each method element -occurring in the exclude-list element of the deployment descriptor. The -name and actions of each EJBMethodPermission must be established as described -in Section 3.1.5.1, Translating EJB method-permission Elements. -The deployment tools must use the addToExcludedPolicy method to add -the EJBMethodPermission objects resulting from the translation of the -exclude-list to the excluded policy statements of the -PolicyConfiguration object. - - - tools - - - 51 - For each security-role-ref element appearing in the deployment -descriptor, a corresponding EJBRoleRefPermission must be created. The name of -each EJBRoleRefPermission must be obtained as described for -EJBMethodPermission objects. The actions used to construct the permission must -be the value of the role-name (that is the reference), appearing in the -security-role-ref. The deployment tools must call the addToRole -method on the PolicyConfiguration object to add a policy statement -corresponding to the EJBRoleRefPermission to the role identified in the rolelink -appearing in the security-role-ref. - - - tools - - - 52 - The application server's deployment tools must translate the declarative -authorization policy appearing in the application or module deployment -descriptor(s) into policy statements within the Policy providers used by the -containers to which the components of the application or module are being -deployed. - - - tools - - - 53 - When a module is deployed, its policy context must be linked to the policy -context of every other module with which it must share the same principal-to-role -mapping. When an application is deployed, the policy contexts of every module of -the application must be linked to the policy contexts of every other module of the -application with which it shares a common Policy provider. Policy contexts are -linked by calling the linkConfiguration method on the PolicyConfiguration -objects of the provider. - - - tools - - - 54 - Once the translation, linking, and committing has occurred, a call must be -made to Policy.refresh on the Policy provider used by each of the containers -to which the application or module is being deployed. The calls to -Policy.refresh must occur before the containers will accept requests for the -deployed resources. - - - tools - - - 55 - The policy context identifiers corresponding to the deployed application or -module must be recorded in the application server so that they can be used by -containers to establish the policy context as required by Section 4.6, Setting the -Policy Context of the Policy Decision and Enforcement Subcontract, and such -that the Deployer may subsequently remove or modify the corresponding policy -contexts as a result of the undeployment or redeployment of the application. - - - tools - - - 56 - A -deployment tool indicates that a policy context is to be removed from service -either by calling getPolicyConfiguration with the identifier of the policy context -on the provider's PolicyConfigurationFactory or by calling delete on the -corresponding PolicyConfiguration object. If the getPolicyConfiguration method -is used, the value true should be passed as the second argument to cause the -corresponding policy statements to be deleted from the context. - - - tools - - - 57 - To ensure that there is not a period during undeployment when the removal of -policy statements on application components renders what were protected -components unprotected, the application server must stop accepting requests for -the application's components before undeploying an application or module. - - - tools - - - 58 - After the policy -contexts are marked for removal from service, a call must be made to -Policy.refresh on all of the Policy providers from which at least one module -of the application or module was marked for removal from service. - - - tools - - - 59 - To facilitate redeployment to an existing policy configuration, container -deployment tools may also support a mode in which they do not delete the -PolicyConfiguration objects associated with the application or module -being undeployed. - - - tools - - - 60 - Containers are not required to deploy to an existing policy configuration. -Containers that chose to provide this functionality must satisfy the following -requirements. -To associate an application or module with an existing set of linked policy -contexts, the identifiers of the existing policy contexts must be applied by the -relevant containers in fulfilling their obligations as defined in the Policy Decision -and Enforcement Subcontract. The policy contexts should be verified for -existence, by calling the inService method of the -PolicyConfigurationFactory of the Policy providers of the relevant -containers. The deployment tools must call Policy.refresh on the Policy -provider of each of the relevant containers, and the containers must not accept -requests for the deployed resources until these calls have completed. - - - tools - - - 61 - Containers are not required to implement redeployment functionality. - - tools - - - 62 - Containers -that chose to provide this functionality must satisfy the following requirements. - -To ensure redeployment does not create a situation where the removal of -policy statements on application components renders what were protected -components unprotected, the application server must stop accepting requests for -the application's components before redeployment begins. The application server -must not resume processing requests for the application's components until after -the calls to Policy.refresh, described below, have completed. - -To redeploy a module, the deployment tools must indicate at all of the Policy -providers to which the module is to be redeployed that the policy context -associated with the module is to be removed from service. If the module is to be -redeployed to the same policy context at a provider, all policy statements must be -removed from the policy context at the provider. - -After the policy contexts have been marked for removal from service and emptied of policy statements (as -necessary), the deployment tools must translate the declarative authorization -policy appearing in the module's deployment descriptor into PolicyConfiguration -objects within the Policy providers at which the module is being redeployed. - - After the translation, the PolicyConfiguration objects must be linked, as -necessary, to the policy context of every other module in the same provider with -which the module must share the same principal-to-role mappings. - -After the module is linked, the commit method must be called on the -PolicyConfiguration objects. After commit has been called, a call must be -made to Policy.refresh on the Policy provider used by each of the containers -to which the module has been redeployed. - - - tools - - - 63 - the provider must include an implementation of the -jakarta.security.jacc.PolicyConfigurationFactory class along -with a matched implementation of a class that implements the -jakarta.security.jacc.PolicyConfiguration interface. - - - provider - - - 64 - In addition to -providing a PolicyConfiguration interface for integration with the -application server deployment tools, the provider must also include a -management interface for policy administrators to use to grant the collections of -permissions that comprise roles, to principals. This interface need not be -standardized. - - - provider - - - 65 - The provider must ensure that all of the permissions added to a role in a policy -context are granted to any principal mapped to the role by the policy -administrator. The provider must ensure that the same principal-to-role mappings -are applied to all linked policy contexts. - - - provider - - - 66 - The provider must ensure that excluded policy statements take precedence -over overlapping unchecked policy statements, and that both excluded and -unchecked policy statements take precedence over overlapping role based policy -statements. - - - provider - - - 67 - The getPolicyConfigurationFactory, and inService methods of the -abstract factory class, -jakarta.security.jacc.PolicyConfigurationFactory, must throw a -SecurityException when called by an AccessControlContext that has not been -granted the setPolicy SecurityPermission. -The getPolicyConfiguration method of all implementations of the -PolicyConfigurationFactory abstract class must throw a -SecurityException when called by an AccessControlContext that has not been -granted the setPolicy SecurityPermission. - - - provider - - - 68 - All of the public methods of all of the concrete implementations of the -PolicyConfiguration interface must throw a SecurityException when called -by an AccessControlContext that has not been granted the setPolicy -SecurityPermission. - - - provider - - - 69 - In cases where a required permission is not held by a caller, the -implementation must return without changing the state of the policy statement -repository. - - - provider - - - 70 - The containers of an application server must be granted the getPolicy -SecurityPermission and the setPolicy SecurityPermission. - - - provider - - - 71 - The Servlet container must construct (or reuse) a WebUserDataPermission object -using the request URI minus the context path as the name and with actions -composed from the HTTP method of the request and a protection value describing -the transport layer protection of the connection on which the request arrived. -The protection value used in the permission construction must be -determined as follows: - - If the request arrived on a connection deemed by the container to be protected -for confidentiality, a protection value of :CONFIDENTIAL must be used. -- If the request arrived on a connection deemed by the container to be protected -for integrity (but not confidentiality), a protection value of :INTEGRAL must be used. -- If the request arrived on a connection deemed by the container to be unprotected, - the actions used in the permission construction must contain only the HTTP - method of the request. - -The Servlet container must use one of the methods described in Section 4.7, -Checking AccessControlContext Independent Grants to test if access to the -resource using the method and connection type encapsulated in the -WebUserDataPermission is permitted. If a SecurityException is thrown in the -permission determination, it must be caught, and the result of the determination -must be that access to the resource using the method and connection type is not -permitted. If access is not permitted, the request must be redirected as defined by -the Servlet Specification. If access is permitted, the request must be subjected to a -pre-dispatch decision. - - - container - - - 72 - The Servlet container must construct (or reuse) a WebResourcePermission object -using the request URI minus the context path as the name and with actions -corresponding to the HTTP method of the request. - - - container - - - 73 - If a SecurityException is thrown in the permission determination, it -must be caught, and the result of the determination must be that the permission is -not granted to the caller. The Servlet container may only dispatch the request to -the web resource if theWebResourcePermission is determined to be granted to the -caller. Otherwise the request must be rejected with the appropriate HTTP error -message as defined by the Servlet Specification. - - - container - - - 74 - Before it dispatches a call to a web resource, the container must associate with -the call thread an AccessControlContext containing the principals of (only) the -target component runAs identity (as defined in Section 4.5, Component runAs -Identity). - - - container - - - 75 - When a call is made from a web resource to isUserInRole(String -roleName) the implementation of this method must construct (or reuse) a -WebRoleRefPermission object using the servlet-name of the calling web resource -as the name and with actions equal to the roleName used in the call. - - - container - - - 76 - If a -SecurityException is thrown in the permission determination, it must be caught, -and the result of the determination must be that the permission is not granted to -the caller. If it is determined that the WebRoleRefPermission has been granted to -the caller, isUserInRole must return true. Otherwise the return value must be false. - - - container - - - 77 - The policy statements of the identified PolicyConfiguration are filtered to -select the set of statements that refer to a permission of the same type as the -checked permission and that have as their name the url-pattern that is the bestmatch -to the name of the checked permission. The algorithm for determining the -best matching url-pattern is described in Section 4.2.2.1, Servlet URL-Pattern -Matching Rules. The resulting policy statements are then reduced to the set -whose actions match the actions of the checked permission. If the resulting set is -empty, the evaluation may terminate, and the result of the evaluation must be that -the checked permission is determined to be unconstrained and thus implicitly -granted. - - - container - - - 78 - If the resulting set is not empty, and it contains one or more excluded policy -statements, the evaluation may terminate and the checked permission must be -determined not to be granted. - -Otherwise, if the set contains one or more unchecked policy statements, -the evaluation may terminate and the checked permission must be -determined to be granted. If the resulting set contained neither -excluded or unchecked policy statements, then the access control context may -only be determined to have been granted the checked permission if it has been -accorded a permission with name equal to the best-matching pattern, and with -actions equal to the actions of the checked permission. - - - container - - - 79 - URL pattern matching must be guided by pattern type such that exact patterns -(those not ending with * or /, or beginning with *.) must match better than -path prefix patterns (those ending with /*) - - and such that path prefix patterns must match better than extension patterns - (those beginning with *.), - - and suchthat extension patterns must match better than the universal pattern /). - -Among path prefix matches, longer string length patterns must match better than shorter -patterns. - - - container - - - 80 - EJB containers must enforce the authorization policies established for EJB -resources as a result of the deployment of application modules containing EJB -resources. - - - container - - - 81 - The EJB container must construct (or reuse) an EJBMethodPermission object with -name corresponding to the ejb-name of the target resource. The actions used in the -permission construction must completely specify the method of the EJB by -identifying the method interface, method name, and method signature as defined -for a methodSpec in the documentation of the EJBMethodPermission class. - - - container - - - 82 - If a SecurityException is -thrown in the permission determination, it must be caught, and the result of the -determination must be that the permission is not granted to the caller. The EJB -container may only dispatch the request to the EJB resource, if the -EJBMethodPermission is determined to be granted to the caller. Otherwise the -request must be rejected with the appropriate RMISecurityException, as defined -by the EJB specification. -Before it dispatches a call to an EJB, the container must associate with the call -thread an AccessControlContext containing the principals of only the target EJB -runAs identity (as defined in Section 4.5, Component runAs Identity). - - - container - - - 83 - When an EJB makes a call to isCallerInRole(String roleName) the -implementation of this method must construct (or reuse) an -EJBRoleRefPermission object using the ejb-name of the EJB making the call as -the name and with the value of the roleName as actions. - - - container - - - 84 - If a -SecurityException is thrown in the permission determination, it must be caught, -and the result of the determination must be that the permission is not granted to -the caller. If it is determined that the EJBRoleRefPermission has been granted to -the caller, then isCallerInRole must return true. Otherwise the return value must -be false. - - - container - - - 85 - The policy statements of the PolicyConfiguration identified by calling the -getContextID method on the PolicyContext utility class must be tested to -determine if they match the permission being evaluated. - - - provider - - - 86 - If one or more excluded -policy statements match the checked permission, the evaluation may terminate -and the checked permission must be determined not to be granted. - - - provider - - - 87 - if one or more unchecked policy statements match the checked permission, the -checked permission must be determined to be granted independent of access -control context. If neither of the excluded or unchecked comparisons yield a -match, then the access control context may only be determined to have been -granted the checked permission if a matching permission has been accorded to the -access control context. - - - provider - - - 88 - An excluded or unchecked policy statement matches a checked permission if the -policy statement satisfies the rules for matching a granted permission to the -checked permission. - - - provider - - - 89 - A granted EJBMethodPermission matches a checked EJBMethodPermission -if their names are equivalent, and if the method specification in the actions of the -grnted permission matches the method specification in the actions of the che?ked -permission (as described in the definition of the EJBMethodPermission class). - - - provider - - - 90 - One or more granted EJBRoleRefPermission objects match a checked -EJBRoleRefPermission if their names and actions are equivalent to the name of -the checked permission. - - - provider - - - 91 - By default (and unless otherwise specified in the EJB or Servlet -specifications), components are configured such that they are assigned the identity -of their caller (such as it is) as their runAs identity. Alternatively, a Deployer may -choose to assign an environment specific identity as a component runAs identity. -In this case, the container must establish the specified identity as the component -runAs identity independent of the identity of the component caller. - - - container - - - 92 - When a Deployer configures an environment specific component identity -based on a deployment descriptor specification that the component run with an -identity mapped to a role, those responsible for defining the principal-to-role -mapping must ensure that the specified identity is mapped to the role. - - - provider - - - 93 - A container establishes a component's runAs identity by associating an -AccessControlContext with the component's thread of execution. The container -must ensure that the AccessControlContext includes a SubjectDomainCombiner; -and the container must protect the AccessControlContext associated with a -running component such that, by default, the component is not granted -permissions sufficient to modify the AccessControlContext. - - - provider - - - 94 - A policy context identifier is set on a thread by calling the setContextID method -on the PolicyContext utility class. The value of a thread policy context identifier -is null until the setContextID method is called. Before invoking policy to evaluate -a transport guarantee or to perform a pre-dispatch decision, and before -dispatching into a Servlet or EJB component, a container must ensure that the -thread policy context identifier identifies the policy context corresponding -to the instance of the module or application for which the operation is being -performed. -Containers must be granted the setPolicy SecurityPermission independent -of policy context identifier (or in all policy contexts) as they need this permission -to set the policy context identifier. - - - container - - - 95 - This specification requires that containers register policy context handlers with -the PolicyContext utility class such that Policy providers can invoke these -handlers to obtain additional context to apply in their access decisions. Policy -context handlers are objects that implement the PolicyContextHandler interface. - - - container - - - 96 - All of the required context handlers must -return the value null when activated outside of the scope of a container's -processing of a component request. Policy providers must not call methods on or -modify the objects returned by the context handlers if these actions will cause the -container to fail in its processing of the associated request.. - - - container - - - 97 - All EJB and Servlet containers must register a PolicyContextHandler whose -getContext method returns a javax.security.auth.Subject object when invoked with -the key javax.security.auth.Subject.container. When this handler is activated -as the result of a policy decision performed by a container before dispatch -into a component, this handler must return a Subject containing the principals - - - container - - - 98 - All EJB containers must register a PolicyContextHandler whose getContext -method returns a javax.xml.soap.SOAPMessage object when invoked with the -key javax.xml.soap.SOAPMessage. If the request being processed by the -container arrived as a SOAP request at the ServiceEndpoint method interface, the -container must return the SOAP message object when this handler is activated. -Otherwise, this handler must return the value null. - - - container - - - 99 - All Servlet containers must register a PolicyContextHandler whose getContext -method returns a javax.servlet.http.HttpServletRequest object when invoked with -the key javax.servlet.http.HttpServletRequest. When this handler is activated, -the container must return the HttpServletRequest object corresponding to the -component request being processed by the container. - - - container - - - 100 - All EJB containers must register a PolicyContextHandler whose getContext -method returns a jakarta.ejb.EnterpriseBean object when invoked with the key -jakarta.ejb.EnterpriseBean. When this handler is activated, the container must -return the EnterpriseBean object corresponding to theEJB component request being -processed by the container. - - - container - - - 101 - All EJB containers must register a PolicyContextHandler whose getContext -method returns an array of objects (Object[]) containing the arguments of the EJB -method invocation (in the same order as they appear in the method signature) -when invoked with the key jakarta.ejb.arguments. The context handler must -return the value null when called in the context of a SOAP request that arrived at -the ServiceEndpoint method interface. Otherwise, the context handler must return -the array of objects corresponding to the parameters of the EJB component -invocation. If there are no parameters in the method signature, the context handler -must return an empty array of Object (i.e. Object[0]). - - - container - - - 102 - A container must use one of the following techniques to check an instance of a -permission for which policy is defined independent of AccessControlContext. - -- The container calls AccessControlContext.checkPermission with -the permission being checked as argument. The call to checkPermission -may be made on any AccessControlContext. If checkPermission throws -an AccessControlException, the permission is not granted. Otherwise the -permission is granted. - -- The container calls AccessController.checkPermission with the -permission being checked. The value of the current thread?s -AccessControlContext is irrelevant in the access determination. If -checkPermission throws an AccessControlException, the checked -permission is not granted. Otherwise the permission is not granted. - -- The container calls SecurityManager.checkPermission with the -permission being checked. If checkPermission throws an -AccessControlException, the checked permission is not granted. Otherwise the -permission is granted. - -- The container calls Policy.implies with two arguments; the -permission being checked and a ProtectionDomain that need not be -constructed with principals. The checked permission is granted if -Policy.implies returns true. Otherwise, the permission is not granted. - -- The container calls -java.security.Policy.getPermissions with a ProtectionDomain -that need not be constructed with principals. The container must call the -implies method on the returned PermissionCollection using the permission -being checked as argument. The checked permission is granted if the -PermissionCollection implies it. Otherwise, the permission is not granted. This -technique is supported but not recommended. - -Prior to using any of the techniques described in this section, the container -must have established a policy context identifier as defined in Section 4.6, -Setting the Policy Context. - - - container - - - 103 - A container must determine if the caller has been granted a permission by -evaluating the permission in the context of an AccessControlContext, -ProtectionDomain, or Subject containing the principals of (only) the caller. If the -caller's identity has been asserted or vouched for by a trusted authority (other than -the caller), the principals of the authority must not be included in the principals of -the caller.A container must use one of the following techniques to determine if a -permission has been granted to the caller. - -The container calls AccessControlContext.checkPermission with -the permission as argument. The call to checkPermission must be made on -an AccessControlContext that contains the principals of the caller. If -checkPermission throws an AccessControlException, the permission is not -granted to the caller. Otherwise the permission is granted. - -The container calls AccessController.checkPermission with the -permission as argument. The AccessControlContext associated with the thread -on which the call to checkPermission is made must contain the principals -of the caller. If checkPermission throws an AccessControlException, the -permission is not granted to the caller. Otherwise the permission is granted. - -The container calls SecurityManager.checkPermission with the -permission as argument. The AccessControlContext associated with the thread -on which the call to checkPermission is made must contain the principals -of the caller. If checkPermission throws an AccessControlException, the -permission is not granted to the caller. Otherwise the permission is granted. - -The container calls Policy.implies with two arguments; the -permission being checked and a ProtectionDomain constructed with the -principals of the caller. The boolean result returned by Policy.implies -indicates whether or not the permission has been granted to the caller. - -The container calls -java.security.Policy.getPermissions with an argument -ProtectionDomain that was constructed with the principals of the caller. The -container must call the implies method on the returned -PermissionCollection using the permission being checked as argument. If the -PermissionCollection implies the permission being tested, the permission has -been granted to the caller. Otherwise it has not. This technique is supported but -not recommended. - - - container - - - 104 - A Policy provider must return that a tested permission has not been granted if it -acquires a non-null policy context identifier by calling getContextID on the -PolicyContext class and the inService method of the -PolicyConfigurationFactory associated with the provider would return -false if called with the policy context identifier. - - - provider - - - 105 - A Policy provider must include the policy statements of the default policy -context in every access determination it performs.A Policy provider that either -does not call PolicyContext.getContexdID, or does so and acquires the identifier -of the default policy context, must use only the policy statements of the default -policy context to perform its access determination. - - - provider - - - 106 - To be compatible with this contract, every JRE of an application server must perform all of the - policy decisions defined by this contract by interacting with the java.security.Policy instance available in the JRE - via the java.security.Policy.getPolicy method. - - - container - - - 107 - Legacy assertion no longer holds - - - container - - - 108 - Once an application server has used either of the system properties defined in -this section to replace a Policy object used by a JRE, the application server must -not use setPolicy to replace the corresponding Policy object of the running JRE -again. - - - container - - - 109 - A Policy provider must use the combined policy statements of the default policy -context (as defined in Section 4.10, Default Policy Context) and of the policy -context identified by calling PolicyContext.getContextID to determine if they -imply the permission being checked. If one or more excluded policy statements -imply the checked permission, the evaluation may terminate and the checked -permission must be determined not to be granted. Otherwise, if one or more -unchecked policy statements imply the checked permission, the checked -permission must be determined to be granted independent of -AccessControlContext. If the status of the checked permission is not resolved by -the excluded and unchecked evaluations, it must be determined if a permission -that implies the checked permission has been granted to the -AccessControlContext being tested for the permission. The checked permission -may only be determined to be granted if a permission that implies the checked -permission has been granted to the AccessControlContext. Otherwise the -permission must be determined not to be granted. - - - provider - - - 110 - The URLPatternSpec syntax is defined as -follows: -URLPatternList ::= URLPattern | URLPatternList colon URLPattern -URLPatternSpec ::= URLPattern | URLPattern colon URLPatternList -name ::= URLPatternSpec -Given this syntax, A reference URLPatternSpec matches an argument -URLPatternSpec if all of the following are true. -- The first URLPattern in the argument URLPatternSpec is matched by the first -URLPattern in the reference URLPatternSpec. --The first URLPattern in the argument URLPatternSpec is NOT matched by -any URLPattern in the URLPatternList of the reference URLPatternSpec. -- If the first URLPattern in the argument URLPatternSpec matches the first -URLPattern in the reference URLPatternSpec, then every URLPattern in the -URLPatternList of the reference URLPatternSpec must be matched by a -URLPattern in the URLPatternList of the argument URLPatternSpec. -The comparisons described above are case sensitive, and all matching is -according to the rules defined in Section 3.1.3.3, Servlet URL-Pattern Matching -Rules. - - - provider - - - 111 - A reference WebResourcePermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebResourcePermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -The comparisons described above are case sensitive. - - - provider - - - 112 - A reference WebRoleRefPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebRoleRefPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The actions (i.e role reference) of the argument permission is equivalent to the -actions (i.e role reference) of the reference permission. -The comparisons described above are case sensitive. - - - provider - - - 113 - A reference WebUserDataPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebUserDataPermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -- The transportType in the actions of the reference permission either corresponds -to the value "NONE", or equals the transportType in the actions of the -argument permission. -The comparisons described above are case sensitive. - - - provider - - - 113 - A reference WebUserDataPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebUserDataPermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, ?Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -- The transportType in the actions of the reference permission either corresponds -to the value "NONE", or equals the transportType in the actions of the -argument permission. -The comparisons described above are case sensitive. - - - provider - - - 114 - A Policy provider must employ the policy decision semantics described in -Section 4.2.1, Servlet Policy Decision Semantics in the Processing of EJB -Policy decisions. - - - provider - - - 115 - A reference EJBMethodPermission implies an argument permission, if all of the -following are true. -- The argument permission is an instanceof EJBMethodPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The methods to which the argument permission applies (as defined in its actions) -must be a subset of the methods to which the reference permission applies -(as defined in its actions). This rule is satisfied if all of the following -conditions are met. -- The method name of the reference permission is null, the empty -string, or equivalent to the method name of the argument -permission. -- The method interface of the reference permission is null, the empty -string, or equivalent to the method interface of the argument -permission. -- The method parameter type list of the reference permission is null, -the empty string, or equivalent to the method parameter type list of -the argument permission. -The comparisons described above are case sensitive. - - - provider - - - 116 - A reference EJBRoleRefPermission implies an argument permission, if all of the -following are true. -- The argument permission is an instanceof EJBRoleRefPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The actions (i.e role reference) of the argument permission is equivalent to the -actions (i.e role reference) of the reference permission. -The comparisons described above are case sensitive. - - - provider - - - 117 - A WebResourcePermission and a WebUserDataPermission must be -instantiated for each url-pattern in the deployment descriptor and the default -pattern, "/", that is not combined by the web-resource-collection elements -of the deployment descriptor with every HTTP method value. The permission -objects must be constructed using the qualified pattern as their name and with -actions defined by the subset of the HTTP methods that do not occur in -combination with the pattern.The resulting permissions must be added to the -unchecked policy statements by calling the addToUncheckedPolicy method -on the PolicyConfiguration object. - - - provider - - - 118 - The WebResourcePermission and WebUserDataPermission objects resulting -from the translation of a Servlet deployment descriptor must be constructed with -name produced by qualifying the URL pattern. The rules for qualifying a URL -pattern are dependent on the rules for determining if one URL pattern matches -another as defined in Section 3.1.3.3, Servlet URL-Pattern Matching Rules, and -are described as follows: - -- If the pattern is a path prefix pattern, it must be qualified by every path-prefix -pattern in the deployment descriptor matched by and different from the pattern -being qualified. The pattern must also be qualified by every exact pattern -appearing in the deployment descriptor that is matched by the pattern being -qualified. - -- If the pattern is an extension pattern, it must be qualified by every path-prefix -pattern appearing in the deployment descriptor and every exact pattern in the -deployment descriptor that is matched by the pattern being qualified. - -- If the pattern is the default pattern, "/", it must be qualified by every other pattern -except the default pattern appearing in the deployment descriptor. - -- If the pattern is an exact pattern, its qualified form must not contain any qualifying -patterns. - -URL patterns are qualified by appending to their String representation, a -colon separated representation of the list of patterns that qualify the pattern. -Duplicates must not be included in the list of qualifying patterns, and any -qualifying pattern matched by another qualifying pattern may be dropped from -the list. -QualifyingPatternList ::= - empty string | colon QualifyingPattern | - QualifyingPatternList colon QualifyingPattern - QualifiedPattern ::= Pattern QualifyingPatternList - -Any pattern, qualified by a pattern that matches it, is overridden and made -irrelevant (in the translation) by the qualifying pattern. Specifically, all extension -patterns and the default pattern are made irrelevant by the presence of the path -prefix pattern "/*" in a deployment descriptor. Patterns qualified by the "/*" -pattern violate the URLPatternSpec constraints of WebResourcePermission and -WebUserDataPermission names and must be rejected by the corresponding -permission constructors. - - - provider - - - 119 - This URL pattern matches another pattern if they are related, by case sensitive -comparison, as follows: -- their pattern values are String equivalent, or -- this pattern is the path-prefix pattern "/*", or -- this pattern is a path-prefix pattern (that is, it starts with "/" and ends with -"/*") and the other pattern starts with the substring of this pattern, minus its -last 2 characters, and the next character of the other pattern, if there is one, is -"/", or -- this pattern is an extension pattern (that is, it starts with "*.") and the other -pattern ends with this pattern, or -- this pattern is the special default pattern, "/", which matches all other patterns. - - - provider - - - 120 - After the PolicyConfiguration objects are linked, the commit method -must be called on all the PolicyConfiguration objects to place them in -service such that their policy statements will be assimilated by the corresponding -Policy providers. - - - provider - - - - 121 - - The following list defines changes to this contract that - apply to containers running without a Java SE SecurityManager. - - 1. The restrictions defined in Section 3.3, Permission to - Configure Policy need not be enforced. Also, the - containers of the application server must not be - denied permission to perform any operation that would - have been permitted in the presence of a SecurityManager. - - 2. Such containers are not required (before dispatching a - call) to associate an AccessControlContext with the call - thread (as otherwise required by Section 4.1.3, - Pre-dispatch Decision and Section 4.3.1, - EJB Pre-dispatch Decision). - - 3. When performing the operations defined in Section 4.7, - Checking AccessControlContext Independent Grants and in - Section 4.8, Checking the Caller for a Permission, - such containers must not employ the - SecurityManager.checkPermission and - AccessControlContext.checkPermission techniques defined - in these sections. - - - container - - - 122 - - This subcontract also applies to the translation of - authorization policy annotations that have an equivalent - representation in Jakarta EE deployment descriptor policy - constructs(i.e security-constraint, method-permission, - security-role-ref, and exclude-list elements) - - - container - - - - 123 - - Independent of this specification, Jakarta EE deployment tools must translate and complete the declarative policy - statements appearing in deployment descriptors into a form suitable for securing applications on the platform. - These deployment tools must combine policy annotations in Java code with policy statements appearing in deployment - descriptors to yield complete representations of authorization policy suitable for securing applications on the platform. - The rules for combining authorization policy annotations with declarative policy statements are described in the - Jakarta Enterprise Beans, Jakarta Servlet, and Jakarta EE platform specifications. Independent of whether annotations - factor in the translation, the resulting policy statements may differ in form from the policy statements appearing - in the deployment descriptors. - - - container - - - 124 - - When an application is composed of multiple web modules, a separate - policy context must be defined per module. This is necessary to ensure - that url-pattern based and servlet name based policy statements - configured for one module do not interfere with those configured - for another. - - - container - - - 125 - - When an application is composed of multiple EJB jars, no two jars - that share at least one ejb-name value in common may share the same - policy context identifiers. - - - container - - - 126 - - Permission Names for Transport and Pre-Dispatch Decisions - The name of the permission checked in a transport or pre-dispatch - decision must be the value that would result from applying the Servlet - welcome file processing rules to the unqualified request URI minus the - context path. - - For the special case where this transformation of the request URI - yields the URLPattern /, the empty string URLPattern, , must be - used as the permission name. The welcome file processing rules are - defined in the Servlet specification. For the special case where the - empty string must be substituted for the / pattern in the permission - evaluation, all target related processing (including servlet mapping, - filter mapping, and form based login processing) must be performed - using the original pattern, /. - - - container - - - 127 - - The EnterpriseBean object must only be returned when this handler - is activated within the scope of a container's processing of a - business method of the EJB Remote, Local, or ServiceEndpoint - interfaces of the EnterpriseBean object. The value null must be - returned if the bean implementation class does not implement the - jakarta.ejb.EnterpriseBean interface. - - - container - - - - - diff --git a/internal/docs/jacc/TCD.txt b/internal/docs/jacc/TCD.txt deleted file mode 100644 index 344f643cdc..0000000000 --- a/internal/docs/jacc/TCD.txt +++ /dev/null @@ -1,84 +0,0 @@ -TCK Coverage Document for Jakarta Authorization -(version 2.0) - - -TCK Components: ---------------- -- User's Guide -- Compatibility Rules -- Configuration Instructions -- Test Suite -- API Tests -- Signature Test -- End-to-End Tests -- Ant Task Tests -- Framework Code -- JavaTest TM Harness - - -Terminology of Metrics ----------------------- -- Assertion: A specific statement of functionality or behavior derived from a specification. - A testable assertion is one that can be validated in an implementation by testing. -- Test: A binary application (or script) comprised of one or more Test Cases. -- Test Case: A single set of test inputs, execution conditions, and expected results - developed to verify an implementation's conformance with a specific assertion. -- Specification Assertion Coverage: Ratio of all assertions tested by at least one test - case to the total number of testable assertions defined by the specification. -- API Coverage: Ratio of methods directly exercised by test cases to the total number - of methods defined by the specification. - - -Coverage --------- -- Total testable assertions derived from Jakarta Authorization Specifications and Javadoc: - 84 (testable) specification assertions - + 62 API assertions - ------------------------------ - 146 testable assertions - - -- Total testable assertions tested - 54 specification assertions tested - + 23 API assertions tested (only include servlet profile not soap) - -------------------------------------- - 77 testable assertions tested - - - - 64% of testable specification assertions tested (54/84) - - 37% of testable API assertions tested (23/62) - - 52% of all (specification and API) assertions tested (77/146) - -- Assertions were identified through the use of CTS Tools and hand markup - (hand markup was required for the Jakarta Authorization specifications) - -- API Signature Coverage: 100% for all defined public and protected members and validated - by the signature test included with the Jakarta Authorization TCK. - -- See the following HTML reports in this bundle for Jakarta Authorization specification and API coverage metrics: - * coverage/jacc/api/summary.html - * coverage/jacc/spec/summary.html - - -Quality Assurance ------------------ -- TCK was run using representative configurations of the Reference Implementation on - the following platforms: - * CentOS Linux 7 / Java SE 8 - * Alpine Linux v3.12 / Java SE 8 -- Code quality was demonstrated through use of code reviews and inspections -- User's Guide was constructed from the standard CTS User's Guide template -- Documentation instructions were verified and tested - - -Justification of Adequacy -------------------------- -The Jakarta Authorization CTS provides a set of tests to ensure all implementations of -the Jakarta Authorizations are compatible. As with all TCKs it is -impossible to provide tests for 100% assertion coverage. Note, while -the CTS may not have tests for all assertions in Jakarta Authorization, all -implementations of Jakarta Authorization must be compatible with the specifications. - -Untested assertions are due to the effects of availability and cost of -test development resources. - diff --git a/internal/docs/jacc/generateAssertionCoverageData b/internal/docs/jacc/generateAssertionCoverageData deleted file mode 100644 index e696d637f5..0000000000 --- a/internal/docs/jacc/generateAssertionCoverageData +++ /dev/null @@ -1,26 +0,0 @@ -#!/bin/sh -# -# Copyright (c) 2018 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 -# - -# Generate Assertion Coverage data -# - -TS_TOOLS_HOME=/home/gsingh/cts-tools -TS_HOME=/home/gsingh/spider-ws - -ant -buildfile $TS_HOME/bin/coverage-build.xml jacc -ant -buildfile $TS_HOME/bin/coverage-build.xml build.page - diff --git a/internal/docs/jacc/generateJavaDocAssertions b/internal/docs/jacc/generateJavaDocAssertions deleted file mode 100644 index 51ed37c7c4..0000000000 --- a/internal/docs/jacc/generateJavaDocAssertions +++ /dev/null @@ -1,36 +0,0 @@ -#!/bin/sh -# -# Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 -# - - -SRC_DIR=/home/rperumal/jacc14/jacc-ri -TOOLS_DIR=/home/rperumal/cts-tools -OUTPUT_DIR=/home/rperumal/CTS14beta/internal/docs/jacc - -mkdir ${OUTPUT_DIR}/temp - -# Generate JACC Javadoc assertions -# -cd ${TOOLS_DIR}/tools/scripts/ -./assert-gen3.sh JACC "JACC 1.0" "Java Authorization Contract for Containers" "1.0" ${SRC_DIR} ${OUTPUT_DIR}/temp jakarta.security.jacc -# Copy generated Javadoc assertions from temp directory to ${OUTPUT_DIR} -# -cp ${OUTPUT_DIR}/temp/assertions.html ${OUTPUT_DIR}/JACCJavadocAssertions.html - -# Remove temporary directory -# -#\rm -rf ${OUTPUT_DIR}/temp - diff --git a/internal/docs/jacc/generateSpecAssertions b/internal/docs/jacc/generateSpecAssertions deleted file mode 100644 index b5d769fdfc..0000000000 --- a/internal/docs/jacc/generateSpecAssertions +++ /dev/null @@ -1,42 +0,0 @@ -#!/bin/sh -# -# Copyright (c) 2018 Oracle and/or its affiliates. All rights reserved. -# -# This program and the accompanying materials are made available under the -# terms of the Eclipse Public License v. 2.0, which is available at -# http://www.eclipse.org/legal/epl-2.0. -# -# This Source Code may also be made available under the following Secondary -# Licenses when the conditions for such availability set forth in the -# Eclipse Public License v. 2.0 are satisfied: GNU General Public License, -# version 2 with the GNU Classpath Exception, which is available at -# https://www.gnu.org/software/classpath/license.html. -# -# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 -# - -# Generate Specification Assertions -# - -DOCS_DIR=/home/gsingh/spider-ws/internal/docs/jacc -TOOLS_DIR=/home/gsingh/cts-tools - -# sort the assertions -# -#cd ${TOOLS_DIR}/tools/scripts -#./sort-spec-assertions ${DOCS_DIR}/JACCSpecAssertions.xml ${DOCS_DIR}/JACCSpecAssertions-sorted.xml - -# Number the assertions -# -#cd ${TOOLS_DIR}/tools/number-assert -#ant -Dinput_file=${DOCS_DIR}/JACCSpecAssertions-sorted.xml -Doutput_file=${DOCS_DIR}/JACCSpecAssertions-numbered.xml -Dreplace_tag=_NUMBER_ -Dinc_num=1 -Dstart_num=1 run - -# Generate html output -# -cd ${TOOLS_DIR}/tools/xsl-transformer/scripts -./run ${DOCS_DIR}/JACCSpecAssertions.xml ${DOCS_DIR}/jaccRegrouping.xsl ${DOCS_DIR}/JACCSpecAssertions.html - -# Remove temporary files -# -#\rm -rf ${DOCS_DIR}/JACCSpecAssertions-numbered.xml ${DOCS_DIR}/JACCSpecAssertions-sorted.xml - diff --git a/internal/docs/jacc/jaccRegrouping.xsl b/internal/docs/jacc/jaccRegrouping.xsl deleted file mode 100644 index fb0da424f8..0000000000 --- a/internal/docs/jacc/jaccRegrouping.xsl +++ /dev/null @@ -1,373 +0,0 @@ - - - - - - - - - - - - Specification Assertion Detail - - -
    - - - -
    - -
    -

    - -
    - - -
    - Specification Assertion Detail -

    -
    - - -
    - - - - - - #:SPEC: - :SPEC: - -
    -
    -
    -
    - - - - assertions - - - - - - - - - - - - - -
    - ID - - Chapter - - Section - - Description - - Required - - Dependency - - Implementation Specific - - Defined by - - Status - - Testable -
    -
    -
    - - - - - - :SPEC: - - - :SPEC: - - - - - - - - - - - - - -
    -
    - -
    -
    - - - - - - - - - - - -
    -
    - -
    -
    - - - - - - - - - - - -
    -
    - -
    -
    - - - - - - - - - - - -
    -
    - -
    -
    - - - - - - - - - - - - - -
    -
    - -
    -
    - - - - - - - - - - - -
    -
    - -
    -
    - - - - - - - - - - - -
    -
    - -
    -
    - - - - - - - - - - - -
    -
    - -
    -
    - - - - - - - - - - - -
    -
    - -
    -
    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - Totals - - Total - - Active - - Deprecated - - Removed -
    - - # of Assertions - - - - - - - - - - - - - - - - - -
    - - # of Required Assertions - - - - - - - - - - - - - - - - - -
    - - # of Optional Assertions - - - - - - - - - - - - - - - - - -
    -
    -
    -
    diff --git a/internal/docs/jacc/jacc_0.3/JACCSpecAssertions_0.3.html b/internal/docs/jacc/jacc_0.3/JACCSpecAssertions_0.3.html deleted file mode 100644 index b213d9e5ae..0000000000 --- a/internal/docs/jacc/jacc_0.3/JACCSpecAssertions_0.3.html +++ /dev/null @@ -1,998 +0,0 @@ - - - - - -Specification Assertion Detail - - -
    -
    -

    Java Authorization Service Provider Contract for Containers.
    1 - 0.3
    - Specification Assertion Detail -

    -
    - - - - - - - - - - - -
    TotalsTotalActiveDeprecatedRemoved
    - # of Assertions - 777700
    - # of Required Assertions - 727200
    - # of Optional Assertions - 5500
    -
    container assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:111.4J2EE 1.4 platforms must implement the contract defined by this JSR.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:211.4Support for the contract by J2EE 1.3 platforms is optional. (OPTIONAL)false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:411.4Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1011.4To allow for the differentiation of sessions of the same subject, - every Servlet container must include a session identifier as a - principal within the subject corresponding to the access control - context. The session identifier need not be related to any specific - Servlet representation of session.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1111.4To support this contract in a Servlet (2.3) environment, a - container or its deploy tools must create policy statements as - necessary to support Servlet's default role-ref semantic.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1322.4For a container to avail itself of the authorization functionality - defined in this contract, it must be provided with implementations - of the Permission classes in the jakarta.security.jacc package. - These classes are: - EJBMethodPermission - EJBRoleRefPermission - WebResourcePermission - WebRoleRefPermission - WebUserDataPermissiontrue -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1522.4If the container is running a Java 1.3 security environment, then it - must be provided with the implementation of a class the extends the - abstract class - javax.security.auth.Policy. If the container is running a Java 1.4 - security environment, then it must also be provided with the - implementation of a class that extends the abstract class, - java.security.Policy.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1822.5For each VM of the application server, if the system property - jacc.auth.policy.provider is defined, the application server must - construct an instance of the class identified by the system - property, confirm that the resulting object is an instance of - javax.security.auth.Policy, and set, using - javax.security.auth.Policy.setPolicy(), the resulting - object as the corresponding Policy object used by the VM. - - If the system property jacc.policy.provider is defined, an - application server running a 1.4 VM must use an analogous method to - construct an instance of the class identified by the system - property, confirm that the resulting object is an instance of - java.security.Policy, and set, using - java.security.Policy.setPolicy(), the resulting object as the - corresponding Policy object used by the VM.true -
    -
    truetechnologyactivefalse
    JACC:SPEC:1922.5Once an application server has used either of the jacc policy system - properites to replace a Policy object used by a VM, the application - server must not use setPolicy() to replace the corresponding Policy - object of the running VM again.true -
    -
    truetechnologyactivefalse
    JACC:SPEC:2633.1.1.1A servlet container is responsible for mapping the target name or - address information of an HTTP request to the appropriate hostname.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4533.1.7Once the translation is complete, a call must be made to - Policy.refresh() on the Policy object used by each of the containers - to which the application or module is being deployed. The calls to - Policy.refresh() must occur before the containers will accept - requests for the deployed resources, but may be deffered until after - principal-to-role mapping.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:4633.1.7The policy context identifiers corresponding to the deployed - application or module must be recorded in the application server so - that they can be used to create permissions for use in the Policy - Decision Subcontract, and such that the deployer may subsequently - remove or modify the corresponding policy configuration as a result - of the undeployment or redeployment of the application. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:4833.1.8To ensure that there is not a period during undeployment when the - removal of policy statements on application components renders what - were protected components unprotected, the application server must - stop accepting requests for the application's components before the - policy statements are deleted. - - After the policy statements are removed a call shall be made to - Policy.refresh() on the Policy object used by each of the containers - from which at least one module of the application was undeployed.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:4933.1.9Containers are not required to deploy to an existing policy - configuration. Containers that chose to provide this functionality - must satisfy the following requirements. - - An application or module shall be associated with an existing set - of linked policy configurations by using the policy context - identifiers of the PolicyConfiguration objects of the existing - policy configuration in the permissions used in the Policy Decision - Subcontract.false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5033.1.10Containers are not required to implement redeployment functionality. - Containers that chose to provide this functionality must satisfy the - following requirements. - - To ensure redeployment does not create a situation where the removal - of policy statements on application components renders what were - protected components unprotected, the application server must stop - accepting requests for the application's components before - redeployment begins. - false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5544.1A container must rely on the java.security.Policy and or - javax.security.auth.Policy objects of the VM (available via - java.security.Policy.getPolicy(), and - jakarta.security.auth.getPolicy() respectively) for all of the policy - decisions defined by this contract.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5644.1If a container employs a custom SecurityManager, the necessary - reliance on the Policy objects of the VM may be accomplished by - ensuring that the custom SecurityManager relies on the Policy object - of the VM for all of its policy decisions defined by this contract.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5744.1Servlet containers shall enforce the authorization policies - established for web resources as a result of the deployment of - application modules containing web resources.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5844.1.1The Servlet container shall construct (or reuse) a - WebUserDataPermission object identifying the target resource in the - authorization policy context and with action composed from the HTTP - method of the request and transport guarantees corresponding to the - properties of the connection on which the request arrived.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5944.1.1The Servlet container shall use one of the methods described in - Section 4.5, - Determining if a Permission is Excluded to determine if access to - the resource under the transport guarantee encapsulated in the - WebUserDataPermission has been excluded. - - If access to the resource has been excluded the request shall be - redirected as defined by the Servlet Specification. If access to the - resource has not been excluded, the request shall be subjected to a - pre-dispatch decision.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6044.1.2The Servlet container shall construct (or reuse) a - WebResourcePermission object corresponding to the target resource in - the authorization policy context and with action composed from the - HTTP method of the request. The Servlet container shall use one of - the methods described in Section 4.6, - Checking if a Caller has been Granted a Permission" to determine if - the WebResourcePermission has been granted to the caller. If a - security exception is thrown in the permission determination, it - shall be caught, and the result of the determination shall be that - the permission is not granted to the caller. The Servlet container - shall only dispatch the request to the web resource, if the - WebResourcePermission is determined to be granted to the caller. - Otherwise the request shall be rejected with the appropriate HTTP - error message.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6144.1.2Prior to dispatching a call to a web resource, the container shall - associate an AccessControlContext containing the principals of the - authorized caller with the call thread.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:6744.3EJB containers shall enforce the authorization policies established - for EJB resources as a result of the deployment of application - modules containing EJB resources. true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6844.3.1The EJB container shall construct (or reuse) a EJBMethodPermission - with name constructed from the authorization policy context - identifier corresponding to the deployed instance of the module - containing the target resource and the ejb-name of the target - resource. The actions used in the permission construction shall - completely specify the method of the EJB by identifing the method - interface, method name, and method signature as defined for a - methodSpec in the documentation of the EJBMethodPermission class.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:7044.3.1The EJB container shall use one of the methods described in - Section 4.6, - Checking if a Caller has been Granted a Permission to determine - if the EJBMethodPermission has been granted to the caller. If a - security exception is thrown in the permission determination, it - shall be caught, and the result of the determination shall be that - the permission is not granted to the caller. The EJB container shall - only dispatch the request to the EJB resource, if the - EJBMethodPermission is determined to be granted to the caller. - Otherwise the request shall be rejected with the appropriate RMI - security exception, as defined by the EJB specification.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7144.3.1 Prior to dispatching a call to an EJB, the container shall - associate an AccessControlContext containing the principals of the - authorized caller with the call threadtrue -
    -
    falsetechnologyactivefalse
    JACC:SPEC:7544.5The policy statements corresponding to WebUserDataPermission objects - are represented as excluded policy statements. The techniques that - shall be used to determine if a WebUserDataPermission is excluded - are described below - - a)The container shall call AccessControlContext.checkPermission with - the WebUserDataPermission as argument. The call to checkPermission - may be made on any AccessControlContext. If checkPermission throws - an access exception, the WebUserDataPermission is excluded. - Otherwise the permission is not excluded. - - b)The container shall call SecurityManager.checkPermission with the - WebUserDataPermission as argument. If checkPermission throws an - access exception, the WebUserDataPermission is excluded. Otherwise - the permission is not excluded. - - A container that relies on a javax.security.auth.Policy provider may - also use the following technique to determine if - WebUserDataPermission is excluded. - - a)The container shall call - javax.security.auth.Policy.getPermissions() to determine - the collection of permissions granted independent of Subject. - To do this, the Subject in the call to getPermissions may be null. - If getPermission returns an empty PermissionCollection, or if the - returned PermissionCollection does not imply the - WebUserDataPermission being tested, then the permission is excluded. - - A container that relies on a J2SE 1.4 java.security.Policy provider - may also use the following techniques to determine if a - WebUserDataPermission is excluded. - - The container shall call Policy.implies with two arguments; the - WebUserDataPermission, and an argument ProtectionDomain that was - constructed without static permissions and that need not be - constructed with principals. The boolean result returned by - policy.implies shall indicate whether or not the permission is - excluded.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:7644.6A container shall determine if a caller has been granted a - permission by evaluating the permission in an AccessControlContext - or ProtectionDomain containing the principals of the Subject - correponding to the caller. - - Independent of whether a container employs a - javax.security.auth.Policy or a J2SE 1.4 java.security.Policy - provider for its authorization decisions it may use one of the - following techniques to determine if a permission has been granted - to the caller. - - a)The container shall call AccessControlContext.checkPermission with - the permission as argument. The call to checkPermission must be made - on an AccessControlContext containing the principals of the Subject - corresponding to the caller. If checkPermission throws an access - exception, the permission is not granted to the caller. Otherwise - the permission is granted. - - b)The container shall call SecurityManager.checkPermission with the - permission as argument and using the principals of the - AccessControlContext associated with the thread on which the call - to checkPermission is performed. If checkPermission throws an - access exception, the permission is not granted to the caller. - Otherwise the permission is granted. - - A container that relies on a javax.security.auth.Policy provider may - also use the following technique to determine if a permission has - been granted to the caller. - - a)The container shall call - javax.security.auth.Policy.getPermissions() with the - Subject corresponding to the caller. The returned - PermissionCollection will contain the collection of permissions - granted to the caller. The container shall call the implies method - on the returned PermissionCollection using the permission being - checked as argument. If the PermissionCollection implies the - permission being tested, the permission has been granted to the - caller. Otherwise it has not. - - A container that relies on a J2SE 1.4 java.secuirty.Policy provider - may also use the following techniques to determine if a permission - has been granted to a caller. - - a)The container shall call - javax.security.Policy.getPermissions() with an argument - ProtectionDomain that was constructed with the principals obtained - from the Subject corresponding to the caller. The container shall - call the implies method on the returned PermissionCollection using - the permission being checked as argument. If the - PermissionCollection implies the permission being tested, the - permission has been granted to the caller. Otherwise it has not. - - b)The container shall call Policy.implies with two arguments; the - permission being checked, and a ProtectionDomain constructed with - the principals obtained from the Subject corresponding to the - caller. The boolean result returned by policy.implies shall indicate - whether or not the permission has been granted to the caller. - Otherwise it has not.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:7744.7To be compatible with this contract, a J2EE 1.3 container must - perform all of its policy decisions as defined by this contract by - interacting with a concrete implementation of the - javax.security.auth.Policy abstract class. - - A J2EE 1.4 container must perform all of its policy decisions as - defined by this contract by interacting with concrete - implementations of either or both of the java.security.Policy and - javax.security.auth.Policy abstract classes.true -
    -
    falsetechnologyactivetrue
    provider assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:311.4Each Policy provider which satisfies this contract must perform or - delegate to another provider all the permission evaluations - requested of it in the VM;true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:511.4Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:611.4Each provider must satisfy all of the authorization requirements of - the EJB and Servlet specifications corresponding to the target - platform.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:711.4A permission corresponding to a resource must identify the context - of the resource's use such that different policy can be applied to - a resource used in different contexts (that is, applications or - instances of an application).true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:811.4In the case of Servlet resources, the provider must be able to - associate a distinct policy context with each context root - (including context roots created to support virtual hosting) - hosted by the server.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:911.4In protecting Servlet resources, a provider must select the - constraints that apply to a resource by implementing a best - match semantic, where the applicable constraints are selected by - applying the Servlet matching rules.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1222.3A provider must include an implementation of a utility class, - jakarta.security.jacc.PolicyConfigurationFactory, for container - deploy tools to use to create and locate instances of a class - within the provider that implements the PolicyConfiguration - interface.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1622.4In each of these cases, the Permission implementation classes made - available to the container must be compatible with the Policy - implementation class, and the Policy implementation classes must be - compatible with the class that implements - the PolicyConfiguration interface.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1722.4The Policy objects whose methods are invoked by the container must - assume responsibility for answering all Policy questions, which may - be accomplished by delegating non jakarta.security.jacc policy - decisions to some other Policy object. true -
    -
    truetechnologyactivefalse
    JACC:SPEC:2333.1The resulting policy statements may differ in form from the policy - statements appearing in the deployment descriptors. The policy - translation defined by this subcontract is described assuming that - the policy statement form used by a platform is identical to that - used to express policy in the deployment descriptors. - - Where this is not the case, the output of the translation must be - equivalent to the translation that would occur if policy was - completely specified in the deployment descriptors and the - translation had proceeded directly from the deployment descriptors - to the J2SE policy forms defined by this subcontract.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:2433.1.1It must be possible to define separate authorization policy contexts - corresponding to each deployed instance of a J2EE module.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2533.1.1This specification requires that the names of checked permissions - be sufficient to identify (that is, carry the identifier of) the - authorization policy context in which the evaluation is to be - performed. - - This specification also requires that all permission objects in - the policy statements of a policy context include the identifier of - the policy context in their name.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2733.1.1.2In the J2EE security model, principal-to-role mappings have - application scope, that is, the same principal-to-role mappings - must apply in the access decisions applied at all of the modules - (that may represent separate policy contexts) that comprise an - application. - - Same application policy contexts shall be associated by calling the - PolicyConfiguration.link() method. This method shall create a - transitive and symetric relationship within the provider and - between this PolicyConfiguration and the argument - PolicyConfiguration, such that they and all PolicyConfigurations - otherwise linked to either of them shall share the same - principal-to-role mappings. - - The semantics of the association shall preserve the invariant that - at most one principal-to-role mapping shall apply to any - PolicyConfiguration.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2833.1.2A reference to a PolicyConfiguration object shall be obtained by - calling the getPolicyConfiguration method on the - PolicyConfigurationFactory class.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2933.1.2The policy context identifier used in the call to - getPolicyConfiguration, shall be the string composed from the - hostname corresponding to the target container, and the - context path corresponding to the application as described in - Servlet Policy Context Identifiers on page 14.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3033.1.2For each auth-constraint element appearing in the deployment - descriptor, a WebResourcePermission shall be instantiated for each - element in the cross-product of url-pattern (in the associated web- - resource-collection)and role-name appearing in the constraint. - - If the reserved role-name, * occurs as a role-name in the - constraint, the cross product shall be computed using all the roles - defined in the web application. true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:3133.1.2The policy context identifier used in the call to getPolicyContext - shall be combined with the url-pattern from the web-resource- - collection to define the name used in the construction of the - WebResourcePermission objects.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:3233.1.2The HTTP methods from the auth-constraint shall be used to define - the actions used in the permission construction.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3333.1.2The WebResourcePermission instantiated for each security role to - which access to a url-pattern is to be granted, shall be added to - the corresponding role by calling the addToRole method on the - PolicyConfiguration object. - - If no role name appears in an auth-constraint, a - WebResourcePermission object shall be instantiated for each url- - pattern in the auth-constraint and added to the excluded policy - statements by calling addToExcludedPolicy on the corresponding - PolicyConfiguration object. - - For each url-pattern of each userdata-constraint appearing in the - deployment descriptor, a WebUserDataPermission shall be - instantiated. - - The name used in the construction of the permission shall be - obtained according to the fashion described for - WebResourcePermission objects. - - The actions used in the construction of a WebuserDataPermission - is obtained by combining the HTTP methods associated with the - userdata-constraint, and then appending to it a representation of - the unacceptable transport guarantees. - - (The mapping of deployment descriptor transport-guarantee to - unacceptable transport guarantee is defined in Table 3-1 on page - 16.) - - In there are no other transport guarantees in the constraint, then - the url-patterns and methods identified in the constraint are - unconstrained (that is, there are no unacceptable transport - guarantees) and the value "UNCONSTRAINED" shall be appended to the - actions used in the construction.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3433.1.3For each security-role-ref appearing in the deployment descriptor a - corresponding WebRoleRefPermission shall be created. The name used - in the construction of each WebRoleRefPermission shall be composed - of the policy context identifier (used in the call to - getPolicyConfiguration and shared with the - trranslation of security-constraint elements of the same deployment - descriptor)followed by the servlet-name in whose context the - security-role-reference is defined. The actions used to construct - the permission shall be the value of the role-name (that is the - reference), appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3633.1.4A reference to a PolicyConfiguration object shall be obtained by - calling the getPolicyConfiguration method on the - PolicyConfigurationFactory class. The policy context identifier used - in the call to getPolicyConfiguration shall be a string selected by - the container to identify the deployment of the EJB jar in the - context of an application. true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3733.1.4An EJBMethodPermission object shall be created for each method- - permission element appearing in the deployment descriptor. The name - of each EJBMethodPermission shall be obtained by combining the - policy context identifier used in the call to getPolicyConfiguration - with the ejb-name as defined in the method element of the method- - permission element. - - The actions used in the permission construction shall be obtained by - translating the contents of the method element into a method - specification according to the methSpec syntax defined in the - documentation of the EJBMethodPermission class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3933.1.5An EJBMethodPermission object shall be created for each method - element occuring in the exclude-list element of the deployment - descriptor. The name and actions of each EJBMethodPermission shall - be obtained as described for non-excluded EJBMethodPermission - objects. The policy context identifier embedded in the names and the - target PolicyConfiguration object shall be that of the - PolicyConfiguration object used in the translation of the non- - excluded method-permission elements of the module. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4133.1.6For each security-role-ref appearing in the deployment descriptor a - corresponding EJBRoleRefPermission shall be created. - - The policy context identifier embedded in the names and the target - PolicyConfiguration object shall be that of the PolicyConfiguration - object used in the translation of the method-permission elements of - the module. The actions used to construct the permission shall be - the value of the role-name (that is the reference), appearing in the - security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4433.1.7When a module is deployed, it shall be linked to the - PolicyConfiguration object of any other module with which it must - share the same principal-to-role mapping. - - When an application is deployed, the PolicyConfiguration objects - corresponding to all the modules of the application must be linked. - PolicyConfigurations are linked by calling the linkConfiguration - method of the PolicyConfiguration interface.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5233.2In addition to providing a PolicyConfiguration interface for - integration with the application server's deploy tools, the provider - must also include a management interface for policy administrators - to use to grant the collections of permissions that comprise roles, - to principals.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5333.2The provider must ensure that all of the permissions added to a role - in a policy configuration context are granted to any principal - mapped to the role by the policy administrator. The provider must - ensure that the same principal-to-role mappings are applied to all - linked policy configuration contexts.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5433.2The provider must ensure that excluded policy statements take - precedence over overlapping unchecked policy statements, and that - both excluded and unchecked policy statements take precedence over - overlapping role based policy statements.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6244.1.3When a call is made from a web resource to isUserInRole(String - roleName) the implementation of this method shall construct (or - reuse) a WebRoleRefPermission object identifying the component - context of the embedded privilege evaluation (that is, the web - resource and role reference) in the corresponding authorization - policy context. The implementation of the isUserInRole method shall - then use one of the methods described in Section 4.6, - Checking if a Caller has been Granted a Permission to determine - if the WebRoleRefPermission has been granted to the caller. If a - security exception is thrown in the permission determination, it - shall be caught, and the result of the determination shall be that - the permission is not granted to the caller. If it is determined - that the WebRoleRefPermission has been granted to the caller, - isUserInRole shall return true. Otherwise the return value shall be - false.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6344.2.1Constraints shall be matched (using the servlet matching rules) on - url-pattern first. - - All constraints (in the policy configuration identified in the name - of the checked permission) with the best (according to the servlet - matching rules) matching url-pattern (to the url-pattern in the name - of the checked permission), shall be tested to see if any of them - constrain an action of the checked permission. - - If none do, the request shall be permitted. If one or more constrain - an action of the checked permission, the set of actions in the - checked permission shall be reduced to the set that are constrained, - and then Policy shall be evaluated to determine if one or more - permissions which "satisfy" the url-pattern of the constraining - permissions, and which when taken together confer all of the actions - determined to be constrained have been granted to the invocation - context.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6444.2.1The url-pattern in the name of a satisfying granted permission must - be a better than or equal match (according to the servlet matching - rules) to the url-pattern of the best matching constraints, and its - url-pattern must also match the url-pattern in the name of the - checked permission. A granted permission whose url-pattern is equal - to the url-pattern in the names of the best matching constraints is - one example of a satisfying granted permission.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6544.2.1The best matching user-data-constraint shall be determined - independent of the best-matching auth-constraint.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6644.2.2URL pattern matching shall be be guided by pattern type such that exact patterns -(those not ending with * or /, or beginning with *.) shall match better than -path prefix patterns (those ending with /*) and such that path prefix patterns -shall match better than extension patterns (those beginning with *.), and such -that extension patterns shall match better than the universal pattern /. Within -each pattern type, longer string length patterns shall match better than shorter -patterns.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6944.3.1EJBMethodPermission may optionally include copies of the arguments - of the proposed invocation, and in the case of an Entity Bean it may - also optionally include a reference to the target EntityBean.false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7244.3.2When an EJB makes a call to isCallerInRole(String roleName) the - implementation of this method shall construct (or reuse) an - EJBRoleRefPermission identifying the component context of the - embedded privilege evaluation (that is, the EJB and role reference) - in the corresponding authorization policy context. The - implementation of the isCallerInRole method shall then use one of - the methods described in Section 4.6, - Checking if a Caller has been Granted a Permission, to determine - if the EJBRoleRefPermission has been granted to the caller. If a - security exception is thrown in the permission determination, it - shall be caught, and the result of the determination shall be that - the permission is not granted to the caller. If it is determined - that the EJBRoleRefPermission has been granted to the caller, then - isCallerInRole shall return true. Otherwise the return value shall - be false.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7344.4.1The policy statements of the policy configuration identified in the - name of the checked permission shall be tested to determine if they - match the permission being evaluated. If one or more excluded policy - statements match the checked permission, the evaluation may - terminate and, independent of subject, the checked permission shall - be determined not to be accorded. Otherwise, if one or more - unchecked policy statements match the checked permission, the - checked permission shall be determined to be accorded independent of - subject. If neither of the excluded or unchecked comparisons yield a - match, then the subject shall only be determined to have been - accorded the checked permission if a permission corresponding to a - matching role-based policy statement is determined to have been - granted to the subject.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7444.4.2A granted EJBMethodPermission matches a checked EJBMethodPermission - if their names are equivalent, and if the method specification in - the actions of the granted permission matches the method - specification in the actions of the checked permission (as described - in the definition of the EJBMethodPermission class). - - One or more granted EJBRoleRefPermission objects match a checked - EJBRoleRefPermission if their names are equivalent to the name of - the checked permission and if the actions of the granted permissions - together contain all of the role references in the actions of the - checked permission.true -
    -
    falsetechnologyactivetrue
    tools assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:1422.4The container deploy tools must also be provided with an - implementation ofthe jakarta.security.jacc.PolicyConfigurationFactory - class along with a matched implementation of a class that - implements the jakarta.security.jacc.PolicyConfiguration interface.true -
    -
    truetechnologyactivefalse
    JACC:SPEC:2033.1The deploy tools must translate the declarative authorization policy - statements derived from application or module deployment - descriptor(s) into instances of the corrresponding - jakarta.security.jacc Permission classes.true -
    -
    truetechnologyactivefalse
    JACC:SPEC:2133.1The deploy tools must use the methods of the PolicyConfiguration - interface to cause authorization policy contexts containing policy - statements corresponding to the permissions resulting from the - translation to be created within the Policy objects used by the - containers to which the components of the application or - module are deployed.true -
    -
    truetechnologyactivefalse
    JACC:SPEC:2233.1Independent of this specification, J2EE deploy tools must translate - and complete the declarative policy statements appearing in - deployment descriptors into a form suitable for securing - applications on the platform. true -
    -
    truetechnologyactivefalse
    JACC:SPEC:3533.1.3 The deploy tools shall call the addToRole method on the - PolicyConfiguration object to add the WebRoleRefPermission object - resulting from the translation to the roleName identified in the - role-link appearing in the security-role-ref. - - For each servlet element in the deployment descriptor a - WebRoleRefPermission shall be created for each security-role whose - name does not appear as the role-name in a security-role-ref within - the servlet element. Each such WebRoleRefPermission - shall be created with action (that is, reference) corresponding to - the role-name and added to the role with the same name (as the - reference) by calling the addToRole method on the - PolicyConfiguration object.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3833.1.4If the method-permission element contains the unchecked element, - then the deploy tools shall create an unchecked policy statement - corresponding to the derived EJBMethodPermission by calling the - addToUncheckedPolicy method on the PolicyConfiguration object. - - Alternatively, if the method-permission element contains 1 or more - role-name elements, then the deploy tools shall create policy - statements associating the derived EJBMethodPermission with each of - the role-names contained in the method-permission element. Deploy - tools shall call the addToRole method to create these policy - statements.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4033.1.5 The deploy tools shall call the addToExcludedPolicy method on the - PolicyConfiguration object to create excluded policy statements in - the provider corresponding to the permissons derived from the - exclude-list.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4233.1.6The deploy tools shall call the addToRole method on the - PolicyConfiguration object to add a policy statement corresponding - to the EJBRoleRefPermission to the role identified in the role-link - appearing in the security-role-ref.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4333.1.7The server's deploy tools must translate the declarative - authorization policy appearing in the application or module - deployment descriptor(s) into policy statements within the Policy - objects used by the containers to which the components of the] - application or module are being deployed.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:4733.1.8When undeploying an application or module, the deploy tools shall - call the delete method on the PolicyConfiguration objects associated - with the modules of the application and associated with the provider - of each container to which one or more modules of the application - have been deployed.true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5133.1.10 To redeploy a module, the deploy tools shall call the delete method - on the module's PolicyConfiguration object in the provider - associated with each of the containers to which the module has been - deployed. - - The deploy tools shall translate the declarative authorization - policy appearing in the module's deployment descriptor into a - PolicyConfiguration object (that may or may not have the same policy - context identifier as the deleted objects). The translation shall - include linking the new PolicyConfiguration module to any other - modules with which the module must share its principal-to-role - mappings. - - After the translation and reconfiguration of policy is complete a - call must be made to Policy.refresh() on the Policy object used by - each of the containers to which the module has been redeployed.false -
    -
    falsetechnologyactivefalse
    - - diff --git a/internal/docs/jacc/jacc_0.3/JACCSpecAssertions_0.3.xml b/internal/docs/jacc/jacc_0.3/JACCSpecAssertions_0.3.xml deleted file mode 100644 index a668b072a8..0000000000 --- a/internal/docs/jacc/jacc_0.3/JACCSpecAssertions_0.3.xml +++ /dev/null @@ -1,1230 +0,0 @@ - - - - - - - 1 - 0 - JACC - 1 - Java Authorization Service Provider Contract for Containers. - 0.3 - - - - -
    -
    -
    -
    -
    -
    - - - - -
    -
    -
    -
    -
    - - - - -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    - - - - -
    -
    -
    -
    -
    - -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    - - - - - - - 1 - J2EE 1.4 platforms must implement the contract defined by this JSR. - - container - - - 2 - Support for the contract by J2EE 1.3 platforms is optional. (OPTIONAL) - - container - - - 3 - Each Policy provider which satisfies this contract must perform or - delegate to another provider all the permission evaluations - requested of it in the VM; - - provider - - - - Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - - container - - - 4 - Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - - provider - - - 5 - Each provider must satisfy all of the authorization requirements of - the EJB and Servlet specifications corresponding to the target - platform. - - provider - - - 6 - A permission corresponding to a resource must identify the context - of the resource's use such that different policy can be applied to - a resource used in different contexts (that is, applications or - instances of an application). - - provider - - - 7 - In the case of Servlet resources, the provider must be able to - associate a distinct policy context with each context root - (including context roots created to support virtual hosting) - hosted by the server. - - provider - - - 8 - In protecting Servlet resources, a provider must select the - constraints that apply to a resource by implementing a best - match semantic, where the applicable constraints are selected by - applying the Servlet matching rules. - - provider - - - 9 - To allow for the differentiation of sessions of the same subject, - every Servlet container must include a session identifier as a - principal within the subject corresponding to the access control - context. The session identifier need not be related to any specific - Servlet representation of session. - - container - - - 10 - To support this contract in a Servlet (2.3) environment, a - container or its deploy tools must create policy statements as - necessary to support Servlet's default role-ref semantic. - - container - - - 11 - A provider must include an implementation of a utility class, - jakarta.security.jacc.PolicyConfigurationFactory, for container - deploy tools to use to create and locate instances of a class - within the provider that implements the PolicyConfiguration - interface. - - provider - - - 12 - For a container to avail itself of the authorization functionality - defined in this contract, it must be provided with implementations - of the Permission classes in the jakarta.security.jacc package. - These classes are: - EJBMethodPermission - EJBRoleRefPermission - WebResourcePermission - WebRoleRefPermission - WebUserDataPermission - - container - - - 13 - The container deploy tools must also be provided with an - implementation ofthe jakarta.security.jacc.PolicyConfigurationFactory - class along with a matched implementation of a class that - implements the jakarta.security.jacc.PolicyConfiguration interface. - - tools - - - 14 - If the container is running a Java 1.3 security environment, then it - must be provided with the implementation of a class the extends the - abstract class - javax.security.auth.Policy. If the container is running a Java 1.4 - security environment, then it must also be provided with the - implementation of a class that extends the abstract class, - java.security.Policy. - - container - - - 15 - In each of these cases, the Permission implementation classes made - available to the container must be compatible with the Policy - implementation class, and the Policy implementation classes must be - compatible with the class that implements - the PolicyConfiguration interface. - - provider - - - 16 - The Policy objects whose methods are invoked by the container must - assume responsibility for answering all Policy questions, which may - be accomplished by delegating non jakarta.security.jacc policy - decisions to some other Policy object. - - provider - - - 17 - For each VM of the application server, if the system property - jacc.auth.policy.provider is defined, the application server must - construct an instance of the class identified by the system - property, confirm that the resulting object is an instance of - javax.security.auth.Policy, and set, using - javax.security.auth.Policy.setPolicy(), the resulting - object as the corresponding Policy object used by the VM. - - If the system property jacc.policy.provider is defined, an - application server running a 1.4 VM must use an analogous method to - construct an instance of the class identified by the system - property, confirm that the resulting object is an instance of - java.security.Policy, and set, using - java.security.Policy.setPolicy(), the resulting object as the - corresponding Policy object used by the VM. - - container - - - 18 - Once an application server has used either of the jacc policy system - properites to replace a Policy object used by a VM, the application - server must not use setPolicy() to replace the corresponding Policy - object of the running VM again. - - container - - - 19 - The deploy tools must translate the declarative authorization policy - statements derived from application or module deployment - descriptor(s) into instances of the corrresponding - jakarta.security.jacc Permission classes. - - tools - - - 20 - The deploy tools must use the methods of the PolicyConfiguration - interface to cause authorization policy contexts containing policy - statements corresponding to the permissions resulting from the - translation to be created within the Policy objects used by the - containers to which the components of the application or - module are deployed. - - tools - - - 21 - Independent of this specification, J2EE deploy tools must translate - and complete the declarative policy statements appearing in - deployment descriptors into a form suitable for securing - applications on the platform. - - tools - - - 22 - The resulting policy statements may differ in form from the policy - statements appearing in the deployment descriptors. The policy - translation defined by this subcontract is described assuming that - the policy statement form used by a platform is identical to that - used to express policy in the deployment descriptors. - - Where this is not the case, the output of the translation must be - equivalent to the translation that would occur if policy was - completely specified in the deployment descriptors and the - translation had proceeded directly from the deployment descriptors - to the J2SE policy forms defined by this subcontract. - - provider - - - 23 - It must be possible to define separate authorization policy contexts - corresponding to each deployed instance of a J2EE module. - - provider - - - 24 - This specification requires that the names of checked permissions - be sufficient to identify (that is, carry the identifier of) the - authorization policy context in which the evaluation is to be - performed. - - This specification also requires that all permission objects in - the policy statements of a policy context include the identifier of - the policy context in their name. - - provider - - - 25 - A servlet container is responsible for mapping the target name or - address information of an HTTP request to the appropriate hostname. - - container - - - 26 - In the J2EE security model, principal-to-role mappings have - application scope, that is, the same principal-to-role mappings - must apply in the access decisions applied at all of the modules - (that may represent separate policy contexts) that comprise an - application. - - Same application policy contexts shall be associated by calling the - PolicyConfiguration.link() method. This method shall create a - transitive and symetric relationship within the provider and - between this PolicyConfiguration and the argument - PolicyConfiguration, such that they and all PolicyConfigurations - otherwise linked to either of them shall share the same - principal-to-role mappings. - - The semantics of the association shall preserve the invariant that - at most one principal-to-role mapping shall apply to any - PolicyConfiguration. - - provider - - - 27 - A reference to a PolicyConfiguration object shall be obtained by - calling the getPolicyConfiguration method on the - PolicyConfigurationFactory class. - - provider - - - 28 - The policy context identifier used in the call to - getPolicyConfiguration, shall be the string composed from the - hostname corresponding to the target container, and the - context path corresponding to the application as described in - Servlet Policy Context Identifiers on page 14. - - provider - - - 29 - For each auth-constraint element appearing in the deployment - descriptor, a WebResourcePermission shall be instantiated for each - element in the cross-product of url-pattern (in the associated web- - resource-collection)and role-name appearing in the constraint. - - If the reserved role-name, * occurs as a role-name in the - constraint, the cross product shall be computed using all the roles - defined in the web application. - - provider - - - 30 - The policy context identifier used in the call to getPolicyContext - shall be combined with the url-pattern from the web-resource- - collection to define the name used in the construction of the - WebResourcePermission objects. - - provider - - - 31 - The HTTP methods from the auth-constraint shall be used to define - the actions used in the permission construction. - - provider - - - 32 - The WebResourcePermission instantiated for each security role to - which access to a url-pattern is to be granted, shall be added to - the corresponding role by calling the addToRole method on the - PolicyConfiguration object. - - If no role name appears in an auth-constraint, a - WebResourcePermission object shall be instantiated for each url- - pattern in the auth-constraint and added to the excluded policy - statements by calling addToExcludedPolicy on the corresponding - PolicyConfiguration object. - - For each url-pattern of each userdata-constraint appearing in the - deployment descriptor, a WebUserDataPermission shall be - instantiated. - - The name used in the construction of the permission shall be - obtained according to the fashion described for - WebResourcePermission objects. - - The actions used in the construction of a WebuserDataPermission - is obtained by combining the HTTP methods associated with the - userdata-constraint, and then appending to it a representation of - the unacceptable transport guarantees. - - (The mapping of deployment descriptor transport-guarantee to - unacceptable transport guarantee is defined in Table 3-1 on page - 16.) - - In there are no other transport guarantees in the constraint, then - the url-patterns and methods identified in the constraint are - unconstrained (that is, there are no unacceptable transport - guarantees) and the value "UNCONSTRAINED" shall be appended to the - actions used in the construction. - - provider - - - 33 - For each security-role-ref appearing in the deployment descriptor a - corresponding WebRoleRefPermission shall be created. The name used - in the construction of each WebRoleRefPermission shall be composed - of the policy context identifier (used in the call to - getPolicyConfiguration and shared with the - trranslation of security-constraint elements of the same deployment - descriptor)followed by the servlet-name in whose context the - security-role-reference is defined. The actions used to construct - the permission shall be the value of the role-name (that is the - reference), appearing in the security-role-ref. - - - provider - - - - The deploy tools shall call the addToRole method on the - PolicyConfiguration object to add the WebRoleRefPermission object - resulting from the translation to the roleName identified in the - role-link appearing in the security-role-ref. - - For each servlet element in the deployment descriptor a - WebRoleRefPermission shall be created for each security-role whose - name does not appear as the role-name in a security-role-ref within - the servlet element. Each such WebRoleRefPermission - shall be created with action (that is, reference) corresponding to - the role-name and added to the role with the same name (as the - reference) by calling the addToRole method on the - PolicyConfiguration object. - - tools - - - 34 - A reference to a PolicyConfiguration object shall be obtained by - calling the getPolicyConfiguration method on the - PolicyConfigurationFactory class. The policy context identifier used - in the call to getPolicyConfiguration shall be a string selected by - the container to identify the deployment of the EJB jar in the - context of an application. - - provider - - - 35 - An EJBMethodPermission object shall be created for each method- - permission element appearing in the deployment descriptor. The name - of each EJBMethodPermission shall be obtained by combining the - policy context identifier used in the call to getPolicyConfiguration - with the ejb-name as defined in the method element of the method- - permission element. - - The actions used in the permission construction shall be obtained by - translating the contents of the method element into a method - specification according to the methSpec syntax defined in the - documentation of the EJBMethodPermission class. - - - provider - - - 36 - If the method-permission element contains the unchecked element, - then the deploy tools shall create an unchecked policy statement - corresponding to the derived EJBMethodPermission by calling the - addToUncheckedPolicy method on the PolicyConfiguration object. - - Alternatively, if the method-permission element contains 1 or more - role-name elements, then the deploy tools shall create policy - statements associating the derived EJBMethodPermission with each of - the role-names contained in the method-permission element. Deploy - tools shall call the addToRole method to create these policy - statements. - - tools - - - 37 - An EJBMethodPermission object shall be created for each method - element occuring in the exclude-list element of the deployment - descriptor. The name and actions of each EJBMethodPermission shall - be obtained as described for non-excluded EJBMethodPermission - objects. The policy context identifier embedded in the names and the - target PolicyConfiguration object shall be that of the - PolicyConfiguration object used in the translation of the non- - excluded method-permission elements of the module. - - - provider - - - - The deploy tools shall call the addToExcludedPolicy method on the - PolicyConfiguration object to create excluded policy statements in - the provider corresponding to the permissons derived from the - exclude-list. - - tools - - - 38 - For each security-role-ref appearing in the deployment descriptor a - corresponding EJBRoleRefPermission shall be created. - - The policy context identifier embedded in the names and the target - PolicyConfiguration object shall be that of the PolicyConfiguration - object used in the translation of the method-permission elements of - the module. The actions used to construct the permission shall be - the value of the role-name (that is the reference), appearing in the - security-role-ref. - - - provider - - - - The deploy tools shall call the addToRole method on the - PolicyConfiguration object to add a policy statement corresponding - to the EJBRoleRefPermission to the role identified in the role-link - appearing in the security-role-ref. - - tools - - - 39 - The server's deploy tools must translate the declarative - authorization policy appearing in the application or module - deployment descriptor(s) into policy statements within the Policy - objects used by the containers to which the components of the] - application or module are being deployed. - - tools - - - 40 - When a module is deployed, it shall be linked to the - PolicyConfiguration object of any other module with which it must - share the same principal-to-role mapping. - - When an application is deployed, the PolicyConfiguration objects - corresponding to all the modules of the application must be linked. - PolicyConfigurations are linked by calling the linkConfiguration - method of the PolicyConfiguration interface. - - provider - - - 41 - Once the translation is complete, a call must be made to - Policy.refresh() on the Policy object used by each of the containers - to which the application or module is being deployed. The calls to - Policy.refresh() must occur before the containers will accept - requests for the deployed resources, but may be deffered until after - principal-to-role mapping. - - container - - - 42 - The policy context identifiers corresponding to the deployed - application or module must be recorded in the application server so - that they can be used to create permissions for use in the Policy - Decision Subcontract, and such that the deployer may subsequently - remove or modify the corresponding policy configuration as a result - of the undeployment or redeployment of the application. - - - container - - - 43 - When undeploying an application or module, the deploy tools shall - call the delete method on the PolicyConfiguration objects associated - with the modules of the application and associated with the provider - of each container to which one or more modules of the application - have been deployed. - - tools - - - 44 - To ensure that there is not a period during undeployment when the - removal of policy statements on application components renders what - were protected components unprotected, the application server must - stop accepting requests for the application's components before the - policy statements are deleted. - - After the policy statements are removed a call shall be made to - Policy.refresh() on the Policy object used by each of the containers - from which at least one module of the application was undeployed. - - container - - - 45 - Containers are not required to deploy to an existing policy - configuration. Containers that chose to provide this functionality - must satisfy the following requirements. - - An application or module shall be associated with an existing set - of linked policy configurations by using the policy context - identifiers of the PolicyConfiguration objects of the existing - policy configuration in the permissions used in the Policy Decision - Subcontract. - - container - - - 46 - Containers are not required to implement redeployment functionality. - Containers that chose to provide this functionality must satisfy the - following requirements. - - To ensure redeployment does not create a situation where the removal - of policy statements on application components renders what were - protected components unprotected, the application server must stop - accepting requests for the application's components before - redeployment begins. - - - container - - - - To redeploy a module, the deploy tools shall call the delete method - on the module's PolicyConfiguration object in the provider - associated with each of the containers to which the module has been - deployed. - - The deploy tools shall translate the declarative authorization - policy appearing in the module's deployment descriptor into a - PolicyConfiguration object (that may or may not have the same policy - context identifier as the deleted objects). The translation shall - include linking the new PolicyConfiguration module to any other - modules with which the module must share its principal-to-role - mappings. - - After the translation and reconfiguration of policy is complete a - call must be made to Policy.refresh() on the Policy object used by - each of the containers to which the module has been redeployed. - - tools - - - 47 - In addition to providing a PolicyConfiguration interface for - integration with the application server's deploy tools, the provider - must also include a management interface for policy administrators - to use to grant the collections of permissions that comprise roles, - to principals. - - provider - - - 48 - The provider must ensure that all of the permissions added to a role - in a policy configuration context are granted to any principal - mapped to the role by the policy administrator. The provider must - ensure that the same principal-to-role mappings are applied to all - linked policy configuration contexts. - - provider - - - 49 - The provider must ensure that excluded policy statements take - precedence over overlapping unchecked policy statements, and that - both excluded and unchecked policy statements take precedence over - overlapping role based policy statements. - - provider - - - 50 - A container must rely on the java.security.Policy and or - javax.security.auth.Policy objects of the VM (available via - java.security.Policy.getPolicy(), and - jakarta.security.auth.getPolicy() respectively) for all of the policy - decisions defined by this contract. - - container - - - 51 - If a container employs a custom SecurityManager, the necessary - reliance on the Policy objects of the VM may be accomplished by - ensuring that the custom SecurityManager relies on the Policy object - of the VM for all of its policy decisions defined by this contract. - - container - - - 52 - Servlet containers shall enforce the authorization policies - established for web resources as a result of the deployment of - application modules containing web resources. - - container - - - 53 - The Servlet container shall construct (or reuse) a - WebUserDataPermission object identifying the target resource in the - authorization policy context and with action composed from the HTTP - method of the request and transport guarantees corresponding to the - properties of the connection on which the request arrived. - - container - - - 54 - The Servlet container shall use one of the methods described in - Section 4.5, - Determining if a Permission is Excluded to determine if access to - the resource under the transport guarantee encapsulated in the - WebUserDataPermission has been excluded. - - If access to the resource has been excluded the request shall be - redirected as defined by the Servlet Specification. If access to the - resource has not been excluded, the request shall be subjected to a - pre-dispatch decision. - - container - - - 55 - The Servlet container shall construct (or reuse) a - WebResourcePermission object corresponding to the target resource in - the authorization policy context and with action composed from the - HTTP method of the request. The Servlet container shall use one of - the methods described in Section 4.6, - Checking if a Caller has been Granted a Permission" to determine if - the WebResourcePermission has been granted to the caller. If a - security exception is thrown in the permission determination, it - shall be caught, and the result of the determination shall be that - the permission is not granted to the caller. The Servlet container - shall only dispatch the request to the web resource, if the - WebResourcePermission is determined to be granted to the caller. - Otherwise the request shall be rejected with the appropriate HTTP - error message. - - container - - - 56 - Prior to dispatching a call to a web resource, the container shall - associate an AccessControlContext containing the principals of the - authorized caller with the call thread. - - container - - - 57 - When a call is made from a web resource to isUserInRole(String - roleName) the implementation of this method shall construct (or - reuse) a WebRoleRefPermission object identifying the component - context of the embedded privilege evaluation (that is, the web - resource and role reference) in the corresponding authorization - policy context. The implementation of the isUserInRole method shall - then use one of the methods described in Section 4.6, - Checking if a Caller has been Granted a Permission to determine - if the WebRoleRefPermission has been granted to the caller. If a - security exception is thrown in the permission determination, it - shall be caught, and the result of the determination shall be that - the permission is not granted to the caller. If it is determined - that the WebRoleRefPermission has been granted to the caller, - isUserInRole shall return true. Otherwise the return value shall be - false. - - provider - - - 58 - Constraints shall be matched (using the servlet matching rules) on - url-pattern first. - - All constraints (in the policy configuration identified in the name - of the checked permission) with the best (according to the servlet - matching rules) matching url-pattern (to the url-pattern in the name - of the checked permission), shall be tested to see if any of them - constrain an action of the checked permission. - - If none do, the request shall be permitted. If one or more constrain - an action of the checked permission, the set of actions in the - checked permission shall be reduced to the set that are constrained, - and then Policy shall be evaluated to determine if one or more - permissions which "satisfy" the url-pattern of the constraining - permissions, and which when taken together confer all of the actions - determined to be constrained have been granted to the invocation - context. - - provider - - - 59 - The url-pattern in the name of a satisfying granted permission must - be a better than or equal match (according to the servlet matching - rules) to the url-pattern of the best matching constraints, and its - url-pattern must also match the url-pattern in the name of the - checked permission. A granted permission whose url-pattern is equal - to the url-pattern in the names of the best matching constraints is - one example of a satisfying granted permission. - - provider - - - 60 - The best matching user-data-constraint shall be determined - independent of the best-matching auth-constraint. - - provider - - - 61 - URL pattern matching shall be be guided by pattern type such that exact patterns -(those not ending with * or /, or beginning with *.) shall match better than -path prefix patterns (those ending with /*) and such that path prefix patterns -shall match better than extension patterns (those beginning with *.), and such -that extension patterns shall match better than the universal pattern /. Within -each pattern type, longer string length patterns shall match better than shorter -patterns. - - provider - - - 62 - EJB containers shall enforce the authorization policies established - for EJB resources as a result of the deployment of application - modules containing EJB resources. - - container - - - 63 - The EJB container shall construct (or reuse) a EJBMethodPermission - with name constructed from the authorization policy context - identifier corresponding to the deployed instance of the module - containing the target resource and the ejb-name of the target - resource. The actions used in the permission construction shall - completely specify the method of the EJB by identifing the method - interface, method name, and method signature as defined for a - methodSpec in the documentation of the EJBMethodPermission class. - - container - - - 64 - EJBMethodPermission may optionally include copies of the arguments - of the proposed invocation, and in the case of an Entity Bean it may - also optionally include a reference to the target EntityBean. - - provider - - - 65 - The EJB container shall use one of the methods described in - Section 4.6, - Checking if a Caller has been Granted a Permission to determine - if the EJBMethodPermission has been granted to the caller. If a - security exception is thrown in the permission determination, it - shall be caught, and the result of the determination shall be that - the permission is not granted to the caller. The EJB container shall - only dispatch the request to the EJB resource, if the - EJBMethodPermission is determined to be granted to the caller. - Otherwise the request shall be rejected with the appropriate RMI - security exception, as defined by the EJB specification. - - container - - - 66 - Prior to dispatching a call to an EJB, the container shall - associate an AccessControlContext containing the principals of the - authorized caller with the call thread - - container - - - 67 - When an EJB makes a call to isCallerInRole(String roleName) the - implementation of this method shall construct (or reuse) an - EJBRoleRefPermission identifying the component context of the - embedded privilege evaluation (that is, the EJB and role reference) - in the corresponding authorization policy context. The - implementation of the isCallerInRole method shall then use one of - the methods described in Section 4.6, - Checking if a Caller has been Granted a Permission, to determine - if the EJBRoleRefPermission has been granted to the caller. If a - security exception is thrown in the permission determination, it - shall be caught, and the result of the determination shall be that - the permission is not granted to the caller. If it is determined - that the EJBRoleRefPermission has been granted to the caller, then - isCallerInRole shall return true. Otherwise the return value shall - be false. - - provider - - - 68 - The policy statements of the policy configuration identified in the - name of the checked permission shall be tested to determine if they - match the permission being evaluated. If one or more excluded policy - statements match the checked permission, the evaluation may - terminate and, independent of subject, the checked permission shall - be determined not to be accorded. Otherwise, if one or more - unchecked policy statements match the checked permission, the - checked permission shall be determined to be accorded independent of - subject. If neither of the excluded or unchecked comparisons yield a - match, then the subject shall only be determined to have been - accorded the checked permission if a permission corresponding to a - matching role-based policy statement is determined to have been - granted to the subject. - - provider - - - 69 - A granted EJBMethodPermission matches a checked EJBMethodPermission - if their names are equivalent, and if the method specification in - the actions of the granted permission matches the method - specification in the actions of the checked permission (as described - in the definition of the EJBMethodPermission class). - - One or more granted EJBRoleRefPermission objects match a checked - EJBRoleRefPermission if their names are equivalent to the name of - the checked permission and if the actions of the granted permissions - together contain all of the role references in the actions of the - checked permission. - - provider - - - 70 - The policy statements corresponding to WebUserDataPermission objects - are represented as excluded policy statements. The techniques that - shall be used to determine if a WebUserDataPermission is excluded - are described below - - a)The container shall call AccessControlContext.checkPermission with - the WebUserDataPermission as argument. The call to checkPermission - may be made on any AccessControlContext. If checkPermission throws - an access exception, the WebUserDataPermission is excluded. - Otherwise the permission is not excluded. - - b)The container shall call SecurityManager.checkPermission with the - WebUserDataPermission as argument. If checkPermission throws an - access exception, the WebUserDataPermission is excluded. Otherwise - the permission is not excluded. - - A container that relies on a javax.security.auth.Policy provider may - also use the following technique to determine if - WebUserDataPermission is excluded. - - a)The container shall call - javax.security.auth.Policy.getPermissions() to determine - the collection of permissions granted independent of Subject. - To do this, the Subject in the call to getPermissions may be null. - If getPermission returns an empty PermissionCollection, or if the - returned PermissionCollection does not imply the - WebUserDataPermission being tested, then the permission is excluded. - - A container that relies on a J2SE 1.4 java.security.Policy provider - may also use the following techniques to determine if a - WebUserDataPermission is excluded. - - The container shall call Policy.implies with two arguments; the - WebUserDataPermission, and an argument ProtectionDomain that was - constructed without static permissions and that need not be - constructed with principals. The boolean result returned by - policy.implies shall indicate whether or not the permission is - excluded. - - container - - - 71 - A container shall determine if a caller has been granted a - permission by evaluating the permission in an AccessControlContext - or ProtectionDomain containing the principals of the Subject - correponding to the caller. - - Independent of whether a container employs a - javax.security.auth.Policy or a J2SE 1.4 java.security.Policy - provider for its authorization decisions it may use one of the - following techniques to determine if a permission has been granted - to the caller. - - a)The container shall call AccessControlContext.checkPermission with - the permission as argument. The call to checkPermission must be made - on an AccessControlContext containing the principals of the Subject - corresponding to the caller. If checkPermission throws an access - exception, the permission is not granted to the caller. Otherwise - the permission is granted. - - b)The container shall call SecurityManager.checkPermission with the - permission as argument and using the principals of the - AccessControlContext associated with the thread on which the call - to checkPermission is performed. If checkPermission throws an - access exception, the permission is not granted to the caller. - Otherwise the permission is granted. - - A container that relies on a javax.security.auth.Policy provider may - also use the following technique to determine if a permission has - been granted to the caller. - - a)The container shall call - javax.security.auth.Policy.getPermissions() with the - Subject corresponding to the caller. The returned - PermissionCollection will contain the collection of permissions - granted to the caller. The container shall call the implies method - on the returned PermissionCollection using the permission being - checked as argument. If the PermissionCollection implies the - permission being tested, the permission has been granted to the - caller. Otherwise it has not. - - A container that relies on a J2SE 1.4 java.secuirty.Policy provider - may also use the following techniques to determine if a permission - has been granted to a caller. - - a)The container shall call - javax.security.Policy.getPermissions() with an argument - ProtectionDomain that was constructed with the principals obtained - from the Subject corresponding to the caller. The container shall - call the implies method on the returned PermissionCollection using - the permission being checked as argument. If the - PermissionCollection implies the permission being tested, the - permission has been granted to the caller. Otherwise it has not. - - b)The container shall call Policy.implies with two arguments; the - permission being checked, and a ProtectionDomain constructed with - the principals obtained from the Subject corresponding to the - caller. The boolean result returned by policy.implies shall indicate - whether or not the permission has been granted to the caller. - Otherwise it has not. - - container - - - 72 - To be compatible with this contract, a J2EE 1.3 container must - perform all of its policy decisions as defined by this contract by - interacting with a concrete implementation of the - javax.security.auth.Policy abstract class. - - A J2EE 1.4 container must perform all of its policy decisions as - defined by this contract by interacting with concrete - implementations of either or both of the java.security.Policy and - javax.security.auth.Policy abstract classes. - - container - - - 73 - - The following list defines changes to this contract that - apply to containers running without a Java SE SecurityManager. - - 1. The restrictions defined in Section 3.3, Permission to - Configure Policy" need not be enforced. Also, the - containers of the application server must not be - denied permission to perform any operation that would - have been permitted in the presence of a SecurityManager. - - 2. Such containers are not required (before dispatching a - call) to associate an AccessControlContext with the call - thread (as otherwise required by Section 4.1.3, - Pre-dispatch Decision" and Section 4.3.1, - EJB Pre-dispatch Decision"). - - 3. When performing the operations defined in Section 4.7, - Checking AccessControlContext Independent Grants" and in - Section 4.8, Checking the Caller for a Permission", - such containers must not employ the - SecurityManager.checkPermission and - AccessControlContext.checkPermission techniques defined - in these sections. - - - container - - - 74 - - This subcontract also applies to the translation of - authorization policy annotations that have an equivalent - representation in Java EE deployment descriptor policy - constructs(i.e security-constraint, method-permission, - security-role-ref, and exclude-list elements) - - - container - - - - 75 - - Independent of this specification, J2EE deployment tools must - translate and complete the declarative policy statements appearing - in deployment descriptors into a form suitable for securing - applications on the platform. On versions of the Java EE platform - that require support for authorization policy annotations, the - deployment tools must combine policy annotations in Java code with - policy statements appearing in deployment descriptors to yield - complete representations of authorization policy suitable for - securing applications on the platform. The rules for combining - authorization policy annotations with declarative policy statements - are described in the versions of the EJB, Servlet, and Java EE - platform specifications that require support for the annotations. - Independent of whether annotations factor in the translation, - the resulting policy statements may differ in form from the policy - statements appearing in the deployment descriptors. - - - container - - - 76 - - When an application is composed of multiple web modules, a separate - policy context must be defined per module. This is necessary to ensure - that url-pattern based and servlet name based policy statements - configured for one module do not interfere with those configured - for another. - - - container - - - 77 - - When an application is composed of multiple EJB jars, no two jars - that share at least one ejb-name value in common may share the same - policy context identifiers. - - - container - - - 78 - - Permission Names for Transport and Pre-Dispatch Decisions - The name of the permission checked in a transport or pre-dispatch - decision must be the value that would result from applying the Servlet - welcome file processing rules to the unqualified request URI minus the - context path. - - For the special case where this transformation of the request URI - yields the URLPattern "/", the empty string URLPattern, "", must be - used as the permission name. The welcome file processing rules are - defined in the Servlet specification. For the special case where the - empty string must be substituted for the "/" pattern in the permission - evaluation, all target related processing (including servlet mapping, - filter mapping, and form based login processing) must be performed - using the original pattern, "/". - - - container - - - 79 - - The EnterpriseBean object must only be returned when this handler - is activated within the scope of a container's processing of a - business method of the EJB Remote, Local, or ServiceEndpoint - interfaces of the EnterpriseBean object. The value null must be - returned if the bean implementation class does not implement the - jakarta.ejb.EnterpriseBean interface. - - - container - - - diff --git a/internal/docs/jacc/jacc_1.2/JACCJavaDocAssertions.html b/internal/docs/jacc/jacc_1.2/JACCJavaDocAssertions.html deleted file mode 100644 index 59d445819d..0000000000 --- a/internal/docs/jacc/jacc_1.2/JACCJavaDocAssertions.html +++ /dev/null @@ -1,759 +0,0 @@ - - - - - -JavaDoc Assertion Detail - - -
    -
    -

    Java Authorization Contract for Containers
    JACC 1.0 - 1.0
    - JavaDoc Assertion Detail -

    -
    - - - - - - - - - - - -
    TotalsTotalActiveDeprecatedRemoved
    - # of Assertions - 595900
    - # of Required Assertions - 595900
    - # of Optional Assertions - 0000
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDReturnMethod/FieldDescriptionRequiredDeprecatedTestable
    JACC:JAVADOC:1EJBMethodPermissionjakarta.security.jacc.EJBMethodPermission.EJBMethodPermission
    - - ( - String - ,
    String - ) -
    - Creates a new EJBMethodPermission with the specified name and actions. - The name contains the value of the ejb-name element corresponding to an EJB in the application's deployment descriptor. The actions contains a methodSpec. The syntax of the actions parameter is defined as follows: methodNameSpec ::= methodName | emptyString methodInterface ::= Home | LocalHome | Remote | Local | ServiceEndpoint methodInterfaceSpec ::= methodInterface | emptyString methodParams ::= typeName | methodParams comma typeName methodParamsSpec ::= emptyString | methodParams methodSpec ::= null | methodNameSpec | methodNameSpec comma methodInterface | methodNameSpec comma methodInterfaceSpec comma methodParamsSpec A null or empty string methodSpec indicates that the permission applies to all methods of the EJB. A methodSpec with a methodNameSpec of the empty string matches all methods of the EJB that match the methodInterface and methodParams elements of the methodSpec. A methodSpec with a methodInterfaceSpec of the empty string matches all methods of the EJB that match the methodNameSpec and methodParams elements of the methodSpec. A methodSpec without a methodParamsSpec matches all methods of the EJB that match the methodNameSpec and methodInterface elements of the methodSpec. Each typeName appearing in methodParams must be the fully-qualified Java type name of a parameter of the target method. The order of the typeNames in methodParams must match the order of occurence of the corresponding parameters in the method signature of the target method(s). A methodSpec with an empty methodParamsSpec matches all 0 argument methods of the EJB that match the methodNameSpec and methodInterfaceSpec elements of the methodSpec. - true -
    -
    true
    JACC:JAVADOC:2EJBMethodPermissionjakarta.security.jacc.EJBMethodPermission.EJBMethodPermission
    - - ( - String - ,
    String - ,
    String - ,
    String[] - ) -
    - Creates a new EJBMethodPermission with name corresponding to the EJBName and actions composed from methodName, methodInterface, and methodParams. - - true -
    -
    true
    JACC:JAVADOC:3EJBMethodPermissionjakarta.security.jacc.EJBMethodPermission.EJBMethodPermission
    - - ( - String - ,
    String - ,
    Method - ) -
    - Creates a new EJBMethodPermission with name corresponding to the EJBName and actions composed from methodInterface, and the Method object. - A container uses this constructor prior to checking if a caller has permission to call the method of an EJB. - true -
    -
    true
    JACC:JAVADOC:4booleanjakarta.security.jacc.EJBMethodPermission.equals
    - - ( - Object - ) -
    - Checks two EJBMethodPermission objects for equality. - EJBMethodPermission objects are equivalent if they have case sensitive equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - true -
    -
    true
    JACC:JAVADOC:5Stringjakarta.security.jacc.EJBMethodPermission.getActions
    -
    - Returns a String containing a canonical representation of the actions of this EJBMethodPermission. - The Canonical form of an EJBMethodPermission is described by the following syntax description. methodNameSpec ::= methodName | emptyString methodInterface ::= Home | LocalHome | Remote | Local | ServiceEndpoint methodInterfaceSpec ::= methodInterface | emptyString methodParams ::= typeName | methodParams comma typeName methodParamsSpec ::= emptyString | methodParams methodSpec ::= null | methodNameSpec | methodNameSpec comma methodInterface | methodNameSpec comma methodInterfaceSpec comma methodParamsSpec - true -
    -
    true
    JACC:JAVADOC:6intjakarta.security.jacc.EJBMethodPermission.hashCode
    -
    - Returns the hash code value for this EJBMethodPermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value every time it is called on a EJBMethodPermission object. The value returned by hashCode for a particular EJBMethodPermission need not remain consistent from one execution of an application to another. If two EJBMethodPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:7booleanjakarta.security.jacc.EJBMethodPermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this EJBMethodPermission. - For this to be the case, The argument must be an instanceof EJBMethodPermission with name equivalent to that of this EJBMethodPermission, and the methods to which the argument permission applies (as defined in its actions) must be a subset of the methods to which this EJBMethodPermission applies (as defined in its actions) The name and actions comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:8EJBRoleRefPermissionjakarta.security.jacc.EJBRoleRefPermission.EJBRoleRefPermission
    - - ( - String - ,
    String - ) -
    - Creates a new EJBRoleRefPermission with the specified name and actions. - true -
    -
    true
    JACC:JAVADOC:9booleanjakarta.security.jacc.EJBRoleRefPermission.equals
    - - ( - Object - ) -
    - Checks two EJBRoleRefPermission objects for equality. - EJBRoleRefPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - true -
    -
    true
    JACC:JAVADOC:10Stringjakarta.security.jacc.EJBRoleRefPermission.getActions
    -
    - Returns a canonical String representation of the actions of this EJBRoleRefPermission. - - true -
    -
    true
    JACC:JAVADOC:11intjakarta.security.jacc.EJBRoleRefPermission.hashCode
    -
    - Returns the hash code value for this EJBRoleRefPermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value, every time it is called on a EJBRoleRefPermission object. The value returned by hashCode for a particular EJBRoleRefPermission need not remain consistent from one execution of an application to another. If two EJBRoleRefPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:12booleanjakarta.security.jacc.EJBRoleRefPermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this EJBRoleRefPermission. - For this to be the case, The argument must be an instanceof EJBRoleRefPermission with name equivalent to that of this EJBRoleRefPermission, and with the role reference equivalent to that of this EJBRoleRefPermission applies. The name and actions comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:13voidjakarta.security.jacc.PolicyConfiguration.addToExcludedPolicy
    - - ( - PermissionCollection - ) -
    - Used to add excluded policy statements to this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:14voidjakarta.security.jacc.PolicyConfiguration.addToExcludedPolicy
    - - ( - Permission - ) -
    - Used to add a single excluded policy statement to this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:15voidjakarta.security.jacc.PolicyConfiguration.addToRole
    - - ( - String - ,
    PermissionCollection - ) -
    - Used to add permissions to a named role in this PolicyConfiguration. - If the named Role does not exist in the PolicyConfiguration, it is created as a result of the call to this function. It is the job of the Policy provider to ensure that all the permissions added to a role are granted to principals mapped to the role. - true -
    -
    true
    JACC:JAVADOC:16voidjakarta.security.jacc.PolicyConfiguration.addToRole
    - - ( - String - ,
    Permission - ) -
    - Used to add a single permission to a named role in this PolicyConfiguration. - If the named Role does not exist in the PolicyConfiguration, it is created as a result of the call to this function. It is the job of the Policy provider to ensure that all the permissions added to a role are granted to principals mapped to the role. - true -
    -
    true
    JACC:JAVADOC:17voidjakarta.security.jacc.PolicyConfiguration.addToUncheckedPolicy
    - - ( - PermissionCollection - ) -
    - Used to add unchecked policy statements to this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:18voidjakarta.security.jacc.PolicyConfiguration.addToUncheckedPolicy
    - - ( - Permission - ) -
    - Used to add a single unchecked policy statement to this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:19voidjakarta.security.jacc.PolicyConfiguration.delete
    -
    - Causes all policy statements to be deleted from this PolicyConfiguration and sets its internal state such that any additional operations attempted on the PolicyConfiguration will be rejected and cause an UnsupportedOperationException to be thrown. - This operation has no affect on any linked PolicyConfigurations other than removing any links involving the deleted PolicyConfiguration. - true -
    -
    true
    JACC:JAVADOC:20Stringjakarta.security.jacc.PolicyConfiguration.getContextID
    -
    - This method returns this object's policy context identifier. - true -
    -
    true
    JACC:JAVADOC:21voidjakarta.security.jacc.PolicyConfiguration.linkConfiguration
    - - ( - PolicyConfiguration - ) -
    - Creates a relationship between this configuration and another such that they share the same principal-to-role mappings. - PolicyConfigurations are linked to apply a common principal-to-role mapping to multiple seperately manageable PolicyConfigurations, as is required when an application is composed of multiple modules. Note that the policy statements which comprise a role, or comprise the excluded or unchecked policy collections in a PolicyConfiguration are unaffected by the configuration being linked to another. - true -
    -
    true
    JACC:JAVADOC:22voidjakarta.security.jacc.PolicyConfiguration.removeExcludedPolicy
    -
    - Used to remove any excluded policy statements from this PolicyConfiguration. - true -
    -
    true
    JACC:JAVADOC:23voidjakarta.security.jacc.PolicyConfiguration.removeRole
    - - ( - String - ) -
    - Used to remove a role and all its permissions from this PolicyConfiguration. - - true -
    -
    true
    JACC:JAVADOC:24voidjakarta.security.jacc.PolicyConfiguration.removeUncheckedPolicy
    -
    - Used to remove any unchecked policy statements from this PolicyConfiguration. - true -
    -
    true
    JACC:JAVADOC:25booleanjakarta.security.jacc.PolicyConfigurationFactory.contains
    - - ( - String - ) -
    - This method determines if a PolicyConfiguration with policy context identifier equivalent to the argument contextID, already exists in the Policy provider associated with the factory. - - true -
    -
    true
    JACC:JAVADOC:26PolicyConfigurationjakarta.security.jacc.PolicyConfigurationFactory.getPolicyConfiguration
    - - ( - String - ) -
    - This method is used to obtain an instance of the provider specific class that implements the PolicyConfiguration interface and that corresponds to one policy configuration within a provider. - The methods of the PolicyConfiguration interface are used to define the policy statements of the associated policy configuration. For a given value of policy context identifier, this method must always return the same instance of PolicyConfiguration and there must be at most one actual instance of a PolicyConfiguration with a given policy context identifier (during a process context). - true -
    -
    true
    JACC:JAVADOC:27PolicyConfigurationFactoryjakarta.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationFactory
    -
    - This static method uses a system property to find and instantiate (via a public constructor) a provider specific factory implementation class. - The name of the provider specific factory implementation class is obtained from the value of the system property, jakarta.security.jacc.PolicyConfigurationFactory.provider - true -
    -
    true
    JACC:JAVADOC:28PolicyConfigurationFactoryjakarta.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationFactory
    -
    throws - ClassNotFoundException
    -
    when the class named by the system property could not be found including because the value of the system property has not been set.true -
    -
    true
    JACC:JAVADOC:29PolicyConfigurationFactoryjakarta.security.jacc.PolicyConfigurationFactory.PolicyConfigurationFactory
    -
    -
    -
    true -
    -
    true
    JACC:JAVADOC:30Objectjakarta.security.jacc.PolicyContext.getContext
    - - ( - String - ) -
    - Authorization protected method that may be used by a Policy provider to activate the PolicyContextHandler registered to the context object key and cause it to return the corresponding policy context object from the container. - When a handler is activated by this method, it passes to the handler the context object key and the handler data associated with the calling thread. - true -
    -
    true
    JACC:JAVADOC:31Stringjakarta.security.jacc.PolicyContext.getContextID
    -
    - This static method returns the value of the policy context identifier associated with the thread on which the accessor is called. - - true -
    -
    true
    JACC:JAVADOC:32Setjakarta.security.jacc.PolicyContext.getHandlerKeys
    -
    - This method may be used to obtain the keys that identify the container specific context handlers registered by the container. - true -
    -
    true
    JACC:JAVADOC:33voidjakarta.security.jacc.PolicyContext.registerHandler
    - - ( - String - ,
    PolicyContextHandler - ,
    boolean - ) -
    - Authorization protected method used to register a container specific PolicyContext handler. - A handler may be registered to handle multiple keys, but at any time, at most one handler may be registered for a key. - true -
    -
    true
    JACC:JAVADOC:34voidjakarta.security.jacc.PolicyContext.setContextID
    - - ( - String - ) -
    - Authorization protected method used to modify the value of the policy context identifier associated with the thread on which this method is called. - - true -
    -
    true
    JACC:JAVADOC:35voidjakarta.security.jacc.PolicyContext.setHandlerData
    - - ( - Object - ) -
    - Authorization protected method that may be used to associate a thread-scoped handler data object with the PolicyContext. - The handler data object will be made available to handlers, where it can serve to supply or bind the handler to invocation scoped state within the container. - true -
    -
    true
    JACC:JAVADOC:36Objectjakarta.security.jacc.PolicyContextHandler.getContext
    - - ( - String - ,
    Object - ) -
    - This public method is used by the PolicyContext class to activate the handler and obtain from it the the context object identified by the (case-sensitive) key. - In addition to the key, the handler will be activated with the handler data value associated within the PolicyContext class with the thread on which the call to this method is made. Note that the policy context identifier associated with a thread is available to the handler by calling PolicyContext.getContextID(). - true -
    -
    true
    JACC:JAVADOC:37String[]jakarta.security.jacc.PolicyContextHandler.getKeys
    -
    - This public method returns the keys identifying the context objects supported by the handler. - The value of each key supported by a handler must be a non-null String value. - true -
    -
    true
    JACC:JAVADOC:38booleanjakarta.security.jacc.PolicyContextHandler.supports
    - - ( - String - ) -
    - This public method returns a boolean result indicating whether or not the handler supports the context object identified by the (case-sensitive) key value. - true -
    -
    true
    JACC:JAVADOC:39intjakarta.security.jacc.WebResourcePermission.compareTo
    - - ( - Object - ) -
    - Determines whether this WebResourcePermission is less than, equal to, or greater than the specified object, and returns a negative integer, zero, or a positive integer respectively. - The behavior of this method must conform to the specification of the CompareTo method of interface Comparable. This method is used to sort WebResourcePermissions according to Servlet's path matching rules, and as necessary to implement best match for Servlet constraint selection and enforcement. WebResourcePermissions are sorted first by URL Pattern type. The sorting by URL Pattern type is done such that exact patterns (those not ending with * or /, or beginning with *.) sort less than path prefix patterns (those ending with /*), path prefix patterns sort less than extension patterns (those beginning with *.), and such that extension patterns sort less than the universal pattern /). Path prefix patterns are sorted first by pattern depth; with deeper patterns sorting less than shallower patterns. Same depth path prefix patterns are sorted by case sensitive lexical comparison of the same depth nodes, beginning with the root node, and continuing until a difference is found. Within pattern types other than path prefix patterns, same type patterns are sorted to case sensitive lexical order. Additional sorting by actions of pattern equivalent permissions is optional. - true -
    -
    true
    JACC:JAVADOC:40booleanjakarta.security.jacc.WebResourcePermission.equals
    - - ( - Object - ) -
    - Checks two WebResourcePermission objects for equality. - WebResourcePermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - true -
    -
    true
    JACC:JAVADOC:41Stringjakarta.security.jacc.WebResourcePermission.getActions
    -
    - Returns a canonical String representation of the actions of this WebResourcePermission. - WebResourcePermission actions are canonicalized by sorting the HTTP methods into lexical order. - true -
    -
    true
    JACC:JAVADOC:42intjakarta.security.jacc.WebResourcePermission.hashCode
    -
    - Returns the hash code value for this WebResourcePermission. - The properties of the returned hash code must be as follows: During the lifetime of a Java application, the hashCode method must return the same integer value, every time it is called on a WebResourcePermission object. The value returned by hashCode for a particular WebResourcePermission need not remain consistent from one execution of an application to another. If two WebResourcePermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:43booleanjakarta.security.jacc.WebResourcePermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this WebResourcePermission. - For this to be the case, The argument must be an instanceof WebResourcePermission with name matched by this WebResourcePermission (according to the servlet matching rules), and the HTTP methods to which the argument permission applies (as defined in its actions) must be a subset of the HTTP methods to which this WebResourcePermission applies (as defined in its actions). The servlet matching rules are used to determine if the name of this WebResourcePermission matches the name of the argument permission. The names match if the values of the URL pattern portions of their names are related as follows: their URL patterns are lexically equivalent, or the URL pattern of this WebResourcePermission is a path-prefix pattern (that is, it ends with /*), and the path-prefix pattern (minus the last 2 characters) is an exact match for a prefix of the URL pattern of the argument permission, or the URL pattern of this WebResourcePermission is an extension pattern (that is, it begins with *.) and the substring of the extension pattern beginning with the . and extending to the end of the pattern, is an exact match for the end of the URL pattern of the argument permission. the URL pattern of this WebResourcePermission is the special pattern containing only the default character / (may be more than one /) which matches all other URL patterns. All of the comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:44WebResourcePermissionjakarta.security.jacc.WebResourcePermission.WebResourcePermission
    - - ( - String - ,
    String - ) -
    - Creates a new WebResourcePermission with the specified name and actions. - The name contains a URL Pattern (as defined in the Java Servlet Specification). The URLPattern identifies the web resources to which the permission applies. The actions parameter contains a comma seperated list of HTTP methods. The syntax of the actions parameter is defined as follows: HTTPMethod ::= GET | POST | PUT | DELETE | HEAD | OPTIONS | TRACE HTTPMethodList ::= HTTPMethod | HTTPMethodList comma HTTPMethod HTTPMethodSpec ::= null | HTTPMethodList If duplicates occur in the HTTPMethodSpec they must be eliminated by the permission constructor. A null or empty string HTTPMethodSpec indicates that the permission applies to all HTTP methods at the resources identified by the URL pattern. - true -
    -
    true
    JACC:JAVADOC:45WebResourcePermissionjakarta.security.jacc.WebResourcePermission.WebResourcePermission
    - - ( - String - ,
    String[] - ) -
    - Creates a new WebResourcePermission with name corresponding to the URLPattern, and actions composed from the array of HTTP methods. - true -
    -
    true
    JACC:JAVADOC:46WebResourcePermissionjakarta.security.jacc.WebResourcePermission.WebResourcePermission
    - - ( - HttpServletRequest - ) -
    - Creates a new WebResourcePermission from the HttpServletRequest object. - A container uses this constructor prior to checking if a caller has permission to perform a servlet request. - true -
    -
    true
    JACC:JAVADOC:47booleanjakarta.security.jacc.WebRoleRefPermission.equals
    - - ( - Object - ) -
    - Checks two WebRoleRefPermission objects for equality. - WebRoleRefPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). The name and actions comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:48Stringjakarta.security.jacc.WebRoleRefPermission.getActions
    -
    - Returns a canonical String representation of the actions of this WebRoleRefPermission. - - true -
    -
    true
    JACC:JAVADOC:49intjakarta.security.jacc.WebRoleRefPermission.hashCode
    -
    - Returns the hash code value for this WebRoleRefPermission. - The properties of the returned hash code must be as follows: During the lifetime of an Java application, the hashCode method must return the same integer value, every time it is called on a WebRoleRefPermission object. The value returned by hashCode for a particular WebRoleRefPermission need not remain consistent from one execution of an application to another. If two WebRoleRefPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:50booleanjakarta.security.jacc.WebRoleRefPermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this WebRoleRefPermission. - For this to be the case, The argument must be an instanceof WebRoleRefPermission with name equivalent to this WebRoleRefPermission, and with role reference equivalent to this WebRoleRefPermission (as defined in their actions). The comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:51WebRoleRefPermissionjakarta.security.jacc.WebRoleRefPermission.WebRoleRefPermission
    - - ( - String - ,
    String - ) -
    - Creates a new WebRoleRefPermission with the specified name and actions. - - true -
    -
    true
    JACC:JAVADOC:52intjakarta.security.jacc.WebUserDataPermission.compareTo
    - - ( - Object - ) -
    - Determines whether this WebUserDataPermission is less than, equal to, or greater than the specified object, and returns a negative integer, zero, or a positive integer respectively. - The behavior of this method must conform to the specification of the CompareTo method of interface Comparable. This method is used to sort WebUserDataPermissions according to Servlet's path matching rules, and as necessary to implement best match for Servlet constraint selection and enforcement. WebUserDataPermissions are sorted first by URL Pattern type. The sorting by URL Pattern type is done such that exact patterns (those not ending with * or /, or beginning with *.) sort less than path prefix patterns (those ending with /*), path prefix patterns sort less than extension patterns (those beginning with *.), and such that extension patterns sort less than the universal pattern /). Path prefix patterns are sorted first by pattern depth; with deeper patterns sorting less than shallower patterns. Same depth path prefix patterns are sorted by case sensitive lexical comparison of the same depth nodes, beginning with the root node, and continuing until a difference is found. Within pattern types other than path prefix patterns, same type patterns are sorted to case sensitive lexical order. Additional sorting by actions of pattern equivalent permissions is optional. - true -
    -
    true
    JACC:JAVADOC:53booleanjakarta.security.jacc.WebUserDataPermission.equals
    - - ( - Object - ) -
    - Checks two WebUserDataPermission objects for equality. - WebUserDataPermission objects are equivalent if they have case equivalent name and actions values. Two Permission objects, P1 and P2, are equivalent if and only if P1.implies(P2) AND P2.implies(P1). - true -
    -
    true
    JACC:JAVADOC:54Stringjakarta.security.jacc.WebUserDataPermission.getActions
    -
    - Returns a canonical String representation of the actions of this WebUserDataPermission. - WebUserDataPermission actions are canonicalized by sorting the HTTP methods and transport Types into lexical order. - true -
    -
    true
    JACC:JAVADOC:55intjakarta.security.jacc.WebUserDataPermission.hashCode
    -
    - Returns the hash code value for this WebUserDataPermission. - The properties of the returned hash code must be as follows: During the lifetime of an Java application, the hashCode method shall return the same integer value every time it is called on a WebUserDataPermission object. The value returned by hashCode for a particular EJBMethod permission need not remain consistent from one execution of an application to another. If two WebUserDataPermission objects are equal according to the equals method, then calling the hashCode method on each of the two Permission objects must produce the same integer result (within an application). - true -
    -
    true
    JACC:JAVADOC:56booleanjakarta.security.jacc.WebUserDataPermission.implies
    - - ( - Permission - ) -
    - Determines if the argument Permission is implied by this WebUserDataPermission. - For this to be the case, The argument must be an instanceof WebUserDataPermission with name matched by this WebUserDataPermission (according to the servlet matching rules), and the HTTP methods to which the argument permission applies (as defined in its actions) must be a subset of the HTTP methods to which this WebUserDataPermission applies (as defined in its actions), and the transport types to which the argument permission applies (as defined in its actions) must be a subset of the Transport types to which this WebUserDataPermission applies (as defined in its actions). The servlet matching rules are used to determine if the name of this WebUserDataPermission matches the name of the argument permission. The names match if the values of the URL pattern portions of their names are related as follows: their URL patterns are lexically equivalent, or the URL pattern of this WebUserDataPermission is a path-prefix pattern (that is, it ends with /*), and the path-prefix pattern (minus the last 2 characters) is an exact match for a prefix of the URL pattern of the argument permission, or the URL pattern of this WebUserDataPermission is an extension pattern (that is, it begins with *.) and the substring of the extension pattern beginning with the . and extending to the end of the pattern, is an exact match for the end of the URL pattern of the argument permission. the URL pattern of this WebUserDataPermission is the special pattern containing only the default character / (there may be more than one /) which matches all other URL patterns. All of the comparisons described above are case sensitive. - true -
    -
    true
    JACC:JAVADOC:57WebUserDataPermissionjakarta.security.jacc.WebUserDataPermission.WebUserDataPermission
    - - ( - String - ,
    String - ) -
    - Creates a new WebUserDataPermission with the specified name and actions. - The name contains a URL Pattern (as defined in the Java Servlet Specification). The URL Pattern identifies the web resources to which the permission applies. The actions parameter contains a comma separated list of HTTP methods followed by a comma separated list of transport protection types. The syntax of the actions parameter is defined as follows: HTTPMethod ::= Get | POST | PUT | DELETE | HEAD | OPTIONS | TRACE - HTTPMethodList ::= HTTPMethod | HTTPMethodList comma HTTPMethod - HTTPMethodSpec ::= emptyString | HTTPMethodList - transportType ::= CLEAR | INTEGRAL | CONFIDENTIAL | UNCONSTRAINED - transportTypeList ::= transportType | transportTypeList comma transportType - transportTypeSpec ::= emptyString | transportTypeList - actions ::= null | HTTPMethodSpec | HTTPMethodSpec colon transportTypeSpec - -If duplicates occur in either the HTTPMethodSpec or transportTypeSpec, they must be eliminated by the permission constructor. An empty string HTTPMethodSpec is a shorthand for a List containing all the possible HTTP methods. An empty string transportTypeSpec is a shorthand for a TransportTypeList containing the transportType value UNCONSTRAINED. A transportType of UNCONSTRAINED indicates that the associated HTTP methods at the web resources identified by the URL pattern may be accessed over any transport. The transportType UNCONSTRAINED is overridden by any other transportType associated with an equivalent URLPattern. - - true -
    -
    true
    JACC:JAVADOC:58WebUserDataPermissionjakarta.security.jacc.WebUserDataPermission.WebUserDataPermission
    - - ( - String - ,
    String[] - ,
    String[] - ) -
    - Creates a new WebUserDataPermission with name corresponding to the URLPattern, and actions composed from the array of HTTP methods and the array of transport types. - - true -
    -
    true
    JACC:JAVADOC:59WebUserDataPermissionjakarta.security.jacc.WebUserDataPermission.WebUserDataPermission
    - - ( - HttpServletRequest - ) -
    - Creates a new WebUserDataPermission from the HttpServletRequest object. - A container uses this constructor prior to checking if a caller has permission to perform a servlet request. - true -
    -
    true
    - - diff --git a/internal/docs/jacc/jacc_1.2/JACCSpecAssertions.html b/internal/docs/jacc/jacc_1.2/JACCSpecAssertions.html deleted file mode 100644 index e7bd11d690..0000000000 --- a/internal/docs/jacc/jacc_1.2/JACCSpecAssertions.html +++ /dev/null @@ -1,1662 +0,0 @@ - - - - - -Specification Assertion Detail - - -
    -
    -

    Java Authorization Contract for Containers.
    1 - 1.0
    - Specification Assertion Detail -

    -
    - - - - - - - - - - - -
    TotalsTotalActiveDeprecatedRemoved
    - # of Assertions - 127114013
    - # of Required Assertions - 118107011
    - # of Optional Assertions - 9702
    -
    container assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:211.4J2EE 1.4 platforms must implement the contract defined by this JSR.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:311.4Support for the contract by J2EE 1.3 platforms is optional. (OPTIONAL)false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:511.4Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1011.4To support this contract in a Servlet environment, a container or its -deployment tools must create policy statements as necessary to -support Servlet's default role-ref semantic. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1111.4This contract must support providers that are unable to determine, -before returning from Policy.getPermissions(), all the permissions -that pertain to a subject/protection domain. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1211.4For a container to support this contract, it must execute in an -environment controlled by a J2SE security manager. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1311.4The evaluation of a permission corresponding to a resource must -identify the context of the resource's use such that different policy -can be applied to a resource used in different contexts (that is, -applications or instances of an application). - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1422.1The security property policy.provider may be used to replace the default -java.security.Policy implementation class. Similarly, the security -property auth.policy.provider may be used to replace the default -javax.security.auth.Policy implementation class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1522.5Each JRE of an application server must be provided with classes that implement -the PolicyConfigurationFactory class and PolicyConfiguration -interface. These classes must be compatible with the Policy implementation class -installed for use by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2122.7An application server or container must bundle or install the -jakarta.security.jacc standard extension. This package must include the -abstract jakarta.security.jacc.PolicyConfigurationFactory class, -the jakarta.security.jacc.PolicyConfiguration and -jakarta.security.jacc.PolicyContextHandler interfaces, and -implementations of the -jakarta.security.jacc.PolicyContextException exception, the -jakarta.security.jacc Permission classes, and the -jakarta.security.jacc.PolicyContext utility class. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:2222.7To enable delegation of non-jakarta.security.jacc policy decisions to -default system Policy providers, all application servers must implement the -following Policy replacement algorithm. - -For each JRE of a J2EE 1.4 application server, if the system property -jakarta.security.jacc.policy.provider is defined, the application server must -construct an instance of the class identified by the system property, -confirm that the resulting object is an instance of java.security.Policy, -and set, by calling the java.security.Policy.setPolicy, the resulting -object as the corresponding Policy object used by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2322.7For each JRE of a J2EE 1.4 application server, if the system property -jakarta.security.jacc.policy.provider is defined, the application -server must construct an instance of the class identified by the system property, -confirm that the resulting object is an instance of java.security.Policy, -and set, by calling the java.security.Policy.setPolicy method, the -resulting object as the corresponding Policy object used by the JRE. - -An application server that chooses to support this contract in a J2SE 1.3 -environment must perform the policy replacement algorithm described above -when the system property -jakarta.security.jacc.auth.policy.provider is defined. That is, -for each JRE of the application server, the server must construct an instance of the -class identified by the system property, confirm that the resulting object is an -instance of javax.security.auth.Policy, and set, by calling -javax.security.auth.Policy.setPolicy method, the resulting object -as the corresponding Policy object used by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2422.7.1A J2EE 1.3 application -server must install or bundle, such that it is used by every JRE of the application -server, a javax.security.auth.SubjectDomainCombiner whose -combine method returns protection domains constructed using the permission -collections returned by javax.security.auth.Policy.getPermisions. -It is recommended that this requirement also be satisfied by J2EE 1.4 application -servers in the case where javax.security.auth.Policy is being used (in -backward compatibility mode) by the SubjectDomainCombiner. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3233.1.2A servlet container is responsible -for mapping the target name or address information of an HTTP request to the -appropriate hostname. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7144.1.1The Servlet container must construct (or reuse) a WebUserDataPermission object -using the request URI minus the context path as the name and with actions -composed from the HTTP method of the request and a protection value describing -the transport layer protection of the connection on which the request arrived. -The protection value used in the permission construction must be -determined as follows: - - If the request arrived on a connection deemed by the container to be protected -for confidentiality, a protection value of :CONFIDENTIAL must be used. -- If the request arrived on a connection deemed by the container to be protected -for integrity (but not confidentiality), a protection value of :INTEGRAL must be used. -- If the request arrived on a connection deemed by the container to be unprotected, - the actions used in the permission construction must contain only the HTTP - method of the request. - -The Servlet container must use one of the methods described in Section 4.7, -Checking AccessControlContext Independent Grants to test if access to the -resource using the method and connection type encapsulated in the -WebUserDataPermission is permitted. If a SecurityException is thrown in the -permission determination, it must be caught, and the result of the determination -must be that access to the resource using the method and connection type is not -permitted. If access is not permitted, the request must be redirected as defined by -the Servlet Specification. If access is permitted, the request must be subjected to a -pre-dispatch decision. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7244.1.2The Servlet container must construct (or reuse) a WebResourcePermission object -using the request URI minus the context path as the name and with actions -corresponding to the HTTP method of the request. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7344.1.2If a SecurityException is thrown in the permission determination, it -must be caught, and the result of the determination must be that the permission is -not granted to the caller. The Servlet container may only dispatch the request to -the web resource if theWebResourcePermission is determined to be granted to the -caller. Otherwise the request must be rejected with the appropriate HTTP error -message as defined by the Servlet Specification. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7444.1.2Before it dispatches a call to a web resource, the container must associate with -the call thread an AccessControlContext containing the principals of (only) the -target component runAs identity (as defined in Section 4.5, Component runAs -Identity). - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7544.1.3When a call is made from a web resource to isUserInRole(String -roleName) the implementation of this method must construct (or reuse) a -WebRoleRefPermission object using the servlet-name of the calling web resource -as the name and with actions equal to the roleName used in the call. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7644.1.3If a -SecurityException is thrown in the permission determination, it must be caught, -and the result of the determination must be that the permission is not granted to -the caller. If it is determined that the WebRoleRefPermission has been granted to -the caller, isUserInRole must return true. Otherwise the return value must be false. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7744.2.2The policy statements of the identified PolicyConfiguration are filtered to -select the set of statements that refer to a permission of the same type as the -checked permission and that have as their name the url-pattern that is the bestmatch -to the name of the checked permission. The algorithm for determining the -best matching url-pattern is described in Section 4.2.2.1, Servlet URL-Pattern -Matching Rules. The resulting policy statements are then reduced to the set -whose actions match the actions of the checked permission. If the resulting set is -empty, the evaluation may terminate, and the result of the evaluation must be that -the checked permission is determined to be unconstrained and thus implicitly -granted. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:7844.2.2If the resulting set is not empty, and it contains one or more excluded policy -statements, the evaluation may terminate and the checked permission must be -determined not to be granted. - -Otherwise, if the set contains one or more unchecked policy statements, -the evaluation may terminate and the checked permission must be -determined to be granted. If the resulting set contained neither -excluded or unchecked policy statements, then the access control context may -only be determined to have been granted the checked permission if it has been -accorded a permission with name equal to the best-matching pattern, and with -actions equal to the actions of the checked permission. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:7944.2.2.1URL pattern matching must be guided by pattern type such that exact patterns -(those not ending with * or /, or beginning with *.) must match better than -path prefix patterns (those ending with /*) - - and such that path prefix patterns must match better than extension patterns - (those beginning with *.), - - and suchthat extension patterns must match better than the universal pattern /). - -Among path prefix matches, longer string length patterns must match better than shorter -patterns. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8044.3EJB containers must enforce the authorization policies established for EJB -resources as a result of the deployment of application modules containing EJB -resources. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8144.3.1The EJB container must construct (or reuse) an EJBMethodPermission object with -name corresponding to the ejb-name of the target resource. The actions used in the -permission construction must completely specify the method of the EJB by -identifying the method interface, method name, and method signature as defined -for a methodSpec in the documentation of the EJBMethodPermission class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8244.3.1If a SecurityException is -thrown in the permission determination, it must be caught, and the result of the -determination must be that the permission is not granted to the caller. The EJB -container may only dispatch the request to the EJB resource, if the -EJBMethodPermission is determined to be granted to the caller. Otherwise the -request must be rejected with the appropriate RMISecurityException, as defined -by the EJB specification. -Before it dispatches a call to an EJB, the container must associate with the call -thread an AccessControlContext containing the principals of only the target EJB -runAs identity (as defined in Section 4.5, Component runAs Identity). - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8344.3.2When an EJB makes a call to isCallerInRole(String roleName) the -implementation of this method must construct (or reuse) an -EJBRoleRefPermission object using the ejb-name of the EJB making the call as -the name and with the value of the roleName as actions. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8444.3.2If a -SecurityException is thrown in the permission determination, it must be caught, -and the result of the determination must be that the permission is not granted to -the caller. If it is determined that the EJBRoleRefPermission has been granted to -the caller, then isCallerInRole must return true. Otherwise the return value must -be false. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9144.5By default (and unless otherwise specified in the EJB or Servlet -specifications), components are configured such that they are assigned the identity -of their caller (such as it is) as their runAs identity. Alternatively, a Deployer may -choose to assign an environment specific identity as a component runAs identity. -In this case, the container must establish the specified identity as the component -runAs identity independent of the identity of the component caller. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9444.6A policy context identifier is set on a thread by calling the setContextID method -on the PolicyContext utility class. The value of a thread policy context identifier -is null until the setContextID method is called. Before invoking policy to evaluate -a transport guarantee or to perform a pre-dispatch decision, and before -dispatching into a Servlet or EJB component, a container must ensure that the -thread policy context identifier identifies the policy context corresponding -to the instance of the module or application for which the operation is being -performed. -Containers must be granted the setPolicy SecurityPermission independent -of policy context identifier (or in all policy contexts) as they need this permission -to set the policy context identifier. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9544.6.1This specification requires that containers register policy context handlers with -the PolicyContext utility class such that Policy providers can invoke these -handlers to obtain additional context to apply in their access decisions. Policy -context handlers are objects that implement the PolicyContextHandler interface. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9644.6.1All of the required context handlers must -return the value null when activated outside of the scope of a container's -processing of a component request. Policy providers must not call methods on or -modify the objects returned by the context handlers if these actions will cause the -container to fail in its processing of the associated request.. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9744.6.1.1All EJB and Servlet containers must register a PolicyContextHandler whose -getContext method returns a javax.security.auth.Subject object when invoked with -the key javax.security.auth.Subject.container. When this handler is activated -as the result of a policy decision performed by a container before dispatch -into a component, this handler must return a Subject containing the principals - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9844.6.1.2All EJB containers must register a PolicyContextHandler whose getContext -method returns a javax.xml.soap.SOAPMessage object when invoked with the -key javax.xml.soap.SOAPMessage. If the request being processed by the -container arrived as a SOAP request at the ServiceEndpoint method interface, the -container must return the SOAP message object when this handler is activated. -Otherwise, this handler must return the value null. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9944.6.1.3All Servlet containers must register a PolicyContextHandler whose getContext -method returns a javax.servlet.http.HttpServletRequest object when invoked with -the key javax.servlet.http.HttpServletRequest. When this handler is activated, -the container must return the HttpServletRequest object corresponding to the -component request being processed by the container. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10044.6.1.4All EJB containers must register a PolicyContextHandler whose getContext -method returns a jakarta.ejb.EnterpriseBean object when invoked with the key -jakarta.ejb.EnterpriseBean. When this handler is activated, the container must -return the EnterpriseBean object corresponding to theEJB component request being -processed by the container. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10144.6.1.5All EJB containers must register a PolicyContextHandler whose getContext -method returns an array of objects (Object[]) containing the arguments of the EJB -method invocation (in the same order as they appear in the method signature) -when invoked with the key jakarta.ejb.arguments. The context handler must -return the value null when called in the context of a SOAP request that arrived at -the ServiceEndpoint method interface. Otherwise, the context handler must return -the array of objects corresponding to the parameters of the EJB component -invocation. If there are no parameters in the method signature, the context handler -must return an empty array of Object (i.e. Object[0]). - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10244.7 A container must use one of the following techniques to check an instance of a -permission for which policy is defined independent of AccessControlContext. - -- The container calls AccessControlContext.checkPermission with -the permission being checked as argument. The call to checkPermission -may be made on any AccessControlContext. If checkPermission throws -an AccessControlException, the permission is not granted. Otherwise the -permission is granted. - -- The container calls AccessController.checkPermission with the -permission being checked. The value of the current thread?s -AccessControlContext is irrelevant in the access determination. If -checkPermission throws an AccessControlException, the checked -permission is not granted. Otherwise the permission is not granted. - -- The container calls SecurityManager.checkPermission with the -permission being checked. If checkPermission throws an -AccessControlException, the checked permission is not granted. Otherwise the -permission is granted. - -- The J2EE 1.4 container calls Policy.implies with two arguments; the -permission being checked and a ProtectionDomain that need not be -constructed with principals. The checked permission is granted if -Policy.implies returns true. Otherwise, the permission is not granted. - -- The J2EE 1.4 container calls -java.security.Policy.getPermissions with a ProtectionDomain -that need not be constructed with principals. The container must call the -implies method on the returned PermissionCollection using the permission -being checked as argument. The checked permission is granted if the -PermissionCollection implies it. Otherwise, the permission is not granted. This -technique is supported but not recommended. - -- The J2EE 1.3 container calls -javax.security.auth.Policy.getPermissions to determine the -collection of permissions granted independent of AccessControlContext. The -Subject in the call to getPermissions may be null. The container must call -the implies method on the returned PermissionCollection using the -permission being checked as argument. The checked permission is granted if -the PermissionCollection implies it. Otherwise, the permission is not granted. -This technique is supported but not recommended. - -Prior to using any of the techniques described in this section, the container -must have established a policy context identifier as defined in Section 4.6, -Setting the Policy Context. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10344.8A container must determine if the caller has been granted a permission by -evaluating the permission in the context of an AccessControlContext, -ProtectionDomain, or Subject containing the principals of (only) the caller. If the -caller's identity has been asserted or vouched for by a trusted authority (other than -the caller), the principals of the authority must not be included in the principals of -the caller.A container must use one of the following techniques to determine if a -permission has been granted to the caller. - -The container calls AccessControlContext.checkPermission with -the permission as argument. The call to checkPermission must be made on -an AccessControlContext that contains the principals of the caller. If -checkPermission throws an AccessControlException, the permission is not -granted to the caller. Otherwise the permission is granted. - -The container calls AccessController.checkPermission with the -permission as argument. The AccessControlContext associated with the thread -on which the call to checkPermission is made must contain the principals -of the caller. If checkPermission throws an AccessControlException, the -permission is not granted to the caller. Otherwise the permission is granted. - -The container calls SecurityManager.checkPermission with the -permission as argument. The AccessControlContext associated with the thread -on which the call to checkPermission is made must contain the principals -of the caller. If checkPermission throws an AccessControlException, the -permission is not granted to the caller. Otherwise the permission is granted. - -The J2EE 1.4 container calls Policy.implies with two arguments; the -permission being checked and a ProtectionDomain constructed with the -principals of the caller. The boolean result returned by Policy.implies -indicates whether or not the permission has been granted to the caller. - -The J2EE 1.4 container calls -java.security.Policy.getPermissions with an argument -ProtectionDomain that was constructed with the principals of the caller. The -container must call the implies method on the returned -PermissionCollection using the permission being checked as argument. If the -PermissionCollection implies the permission being tested, the permission has -been granted to the caller. Otherwise it has not. This technique is supported but -not recommended. - -The J2EE 1.3 container calls -javax.security.auth.Policy.getPermissions with an argument -Subject containing the principals of the caller.The container must call the -implies method on the returned PermissionCollection using the permission -being checked as argument. If the PermissionCollection implies the permission -being tested, the permission has been granted to the caller. Otherwise it has not. -This technique is supported but not recommended. -Prior to using any of the techniques described in this section, the container -must have established a policy context identifier as defined in Section 4.6, -Setting the Policy Context. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10644.11To be compatible with this contract, all of the JRE of a J2EE 1.4 application -server must perform all of the policy decisions defined by this contract by -interacting with the java.security.Policy instance available in the JRE -via the java.security.Policy.getPolicy method. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10744.11All of the JRE of a -J2EE 1.3 application server must perform all of the policy decisions defined by -this contract by interacting with the javax.security.auth.Policy instance -available in the JRE via the jakarta.security.auth.getPolicy method. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10822.7Once an application server has used either of the system properties defined in -this section to replace a Policy object used by a JRE, the application server must -not use setPolicy to replace the corresponding Policy object of the running JRE -again. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:12111.5 - The following list defines changes to this contract that - apply to containers running without a Java SE SecurityManager. - - 1. The restrictions defined in Section 3.3, Permission to - Configure Policy need not be enforced. Also, the - containers of the application server must not be - denied permission to perform any operation that would - have been permitted in the presence of a SecurityManager. - - 2. Such containers are not required (before dispatching a - call) to associate an AccessControlContext with the call - thread (as otherwise required by Section 4.1.3, - Pre-dispatch Decision and Section 4.3.1, - EJB Pre-dispatch Decision). - - 3. When performing the operations defined in Section 4.7, - Checking AccessControlContext Independent Grants and in - Section 4.8, Checking the Caller for a Permission, - such containers must not employ the - SecurityManager.checkPermission and - AccessControlContext.checkPermission techniques defined - in these sections. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:12233.0 - This subcontract also applies to the translation of - authorization policy annotations that have an equivalent - representation in Java EE deployment descriptor policy - constructs(i.e security-constraint, method-permission, - security-role-ref, and exclude-list elements) - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12333.1 - Independent of this specification, J2EE deployment tools must - translate and complete the declarative policy statements appearing - in deployment descriptors into a form suitable for securing - applications on the platform. On versions of the Java EE platform - that require support for authorization policy annotations, the - deployment tools must combine policy annotations in Java code with - policy statements appearing in deployment descriptors to yield - complete representations of authorization policy suitable for - securing applications on the platform. The rules for combining - authorization policy annotations with declarative policy statements - are described in the versions of the EJB, Servlet, and Java EE - platform specifications that require support for the annotations. - Independent of whether annotations factor in the translation, - the resulting policy statements may differ in form from the policy - statements appearing in the deployment descriptors. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12433.1.2 - When an application is composed of multiple web modules, a separate - policy context must be defined per module. This is necessary to ensure - that url-pattern based and servlet name based policy statements - configured for one module do not interfere with those configured - for another. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12533.1.4 - When an application is composed of multiple EJB jars, no two jars - that share at least one ejb-name value in common may share the same - policy context identifiers. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:12644.1.1 - Permission Names for Transport and Pre-Dispatch Decisions - The name of the permission checked in a transport or pre-dispatch - decision must be the value that would result from applying the Servlet - welcome file processing rules to the unqualified request URI minus the - context path. - - For the special case where this transformation of the request URI - yields the URLPattern /, the empty string URLPattern, , must be - used as the permission name. The welcome file processing rules are - defined in the Servlet specification. For the special case where the - empty string must be substituted for the / pattern in the permission - evaluation, all target related processing (including servlet mapping, - filter mapping, and form based login processing) must be performed - using the original pattern, /. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12744.6.1.4 - The EnterpriseBean object must only be returned when this handler - is activated within the scope of a container's processing of a - business method of the EJB Remote, Local, or ServiceEndpoint - interfaces of the EnterpriseBean object. The value null must be - returned if the bean implementation class does not implement the - jakarta.ejb.EnterpriseBean interface. - true -
    -
    falsetechnologyactivefalse
    provider assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:411.4Each Policy provider that satisfies this contract must perform or -delegate to another provider all the permission evaluations -requested via its interface in the JRE; not just those made by the -container to implement J2EE security functionality. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:611.4Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:711.4Each provider must satisfy all of the authorization requirements of - the EJB and Servlet specifications corresponding to the target - platform. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:811.4In the case of Servlet resources, the provider must be able to - associate a distinct policy context with each context root - (including context roots created to support virtual hosting) - hosted by the server. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:911.4In protecting Servlet resources, a provider must select the policy -statements that apply to a request according to the constraint -matching and servlet mapping rules defined by the Servlet -specification. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1622.5If the provider is seeking to replace the Policy implementation used by the -JRE, then the JRE must be provided with an environment specific Policy -implementation class. If the JRE is running a J2SE 1.4 security environment, then -it must be provided with an implementation of the java.security.Policy -class. If the JRE is running a J2SE 1.3 security environment, it must be provided -with an implementation of the javax.security.auth.Policy class (that is, -a JAAS Policy object). - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1722.5A replacement Policy object must assume responsibility for performing all -policy decisions within the JRE in which it is installed that are requested by way -of the Policy interface that it implements. A replacement Policy object may -accomplish this by delegating non-jakarta.security.jacc policy decisions to -the corresponding default system Policy implementation class. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1822.5A replacement -Policy object that relies in this way on the corresponding default Policy -implementation class must identify itself in its installation instructions as a -delegating Policy provider. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1922.5The standard security properties mechanism for replacing a default system -Policy implementation (see Section 2.1, Policy Implementation Class) should -not be used to replace a default system Policy provider with a delegating Policy -provider. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:2022.6A J2SE 1.4 provider may support replacement of -the JAAS Policy object if and only if all jakarta.security.jacc policy decisions -performed by the replacement JAAS Policy object return the same result as when -the java.security.Policy interface is used. To satisfy this requirement, the -replacement JAAS Policy object must be compatible with the implementations of -PolicyConfigurationFactory and PolicyConfiguration interface -provided for use with the java.security.Policy implementation class. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6333.2the provider must include an implementation of the -jakarta.security.jacc.PolicyConfigurationFactory class along -with a matched implementation of a class that implements the -jakarta.security.jacc.PolicyConfiguration interface. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6433.2In addition to -providing a PolicyConfiguration interface for integration with the -application server deployment tools, the provider must also include a -management interface for policy administrators to use to grant the collections of -permissions that comprise roles, to principals. This interface need not be -standardized. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:6533.2The provider must ensure that all of the permissions added to a role in a policy -context are granted to any principal mapped to the role by the policy -administrator. The provider must ensure that the same principal-to-role mappings -are applied to all linked policy contexts. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6633.2The provider must ensure that excluded policy statements take precedence -over overlapping unchecked policy statements, and that both excluded and -unchecked policy statements take precedence over overlapping role based policy -statements. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6733.3The getPolicyConfigurationFactory, and inService methods of the -abstract factory class, -jakarta.security.jacc.PolicyConfigurationFactory, must throw a -SecurityException when called by an AccessControlContext that has not been -granted the setPolicy SecurityPermission. -The getPolicyConfiguration method of all implementations of the -PolicyConfigurationFactory abstract class must throw a -SecurityException when called by an AccessControlContext that has not been -granted the setPolicy SecurityPermission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6833.3All of the public methods of all of the concrete implementations of the -PolicyConfiguration interface must throw a SecurityException when called -by an AccessControlContext that has not been granted the setPolicy -SecurityPermission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6933.3In cases where a required permission is not held by a caller, the -implementation must return without changing the state of the policy statement -repository. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:7033.3The containers of an application server must be granted the getPolicy -SecurityPermission and the setPolicy SecurityPermission. J2EE 1.3 Containers -that choose to support this contract must be granted the getPolicy -AuthPermission and the setPolicy AuthPermission. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:8544.4.1The policy statements of the PolicyConfiguration identified by calling the -getContextID method on the PolicyContext utility class must be tested to -determine if they match the permission being evaluated. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8644.4.1If one or more excluded -policy statements match the checked permission, the evaluation may terminate -and the checked permission must be determined not to be granted. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8744.4.1 if one or more unchecked policy statements match the checked permission, the -checked permission must be determined to be granted independent of access -control context. If neither of the excluded or unchecked comparisons yield a -match, then the access control context may only be determined to have been -granted the checked permission if a matching permission has been accorded to the -access control context. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8844.4.2An excluded or unchecked policy statement matches a checked permission if the -policy statement satisfies the rules for matching a granted permission to the -checked permission. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:8944.4.2A granted EJBMethodPermission matches a checked EJBMethodPermission -if their names are equivalent, and if the method specification in the actions of the -grnted permission matches the method specification in the actions of the che?ked -permission (as described in the definition of the EJBMethodPermission class). - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:9044.4.2One or more granted EJBRoleRefPermission objects match a checked -EJBRoleRefPermission if their names and actions are equivalent to the name of -the checked permission. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:9244.5When a Deployer configures an environment specific component identity -based on a deployment descriptor specification that the component run with an -identity mapped to a role, those responsible for defining the principal-to-role -mapping must ensure that the specified identity is mapped to the role. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9344.5A container establishes a component's runAs identity by associating an -AccessControlContext with the component's thread of execution. The container -must ensure that the AccessControlContext includes a SubjectDomainCombiner; -and the container must protect the AccessControlContext associated with a -running component such that, by default, the component is not granted -permissions sufficient to modify the AccessControlContext. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10444.9A Policy provider must return that a tested permission has not been granted if it -acquires a non-null policy context identifier by calling getContextID on the -PolicyContext class and the inService method of the -PolicyConfigurationFactory associated with the provider would return -false if called with the policy context identifier. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10544.10A Policy provider must include the policy statements of the default policy -context in every access determination it performs.A Policy provider that either -does not call PolicyContext.getContexdID, or does so and acquires the identifier -of the default policy context, must use only the policy statements of the default -policy context to perform its access determination. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10944.2.1A Policy provider must use the combined policy statements of the default policy -context (as defined in Section 4.10, Default Policy Context) and of the policy -context identified by calling PolicyContext.getContextID to determine if they -imply the permission being checked. If one or more excluded policy statements -imply the checked permission, the evaluation may terminate and the checked -permission must be determined not to be granted. Otherwise, if one or more -unchecked policy statements imply the checked permission, the checked -permission must be determined to be granted independent of -AccessControlContext. If the status of the checked permission is not resolved by -the excluded and unchecked evaluations, it must be determined if a permission -that implies the checked permission has been granted to the -AccessControlContext being tested for the permission. The checked permission -may only be determined to be granted if a permission that implies the checked -permission has been granted to the AccessControlContext. Otherwise the -permission must be determined not to be granted. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11044.2.1.1The URLPatternSpec syntax is defined as -follows: -URLPatternList ::= URLPattern | URLPatternList colon URLPattern -URLPatternSpec ::= URLPattern | URLPattern colon URLPatternList -name ::= URLPatternSpec -Given this syntax, A reference URLPatternSpec matches an argument -URLPatternSpec if all of the following are true. -- The first URLPattern in the argument URLPatternSpec is matched by the first -URLPattern in the reference URLPatternSpec. --The first URLPattern in the argument URLPatternSpec is NOT matched by -any URLPattern in the URLPatternList of the reference URLPatternSpec. -- If the first URLPattern in the argument URLPatternSpec matches the first -URLPattern in the reference URLPatternSpec, then every URLPattern in the -URLPatternList of the reference URLPatternSpec must be matched by a -URLPattern in the URLPatternList of the argument URLPatternSpec. -The comparisons described above are case sensitive, and all matching is -according to the rules defined in Section 3.1.3.3, Servlet URL-Pattern Matching -Rules. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11144.2.1.2A reference WebResourcePermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebResourcePermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11244.2.1.3A reference WebRoleRefPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebRoleRefPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The actions (i.e role reference) of the argument permission is equivalent to the -actions (i.e role reference) of the reference permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11344.2.1.4A reference WebUserDataPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebUserDataPermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -- The transportType in the actions of the reference permission either corresponds -to the value "NONE", or equals the transportType in the actions of the -argument permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11344.2.1.4 A reference WebUserDataPermission implies an argument permission if all of the -following are true. -- The argument permission is an instanceof WebUserDataPermission. -- The name of the argument permission is matched by the name of the reference -permission according to the rules defined in Section 4.2.1.1, ?Matching Qualified -URL Pattern Names. -- The HTTP methods in the actions of the argument permission are a subset of -the HTTP methods in the actions of the reference permission. -- The transportType in the actions of the reference permission either corresponds -to the value "NONE", or equals the transportType in the actions of the -argument permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11444.4.1A Policy provider must employ the policy decision semantics described in -Section 4.2.1, Servlet Policy Decision Semantics in the Processing of EJB -Policy decisions. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11544.4.1.1A reference EJBMethodPermission implies an argument permission, if all of the -following are true. -- The argument permission is an instanceof EJBMethodPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The methods to which the argument permission applies (as defined in its actions) -must be a subset of the methods to which the reference permission applies -(as defined in its actions). This rule is satisfied if all of the following -conditions are met. -- The method name of the reference permission is null, the empty -string, or equivalent to the method name of the argument -permission. -- The method interface of the reference permission is null, the empty -string, or equivalent to the method interface of the argument -permission. -- The method parameter type list of the reference permission is null, -the empty string, or equivalent to the method parameter type list of -the argument permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11644.4.1.2A reference EJBRoleRefPermission implies an argument permission, if all of the -following are true. -- The argument permission is an instanceof EJBRoleRefPermission. -- The name of the argument permission is equivalent to the name of the reference -permission. -- The actions (i.e role reference) of the argument permission is equivalent to the -actions (i.e role reference) of the reference permission. -The comparisons described above are case sensitive. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11733.1.3.1A WebResourcePermission and a WebUserDataPermission must be -instantiated for each url-pattern in the deployment descriptor and the default -pattern, "/", that is not combined by the web-resource-collection elements -of the deployment descriptor with every HTTP method value. The permission -objects must be constructed using the qualified pattern as their name and with -actions defined by the subset of the HTTP methods that do not occur in -combination with the pattern.The resulting permissions must be added to the -unchecked policy statements by calling the addToUncheckedPolicy method -on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11833.1.3.1The WebResourcePermission and WebUserDataPermission objects resulting -from the translation of a Servlet deployment descriptor must be constructed with -name produced by qualifying the URL pattern. The rules for qualifying a URL -pattern are dependent on the rules for determining if one URL pattern matches -another as defined in Section 3.1.3.3, Servlet URL-Pattern Matching Rules, and -are described as follows: - -- If the pattern is a path prefix pattern, it must be qualified by every path-prefix -pattern in the deployment descriptor matched by and different from the pattern -being qualified. The pattern must also be qualified by every exact pattern -appearing in the deployment descriptor that is matched by the pattern being -qualified. - -- If the pattern is an extension pattern, it must be qualified by every path-prefix -pattern appearing in the deployment descriptor and every exact pattern in the -deployment descriptor that is matched by the pattern being qualified. - -- If the pattern is the default pattern, "/", it must be qualified by every other pattern -except the default pattern appearing in the deployment descriptor. - -- If the pattern is an exact pattern, its qualified form must not contain any qualifying -patterns. - -URL patterns are qualified by appending to their String representation, a -colon separated representation of the list of patterns that qualify the pattern. -Duplicates must not be included in the list of qualifying patterns, and any -qualifying pattern matched by another qualifying pattern may be dropped from -the list. -QualifyingPatternList ::= - empty string | colon QualifyingPattern | - QualifyingPatternList colon QualifyingPattern - QualifiedPattern ::= Pattern QualifyingPatternList - -Any pattern, qualified by a pattern that matches it, is overridden and made -irrelevant (in the translation) by the qualifying pattern. Specifically, all extension -patterns and the default pattern are made irrelevant by the presence of the path -prefix pattern "/*" in a deployment descriptor. Patterns qualified by the "/*" -pattern violate the URLPatternSpec constraints of WebResourcePermission and -WebUserDataPermission names and must be rejected by the corresponding -permission constructors. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:11933.1.3.1This URL pattern matches another pattern if they are related, by case sensitive -comparison, as follows: -- their pattern values are String equivalent, or -- this pattern is the path-prefix pattern "/*", or -- this pattern is a path-prefix pattern (that is, it starts with "/" and ends with -"/*") and the other pattern starts with the substring of this pattern, minus its -last 2 characters, and the next character of the other pattern, if there is one, is -"/", or -- this pattern is an extension pattern (that is, it starts with "*.") and the other -pattern ends with this pattern, or -- this pattern is the special default pattern, "/", which matches all other patterns. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:12033.1.6After the PolicyConfiguration objects are linked, the commit method -must be called on all the PolicyConfiguration objects to place them in -service such that their policy statements will be assimilated by the corresponding -Policy providers. - true -
    -
    falsetechnologyactivefalse
    tools assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:2533.1The getPolicyConfigurationFactory method must be used in every JRE -to which the components of the application or module are being deployed to find -or instantiate PolicyConfigurationFactory objects. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2633.1The getPolicyConfiguration method of the factories must be used to -find or instantiate PolicyConfiguration objects corresponding to the -application or modules being deployed. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2733.1The declarative authorization policy statements derived from application or -module deployment descriptor(s) must be translated to create instances of the -corresponding jakarta.security.jacc Permission classes. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2833.1Methods of the PolicyConfiguration interface must be used with the -permissions resulting from the translation to create policy statements within the -PolicyConfiguration objects. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2933.1The PolicyConfiguration objects must be linked such that the same -principal-to-role mapping will be applied to all the modules of the application. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3033.1Independent of this specification, J2EE deployment tools must translate and -complete the declarative policy statements appearing in deployment descriptors -into a form suitable for securing applications on the platform. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:3133.1.1.1A policy context is in one of three states and all -implementations of the PolicyConfiguration interface must implement the state -semantics defined in this section. - -- open -A policy context in the open state must be available for configuration by any -of the methods of the PolicyConfiguration interface. A policy context in the -open state must not be assimilated at Policy.refresh into the policy statements -used by the Policy provider in performing its access decisions. - -- inService -A policy context in the inService state must be assimilated at Policy.refresh -into the policy statements used by its provider. When a provider's refresh -method is called, it must assimilate only policy contexts that are in the inService -state and it must ensure that the policy statements put into service for -each policy context are only those defined in the context at the time of the call -to refresh. A policy context in the inService state must be unavailable for -additional configuration. A policy context in the inService state must be transitioned -to the open state when it is returned as a result of a call to getPolicy- -Configuration. A policy context is transitioned to the inService state by -calling the commit method, and only a policy context in the open state may be -transitioned to the inService state. - -- deleted -A policy context in the deleted state must be unavailable for configuration and -it must be unavailable for assimilation into its associated Provider. A policy -context in the deleted state must be transitioned to the open state when it is -returned as a result of a call to getPolicyConfiguration. A policy context is -transitioned to the deleted state by calling the delete method. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:3333.1.3A reference to a PolicyConfiguration object must be obtained by calling the -getPolicyConfiguration method on the -PolicyConfigurationFactory implementation class of the provider -configured into the container. The policy context identifier used in the call to the -getPolicyConfiguration method must be a String composed as -described in Section 3.1.2, Servlet Policy Context Identifiers, on page 18. The -value true must be passed as the second parameter in the call to -getPolicyConfiguration to ensure that any and all policy statements are -removed from the policy context associated with the returned -PolicyConfiguration. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3433.1.3.1A WebResourcePermission and a WebUserDataPermission object must be -instantiated for each distinct url-pattern occurring in the securityconstraint -elements that contain an auth-constraint naming no roles (i.e -an excluding auth-constraint). The permissions must be constructed using -the qualified (as defined in Qualified URL Pattern Names) pattern as their name -and with actions defined by the union of the HTTP methods named or implied -by all of the collections containing the pattern and occurring in a constraint with -an excluding auth-constraint. The constructed permissions must be added to -the excluded policy statements by calling the addToExcludedPolicy method -on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3533.1.3.1A WebResourcePermission must be instantiated for each distinct combination -in the cross-product of url-pattern and role-name occurring in the -security-constraint elements that contain an auth-constraint -naming roles. When an auth-constraint names the reserved role-name, -"*", all of the patterns in the containing security-constraint must be -combined with all of the roles defined in the web application. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3633.1.3.1Each WebResourcePermission object must be constructed using the qualified pattern as -its name and with actions defined by the union of the HTTP methods named or -implied by the collections containing the pattern and occurring in a constraint that -names (or implies via "*") the role to which the permission is being added. The -resulting permissions must be added to the corresponding roles by calling the -addToRole method on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3733.1.3.1 The -resulting permissions must be added to the corresponding roles by calling the -addToRole method on the PolicyConfiguration object. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:3833.1.3.1A WebResourcePermission must be instantiated for each distinct urlpattern -occurring in the security-constraint elements that do not -contain an auth-constraint. Each WebResourcePermission object must be -constructed using the qualified pattern as its name and with actions defined by the -union of the HTTP methods named or implied by the collections containing the -pattern and occurring in a security-constraint without an authconstraint. -The resulting permissions must be added to the unchecked policy -statements by calling the addToUncheckedPolicy method on the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3933.1.3.1The WebResourcePermission objects resulting from -the translation of a security-constraint that does not contain an authconstraint -must be added to the unchecked policy statements by calling -addToUncheckedPolicy on the PolicyConfiguration object. - true -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:4033.1.3.1The -WebResourcePermission objects resulting from the translation of a securityconstraint -containing an auth-constraint that named no roles must be -added to the excluded policy statements by calling addToExcludedPolicy on -the PolicyConfiguration object. - false -
    -
    falsetechnologyremovedtrue
    JACC:SPEC:4133.1.3.1A WebUserDataPermission must be instantiated for each distinct combination -of url-pattern and acceptable connection type resulting from the processing -of the security-constraint elements that do not contain an excluding -auth-constraint. The mapping of security-constraint to acceptable -connection type must be as defined in Mapping Transport Guarantee to Connection -Type. Each WebUserDataPermission object must be constructed using the -qualified pattern as its name and with actions defined by appending a -representation of the acceptable connection type to the union of the HTTP -methods named or implied by the collections containing the pattern and occurring -in a security-constraint that maps to the connection type and that does not -contain an excluding auth-constraint. The resulting permissions must be -added to the unchecked policy statements by calling the -addToUncheckedPolicy method on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4233.1.3.1A transport-guarantee (in a user-data-constraint) of NONE, or a -security-constraint without a user-data-constraint, indicates that -the associated URL patterns and HTTP methods may be accessed over any -(including an unprotected) transport. A transport-guarantee of -INTEGRAL indicates that acceptable connections are those deemed by the -container to be integrity protected. A transport-guarantee of -CONFIDENTIAL indicates that acceptable connections are those deemed by the -container to be protected for confidentiality. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4333.1.3.2For each security-role-ref appearing in the deployment descriptor a -corresponding WebRoleRefPermission must be created. The name used in the -construction of each WebRoleRefPermission must be the servlet-name in -whose context the security-role-ref is defined. The actions used to -construct the permission must be the value of the role-name (that is the -reference), appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4433.1.3.2The deployment tools must call the addToRole method on the - PolicyConfiguration object to add the WebRoleRefPermission object - resulting from the translation to the role identified in the role-link - appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4533.1.3.2For each servlet element in the deployment descriptor a WebRoleRefPermission must -be created for each security-role whose name does not appear as the rolename -in a security-role-ref within the servlet element. Each such -WebRoleRefPermission must be created with action (that is, reference) -corresponding to the role-name and added to the role with the same name (as -the reference) by calling the addToRole method on the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4633.1.4an application server must establish EJB policy -context identifiers sufficient to differentiate all instances of the deployment of an -EJB jar on the application server, or on any other application server with which -the server may share the same policy statement repository. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:4733.1.5.1An EJBMethodPermission object must be created for each role-name or -unchecked element contained in each method-permission element -appearing in the deployment descriptor. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4833.1.5.1The name of each EJBMethodPermission -must be the ejb-name as defined in the method element of the methodpermission -element. The actions used in the permission construction must be -obtained by translating the contents of the method element into a method -specification according to the methodSpec syntax defined in the documentation of -the EJBMethodPermission class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4933.1.5.1If the method-permission element contains the unchecked element, -then the deployment tools must call the addToUncheckedPolicy method to -add the permission resulting from the translation to the -PolicyConfiguration object. - -Alternatively, if the method-permission -element contains one or more role-name elements, then the deployment tools -must call the addToRole method to add each of the permissions resulting from -the translation to the corresponding role of the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5033.1.5.2An EJBMethodPermission object must be created for each method element -occurring in the exclude-list element of the deployment descriptor. The -name and actions of each EJBMethodPermission must be established as described -in Section 3.1.5.1, Translating EJB method-permission Elements. -The deployment tools must use the addToExcludedPolicy method to add -the EJBMethodPermission objects resulting from the translation of the -exclude-list to the excluded policy statements of the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5133.1.5.3For each security-role-ref element appearing in the deployment -descriptor, a corresponding EJBRoleRefPermission must be created. The name of -each EJBRoleRefPermission must be obtained as described for -EJBMethodPermission objects. The actions used to construct the permission must -be the value of the role-name (that is the reference), appearing in the -security-role-ref. The deployment tools must call the addToRole -method on the PolicyConfiguration object to add a policy statement -corresponding to the EJBRoleRefPermission to the role identified in the rolelink -appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5233.1.6The application server's deployment tools must translate the declarative -authorization policy appearing in the application or module deployment -descriptor(s) into policy statements within the Policy providers used by the -containers to which the components of the application or module are being -deployed. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5333.1.6When a module is deployed, its policy context must be linked to the policy -context of every other module with which it must share the same principal-to-role -mapping. When an application is deployed, the policy contexts of every module of -the application must be linked to the policy contexts of every other module of the -application with which it shares a common Policy provider. Policy contexts are -linked by calling the linkConfiguration method on the PolicyConfiguration -objects of the provider. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5433.1.6Once the translation, linking, and committing has occurred, a call must be -made to Policy.refresh on the Policy provider used by each of the containers -to which the application or module is being deployed. The calls to -Policy.refresh must occur before the containers will accept requests for the -deployed resources. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5533.1.6The policy context identifiers corresponding to the deployed application or -module must be recorded in the application server so that they can be used by -containers to establish the policy context as required by Section 4.6, Setting the -Policy Context of the Policy Decision and Enforcement Subcontract, and such -that the Deployer may subsequently remove or modify the corresponding policy -contexts as a result of the undeployment or redeployment of the application. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5633.1.7A -deployment tool indicates that a policy context is to be removed from service -either by calling getPolicyConfiguration with the identifier of the policy context -on the provider's PolicyConfigurationFactory or by calling delete on the -corresponding PolicyConfiguration object. If the getPolicyConfiguration method -is used, the value true should be passed as the second argument to cause the -corresponding policy statements to be deleted from the context. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5733.1.7To ensure that there is not a period during undeployment when the removal of -policy statements on application components renders what were protected -components unprotected, the application server must stop accepting requests for -the application's components before undeploying an application or module. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5833.1.7After the policy -contexts are marked for removal from service, a call must be made to -Policy.refresh on all of the Policy providers from which at least one module -of the application or module was marked for removal from service. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5933.1.7To facilitate redeployment to an existing policy configuration, container -deployment tools may also support a mode in which they do not delete the -PolicyConfiguration objects associated with the application or module -being undeployed. - false -
    -
    falsetechnologyremovedfalse
    JACC:SPEC:6033.1.8Containers are not required to deploy to an existing policy configuration. -Containers that chose to provide this functionality must satisfy the following -requirements. -To associate an application or module with an existing set of linked policy -contexts, the identifiers of the existing policy contexts must be applied by the -relevant containers in fulfilling their obligations as defined in the Policy Decision -and Enforcement Subcontract. The policy contexts should be verified for -existence, by calling the inService method of the -PolicyConfigurationFactory of the Policy providers of the relevant -containers. The deployment tools must call Policy.refresh on the Policy -provider of each of the relevant containers, and the containers must not accept -requests for the deployed resources until these calls have completed. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6133.1.9Containers are not required to implement redeployment functionality.false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:6233.1.9Containers -that chose to provide this functionality must satisfy the following requirements. - -To ensure redeployment does not create a situation where the removal of -policy statements on application components renders what were protected -components unprotected, the application server must stop accepting requests for -the application's components before redeployment begins. The application server -must not resume processing requests for the application's components until after -the calls to Policy.refresh, described below, have completed. - -To redeploy a module, the deployment tools must indicate at all of the Policy -providers to which the module is to be redeployed that the policy context -associated with the module is to be removed from service. If the module is to be -redeployed to the same policy context at a provider, all policy statements must be -removed from the policy context at the provider. - -After the policy contexts have been marked for removal from service and emptied of policy statements (as -necessary), the deployment tools must translate the declarative authorization -policy appearing in the module's deployment descriptor into PolicyConfiguration -objects within the Policy providers at which the module is being redeployed. - - After the translation, the PolicyConfiguration objects must be linked, as -necessary, to the policy context of every other module in the same provider with -which the module must share the same principal-to-role mappings. - -After the module is linked, the commit method must be called on the -PolicyConfiguration objects. After commit has been called, a call must be -made to Policy.refresh on the Policy provider used by each of the containers -to which the module has been redeployed. - false -
    -
    falsetechnologyactivetrue
    - - diff --git a/internal/docs/jacc/jacc_1.2/assertions.html b/internal/docs/jacc/jacc_1.2/assertions.html deleted file mode 100644 index 7aa41dbc94..0000000000 --- a/internal/docs/jacc/jacc_1.2/assertions.html +++ /dev/null @@ -1,1229 +0,0 @@ - - - - - -Specification Assertion Detail - - -
    -
    -

    Java Authorization Contract for Containers.
    1 - 1.0
    - Specification Assertion Detail -

    -
    - - - - - - - - - - - -
    TotalsTotalActiveDeprecatedRemoved
    - # of Assertions - 10610600
    - # of Required Assertions - 969600
    - # of Optional Assertions - 101000
    -
    container assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:211.4J2EE 1.4 platforms must implement the contract defined by this JSR.true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:311.4Support for the contract by J2EE 1.3 platforms is optional. (OPTIONAL)false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:511.4Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1011.4To support this contract in a Servlet environment, a container or its -deployment tools must create policy statements as necessary to -support Servlet's default role-ref semantic. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1111.4This contract must support providers that are unable to determine, -before returning from Policy.getPermissions(), all the permissions -that pertain to a subject/protection domain. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1211.4For a container to support this contract, it must execute in an -environment controlled by a J2SE security manager. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1311.4The evaluation of a permission corresponding to a resource must -identify the context of the resource's use such that different policy -can be applied to a resource used in different contexts (that is, -applications or instances of an application). - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1422.1The security property policy.provider may be used to replace the default -java.security.Policy implementation class. Similarly, the security -property auth.policy.provider may be used to replace the default -javax.security.auth.Policy implementation class. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1522.5Each JRE of an application server must be provided with classes that implement -the PolicyConfigurationFactory class and PolicyConfiguration -interface. These classes must be compatible with the Policy implementation class -installed for use by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2122.7An application server or container must bundle or install the -jakarta.security.jacc standard extension. This package must include the -abstract jakarta.security.jacc.PolicyConfigurationFactory class -and implementations of the jakarta.security.jacc Permission classes and the -jakarta.security.jacc.PolicyContext utility class. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:2222.7To enable delegation of non-jakarta.security.jacc policy decisions to -default system Policy providers, all application servers must implement the -following Policy replacement algorithm. - -For each JRE of a J2EE 1.4 application server, if the system property -jakarta.security.jacc.policy.provider is defined, the application server must -construct an instance of the class identified by the system property, -confirm that the resulting object is an instance of java.security.Policy, -and set, by calling the java.security.Policy.setPolicy, the resulting -object as the corresponding Policy object used by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2322.7In both J2SE 1.3 and J2SE 1.4 environments, if the system property -“jakarta.security.jacc.auth.policy.provider” is defined, an application -server must use an analogous method to construct an instance of the class -identified by the system property, confirm that the resulting object is an instance -of javax.security.auth.Policy, and set, by calling -javax.security.auth.Policy.setPolicy, the resulting object as the -corresponding Policy object used by the JRE. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2422.7.1A J2EE 1.3 application -server must install or bundle, such that it is used by every JRE of the application -server, a javax.security.auth.SubjectDomainCombiner whose -combine method returns protection domains constructed using the permission -collections returned by javax.security.auth.Policy.getPermisions. -It is recommended that this requirement also be satisfied by J2EE 1.4 application -servers in the case where javax.security.auth.Policy is being used (in -backward compatibility mode) by the SubjectDomainCombiner. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3233.1.2A servlet container is responsible -for mapping the target name or address information of an HTTP request to the -appropriate hostname. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7144.1.1The Servlet container must construct (or reuse) a WebUserDataPermission object -using the request URI minus the context path as the name and with actions -composed from the HTTP method of the request and a protection value describing -the transport layer protection of the connection on which the request arrived. - -If access to the resource has been excluded, the request must be -redirected as defined by the Servlet Specification. If access to the resource has not -been excluded, the request must be subjected to a pre-dispatch decision. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7244.1.2The Servlet container must construct (or reuse) a WebResourcePermission object -using the request URI minus the context path as the name and with actions -corresponding to the HTTP method of the request. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7344.1.2If a SecurityException is thrown in the permission determination, it -must be caught, and the result of the determination must be that the permission is -not granted to the caller. The Servlet container may only dispatch the request to -the web resource if theWebResourcePermission is determined to be granted to the -caller. Otherwise the request must be rejected with the appropriate HTTP error -message. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7444.1.2Before it dispatches a call to a web resource, the container must associate with -the call thread an AccessControlContext containing the principals of (only) the -target component’s runAs identity (as defined in Section 4.5, “Component runAs -Identity). - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7544.1.3When a call is made from a web resource to isUserInRole(String -roleName) the implementation of this method must construct (or reuse) a -WebRoleRefPermission object using the servlet-name of the calling web resource -as the name and with actions equal to the roleName used in the call. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7644.1.3If a -SecurityException is thrown in the permission determination, it must be caught, -and the result of the determination must be that the permission is not granted to -the caller. If it is determined that the WebRoleRefPermission has been granted to -the caller, isUserInRole must return true. Otherwise the return value must be false. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7744.2.2The policy statements of the identified PolicyConfiguration are filtered to -select the set of statements that refer to a permission of the same type as the -checked permission and that have as their name the url-pattern that is the bestmatch -to the name of the checked permission. The algorithm for determining the -best matching url-pattern is described in Section 4.2.2.1, “Servlet URL-Pattern -Matching Rules”. The resulting policy statements are then reduced to the set -whose actions match the actions of the checked permission. If the resulting set is -empty, the evaluation may terminate, and the result of the evaluation must be that -the checked permission is determined to be unconstrained and thus implicitly -granted. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7844.2.2If the resulting set is not empty, and it contains one or more excluded policy -statements, the evaluation may terminate and the checked permission must be -determined not to be granted. - -Otherwise, if the set contains one or more unchecked policy statements, -the evaluation may terminate and the checked permission must be -determined to be granted. If the resulting set contained neither -excluded or unchecked policy statements, then the access control context may -only be determined to have been granted the checked permission if it has been -accorded a permission with name equal to the best-matching pattern, and with -actions equal to the actions of the checked permission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7944.2.2.1URL pattern matching must be guided by pattern type such that exact patterns -(those not ending with * or /, or beginning with *.) must match better than -path prefix patterns (those ending with /*) - - and such that path prefix patterns must match better than extension patterns - (those beginning with *.), - - and suchthat extension patterns must match better than the universal pattern /). - -Among path prefix matches, longer string length patterns must match better than shorter -patterns. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8044.3EJB containers must enforce the authorization policies established for EJB -resources as a result of the deployment of application modules containing EJB -resources. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8144.3.1The EJB container must construct (or reuse) an EJBMethodPermission object with -name corresponding to the ejb-name of the target resource. The actions used in the -permission construction must completely specify the method of the EJB by -identifying the method interface, method name, and method signature as defined -for a methodSpec in the documentation of the EJBMethodPermission class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8244.3.1If a SecurityException is -thrown in the permission determination, it must be caught, and the result of the -determination must be that the permission is not granted to the caller. The EJB -container may only dispatch the request to the EJB resource, if the -EJBMethodPermission is determined to be granted to the caller. Otherwise the -request must be rejected with the appropriate RMISecurityException, as defined -by the EJB specification. -Before it dispatches a call to an EJB, the container must associate with the call -thread an AccessControlContext containing the principals of only the target EJB’s -runAs identity (as defined in Section 4.5, “Component runAs Identity). - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8344.3.2When an EJB makes a call to isCallerInRole(String roleName) the -implementation of this method must construct (or reuse) an -EJBRoleRefPermission object using the ejb-name of the EJB making the call as -the name and with the value of the roleName as actions. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8444.3.2If a -SecurityException is thrown in the permission determination, it must be caught, -and the result of the determination must be that the permission is not granted to -the caller. If it is determined that the EJBRoleRefPermission has been granted to -the caller, then isCallerInRole must return true. Otherwise the return value must -be false. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9144.5By default (and unless otherwise specified in the EJB or Servlet -specifications), components are configured such that they are assigned the identity -of their caller (such as it is) as their runAs identity. Alternatively, a Deployer may -choose to assign an environment specific identity as a component’s runAs identity. -In this case, the container must establish the specified identity as the component’s -runAs identity independent of the identity of the component’s caller. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9444.6A policy context identifier is set on a thread by calling the setContextID method -on the PolicyContext utility class. The value of a thread’s policy context identifier -is null until the setContextID method is called. Before invoking policy to evaluate -a transport guarantee or to perform a pre-dispatch decision, and before -dispatching into a Servlet or EJB component, a container must ensure that the -thread’s policy context identifier identifies the PolicyConfiguration corresponding -to the instance of the module or application for which the operation is being -performed. -Containers must be granted the “setPolicy” SecurityPermission independent -of policy context identifier (or in all policy contexts) as they need this permission -to set the policy context identifier. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9544.6.1This specification requires that containers register policy context handlers with -the PolicyContext utility class such that policy providers can invoke these -handlers to obtain additional context to apply in their access decisions. Policy -context handlers are objects that implement the PolicyContextHandler interface. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9644.6.1All of the required context handlers must -return the value null when activated outside of the scope of a container’s -processing of a component request. Policy modules must not call methods on or -modify the objects returned by the context handlers if these actions will adversely -affect the container’s ability to process the request. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9744.6.1.1All EJB and Servlet containers must register a PolicyContextHandler whose -getContext method returns a javax.security.auth.Subject object when invoked with -the key “javax.security.auth.Subject.container”. When this handler is activated -as the result of a policy decision performed by a container before dispatch -into a component, this handler must return a Subject containing the principals - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:9844.6.1.2All EJB and Servlet containers must register a PolicyContextHandler whose -getContext method returns a javax.xml.soap.SOAPMessage object when invoked -with the key “javax.xml.soap.SOAPMessage”. If the request being processed by -the container arrived as a SOAP request, the container must return the SOAP -message object when this handler is activated. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9944.6.1.3All Servlet containers must register a PolicyContextHandler whose getContext -method returns a javax.servlet.http.HttpServletRequest object when invoked with -the key “javax.servlet.http.HttpServletRequest”. When this handler is activated, -the container must return the HttpServletRequest object corresponding to the -component request being processed by the container. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10044.6.1.4All EJB containers must register a PolicyContextHandler whose getContext -method returns a jakarta.ejb.EnterpriseBean object when invoked with the key -“jakarta.ejb.EnterpriseBean”. When this handler is activated, the container must -return the EnterpriseBean object corresponding to the component request being -processed by the container. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10144.6.1.5All EJB containers must register a PolicyContextHandler whose getContext -method returns an array of objects (Object[]) containing the arguments of the EJB -method invocation (in the same order as they appear in the method signature) -when invoked with the key “jakarta.ejb.arguments”. If there are no parameters in -the method signature, the context handler must return the value null. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10244.7The policy statements -corresponding to WebUserDataPermission objects are represented as excluded -policy statements. A container must use one of the following techniques to -determine if a WebUserDataPermission is excluded1. - -The container calls AccessControlContext.checkPermission with -the WebUserDataPermission as argument. The call to checkPermission -may be made on any AccessControlContext. If checkPermission throws -an AccessControlException, the WebUserDataPermission is excluded. -Otherwise the permission is not excluded. - - The container calls AccessController.checkPermission with the -WebUserDataPermission as argument. The value of the current thread’s -AccessControlContext is irrelevant in the access determination. If -checkPermission throws an AccessControlException, the -WebUserDataPermission is excluded. Otherwise the permission is not -excluded. - - The container calls SecurityManager.checkPermission with the -WebUserDataPermission as argument. If checkPermission throws an -AccessControlException, theWebUserDataPermission is excluded.Otherwise -the permission is not excluded. - -The J2EE 1.4 container calls Policy.implies with two arguments; the -WebUserDataPermission and an argument ProtectionDomain that was -constructed without static permissions and that need not be constructed with -principals. The checked permission is excluded if Policy.implies returns false. -Otherwise, the permission is not excluded. - -The J2EE 1.4 container calls -java.security.Policy.getPermissions with an argument -ProtectionDomain that must be constructed without static permissions and that -need not be constructed with principals. The container must call the implies -method on the returned PermissionCollection using the permission being -checked as argument. The checked permission is excluded if the -PermissionCollection does not imply it. Otherwise, the permission is not -excluded. This technique is supported but not recommended. - -The J2EE 1.3 container calls -javax.security.auth.Policy.getPermissions to determine the -collection of permissions granted independent of access control context. The -Subject argument in the call to getPermissions may be null. The container -must call the impliesmethod on the returned PermissionCollection using the -permission being checked as argument. The checked permission is excluded if -the PermissionCollection does not imply it. Otherwise, the permission is not -excluded. This technique is supported but not recommended. -Prior to using any of the techniques described in this section, the container -must have established a policy context identifier as defined in Section 4.6, -Setting the Policy Context. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10344.8A container must determine if the caller has been granted a permission by -evaluating the permission in the context of an AccessControlContext, -ProtectionDomain, or Subject containing the principals of (only) the caller. If the -caller's identity has been asserted or vouched for by a trusted authority (other than -the caller), the principals of the authority must not be included in the principals of -the caller. -A container must use one of the following techniques to determine if a -permission has been granted to the caller. - -The container calls AccessControlContext.checkPermission with -the permission as argument. The call to checkPermission must be made on -an AccessControlContext that contains the principals of the caller. If -checkPermission throws an AccessControlException, the permission is not -granted to the caller. Otherwise the permission is granted. - -The container calls AccessController.checkPermission with the -permission as argument. The AccessControlContext associated with the thread -on which the call to checkPermission is made must contain the principals -of the caller. If checkPermission throws an AccessControlException, the -permission is not granted to the caller. Otherwise the permission is granted. - -The container calls SecurityManager.checkPermission with the -permission as argument. The AccessControlContext associated with the thread -on which the call to checkPermission is made must contain the principals -of the caller. If checkPermission throws an AccessControlException, the -permission is not granted to the caller. Otherwise the permission is granted. - -The J2EE 1.4 container calls Policy.implies with two arguments; the -permission being checked and a ProtectionDomain constructed with the -principals of the caller. The boolean result returned by Policy.implies -indicates whether or not the permission has been granted to the caller. - -The J2EE 1.4 container calls -java.security.Policy.getPermissions with an argument -ProtectionDomain that was constructed with the principals of the caller. The -container must call the implies method on the returned -PermissionCollection using the permission being checked as argument. If the -PermissionCollection implies the permission being tested, the permission has -been granted to the caller. Otherwise it has not. This technique is supported but -not recommended. - -The J2EE 1.3 container calls -javax.security.auth.Policy.getPermissions with an argument -Subject containing the principals of the caller.The container must call the -implies method on the returned PermissionCollection using the permission -being checked as argument. If the PermissionCollection implies the permission -being tested, the permission has been granted to the caller. Otherwise it has not. -This technique is supported but not recommended. -Prior to using any of the techniques described in this section, the container -must have established a policy context identifier as defined in Section 4.6, -Setting the Policy Context. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10644.11To be compatible with this contract, all of the JRE’s of a J2EE 1.4 application -server must perform all of the policy decisions defined by this contract by -interacting with the java.security.Policy instance available in the JRE -via the java.security.Policy.getPolicy method. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10744.11All of the JRE’s of a -J2EE 1.3 application server must perform all of the policy decisions defined by -this contract by interacting with the javax.security.auth.Policy instance -available in the JRE via the jakarta.security.auth.getPolicy method. - false -
    -
    falsetechnologyactivetrue
    provider assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:411.4Each Policy provider that satisfies this contract must perform or -delegate to another provider all the permission evaluations -requested via its interface in the JRE; not just those made by the -container to implement J2EE security functionality. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:611.4Each provider must export interfaces (defined by this contract) for - use by containers and or container deployment tools to create policy - statements within the policy store of the provider. These interfaces - must be used when an application or module is deployed in a - container. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:711.4Each provider must satisfy all of the authorization requirements of - the EJB and Servlet specifications corresponding to the target - platform. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:811.4In the case of Servlet resources, the provider must be able to - associate a distinct policy context with each context root - (including context roots created to support virtual hosting) - hosted by the server. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:911.4In protecting Servlet resources, a provider must select the -constraints that apply to a resource according to the "best-match" -constraint matching rules defined by this specification and the -servlet mapping rules defined by the Servlet specification. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1622.5If the provider is seeking to replace the Policy implementation used by the -JRE, then the JRE must be provided with an environment specific Policy -implementation class. If the JRE is running a J2SE 1.4 security environment, then -it must be provided with an implementation of the java.security.Policy -class. If the JRE is running a J2SE 1.3 security environment, it must be provided -with an implementation of the javax.security.auth.Policy class (that is, -a JAAS Policy object). - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:1722.5A replacement Policy object must assume responsibility for performing all -policy decisions within the JRE in which it is installed that are requested by way -of the Policy interface that it implements. A replacement Policy object may -accomplish this by delegating non-jakarta.security.jacc policy decisions to -the corresponding default system Policy implementation class. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1822.5A replacement -Policy object that relies in this way on the corresponding default Policy -implementation class must identify itself in its installation instructions as a -“delegating Policy provider”. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:1922.5The standard security properties mechanism for replacing a default system -Policy implementation (see Section 2.1, “Policy Implementation Class) should -not be used to replace a default system Policy provider with a delegating policy -provider. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:2022.6A J2SE 1.4 provider may support replacement of -the JAAS Policy object if and only if all jakarta.security.jacc policy decisions -performed by the replacement JAAS Policy object return the same result as when -the java.security.Policy interface is used. To satisfy this requirement, the -replacement JAAS policy object must be compatible with the implementations of -PolicyConfigurationFactory and PolicyConfiguration interface -provided for use with the java.security.Policy implementation class. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6333.2the provider must include an implementation of the -jakarta.security.jacc.PolicyConfigurationFactory class along -with a matched implementation of a class that implements the -jakarta.security.jacc.PolicyConfiguration interface. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6433.2In addition to -providing a PolicyConfiguration interface for integration with the -application server’s deployment tools, the provider must also include a -management interface for policy administrators to use to grant the collections of -permissions that comprise roles, to principals. This interface need not be -standardized. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:6533.2The provider must ensure that all of the permissions added to a role in a policy -configuration context are granted to any principal mapped to the role by the policy -administrator. The provider must ensure that the same principal-to-role mappings -are applied to all linked policy configuration contexts. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6633.2The provider must ensure that excluded policy statements take precedence -over overlapping unchecked policy statements, and that both excluded and -unchecked policy statements take precedence over overlapping role based policy -statements. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6733.3The getPolicyConfigurationFactory, and contains methods of the -abstract factory class, -jakarta.security.jacc.PolicyConfigurationFactory, must throw a -SecurityException when called by an AccessControlContext that has not been -granted the “getPolicy” SecurityPermission. -The getPolicyConfiguration method of all implementations of the -PolicyConfigurationFactory abstract class must throw a -SecurityException when called by an AccessControlContext that has not been -granted the “setPolicy” SecurityPermission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6833.3All of the public methods of all of the concrete implementations of the -PolicyConfiguration interface must throw a SecurityException when called -by an AccessControlContext that has not been granted the “setPolicy” -SecurityPermission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6933.3In cases where a required permission is not held by a caller, the -implementation must return without changing the state of the policy statement -repository. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:7033.3The containers of an application server must be granted the “getPolicy” -SecurityPermission and the “setPolicy” SecurityPermission. J2EE 1.3 Containers -that choose to support this contract must be granted the “getPolicy” -AuthPermission and the “setPolicy” AuthPermission. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:8544.4.1The policy statements of the PolicyConfiguration identified by calling the -getContextID method on the PolicyContext utility class must be tested to -determine if they match the permission being evaluated. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8644.4.1If one or more excluded -policy statements match the checked permission, the evaluation may terminate -and the checked permission must be determined not to be granted. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8744.4.1 if one or more unchecked policy statements match the checked permission, the -checked permission must be determined to be granted independent of access -control context. If neither of the excluded or unchecked comparisons yield a -match, then the access control context may only be determined to have been -granted the checked permission if a matching permission has been accorded to the -access control context. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8844.4.2An excluded or unchecked policy statement matches a checked permission if the -policy statement satisfies the rules for matching a granted permission to the -checked permission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:8944.4.2A granted EJBMethodPermission matches a checked EJBMethodPermission -if their names are equivalent, and if the method specification in the actions of the -granted permission matches the method specification in the actions of the checked -permission (as described in the definition of the EJBMethodPermission class). - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9044.4.2One or more granted EJBRoleRefPermission objects match a checked -EJBRoleRefPermission if their names and actions are equivalent to the name of -the checked permission. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9244.5When a Deployer configures an environment specific component identity -based on a deployment descriptor specification that the component run with an -identity mapped to a role, those responsible for defining the principal-to-role -mapping must ensure that the specified identity is mapped to the role. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:9344.5A container establishes a component’s runAs identity by associating an -AccessControlContext with the component’s thread of execution. A component’s -container must protect the AccessControlContext associated with a running -component such that, by default, the component is not granted permissions -sufficient to modify the AccessControlContext. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:10444.9A policy provider must return that a tested permission has not been granted if it -acquires a non-null policy context identifier by calling getContextID on the -PolicyContext class and the contains method of the -PolicyConfigurationFactory associated with the provider would return -false if called with the policy context identifier. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:10544.10A policy module must consult the default policy context if the policy context -identifier it acquires by calling getContextID on the PolicyContext class is the null -value, or when the result of its permission decision in the indicated policy context -is neither granted or explicitly excluded. -The default policy context contains the policy statements that apply to the -JRE independent of the policy configurations defined as the result of the -deployment of modules or applications in containers. In the typical policy -delegation scenario, the default policy context will be encapsulated in a policy -module to which non-jakarta.security.jacc policy decisions are delegated. - true -
    -
    falsetechnologyactivetrue
    tools assertions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
    JACC:SPEC:2533.1The getPolicyConfigurationFactory method must be used in the -containers to which the components of the application or module are being -deployed to find or instantiate PolicyConfigurationFactory objects. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2633.1The getPolicyConfiguration method of the factory must be used to -find or instantiate PolicyConfiguration objects corresponding to the -application or modules being deployed. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2733.1The declarative authorization policy statements derived from application or -module deployment descriptor(s) must be translated to create instances of the -corresponding jakarta.security.jacc Permission classes. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2833.1Methods of the PolicyConfiguration interface must be used with the -permissions resulting from the translation to create policy statements within the -PolicyConfiguration objects. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:2933.1The PolicyConfiguration objects must be linked such that the same -principal-to-role mapping will be applied to all the modules of the application. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3033.1Independent of this specification, J2EE deployment tools must translate and -complete the declarative policy statements appearing in deployment descriptors -into a form suitable for securing applications on the platform. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3133.1.1.1Same application policy contexts must be associated by -calling the PolicyConfiguration.linkConfiguration method. This -method must create a transitive and symmetric relationship within the provider -and between this PolicyConfiguration and the argument -PolicyConfiguration, such that they and all PolicyConfiguration objects -otherwise linked to either of them share the same principal-to-role mappings. The -semantics of the association must preserve the invariant that at most one principalto- -role mapping may apply to any PolicyConfiguration. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3333.1.3A reference to a PolicyConfiguration object must be obtained by calling the -getPolicyConfiguration method on the -PolicyConfigurationFactory implementation class of the provider -configured into the container. The policy context identifier used in the call to the -getPolicyConfiguration method must be a String composed as -described in Section 3.1.2, “Servlet Policy Context Identifiers,” on page 17. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3433.1.3.1For each security-constraint element that contains an authconstraint -element, a WebResourcePermission must be instantiated for each -value in the cross-product of url-pattern (from a web-resourcecollection -within the security-constraint) and role-name appearing -in the auth-constraint. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3533.1.3.1If the reserved role-name, “*”, occurs as a rolename -in the constraint, the cross product must be computed using all the roles -defined in the web application. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3633.1.3.1The WebResourcePermission objects must be -constructed using the url-pattern as their name and with actions defined by -the union of the HTTP methods from all the collections that contained the urlpattern -within the security-constraint. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3733.1.3.1Each permission constructed for -a combination of url-pattern and role must be added to the corresponding -role by calling the addToRole method on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3833.1.3.1When a security-constraint does not contain an authconstraint, -or it contains an auth-constraint that contains no role names, -aWebResourcePermission must be instantiated (with arguments as defined above) -for each different url-pattern appearing in the collections within the -security-constraint. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:3933.1.3.1The WebResourcePermission objects resulting from -the translation of a security-constraint that does not contain an authconstraint -must be added to the unchecked policy statements by calling -addToUncheckedPolicy on the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4033.1.3.1The -WebResourcePermission objects resulting from the translation of a securityconstraint -containing an auth-constraint that named no roles must be -added to the excluded policy statements by calling addToExcludedPolicy on -the PolicyConfiguration object. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4133.1.3.1For each security-constraint element in the deployment descriptor, a -WebUserDataPermission must be instantiated for each different url-pattern -appearing in the web-resource-collection elements within the security-constraint. - -TheWebUserDataPermission objects must be constructed using a url-pattern -as their name and with actions defined by concatenating a representation of the -unacceptable transport guarantees to the union of the HTTP methods from the -contained collections that contained the url-pattern. - -The WebUserDataPermission objects resulting from the translation must be added to -the excluded policy statements by calling addToExcludedPolicy on the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4233.1.3.1A transport-guarantee (in a user-data-constraint) of -NONE, or a security-constraint without a user-dataconstraint, -indicates that the associated URL patterns and HTTP methods -may be accessed over any (including an unprotected) transport. - -A transport-guarantee of INTEGRAL indicates that transport connections deemed by the -container to be unprotected or confidentiality only protected are unacceptable. - - A transport-guarantee of CONFIDENTIAL indicates that transport -connections that the container considers to be unprotected or integrity only -protected are unacceptable. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4333.1.3.2For each security-role-ref appearing in the deployment descriptor a -corresponding WebRoleRefPermission must be created. The name used in the -construction of each WebRoleRefPermission must be the servlet-name in -whose context the security-role-ref is defined. The actions used to -construct the permission must be the value of the role-name (that is the -reference), appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4433.1.3.2The deployment tools must call the addToRole method on the - PolicyConfiguration object to add the WebRoleRefPermission object - resulting from the translation to the role identified in the role-link - appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4533.1.3.2For each servlet element in the deployment descriptor a WebRoleRefPermission must -be created for each security-role whose name does not appear as the rolename -in a security-role-ref within the servlet element. Each such -WebRoleRefPermission must be created with action (that is, reference) -corresponding to the role-name and added to the role with the same name (as -the reference) by calling the addToRole method on the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4633.1.4an application server must establish EJB policy -context identifiers sufficient to differentiate all instances of the deployment of an -EJB jar on the application server, or on any other application server with which -the server may share the same policy statement repository. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4733.1.5.1An EJBMethodPermission object must be created for each role-name or -unchecked element contained in each method-permission element -appearing in the deployment descriptor. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4833.1.5.1The name of each EJBMethodPermission -must be the ejb-name as defined in the method element of the methodpermission -element. The actions used in the permission construction must be -obtained by translating the contents of the method element into a method -specification according to the methodSpec syntax defined in the documentation of -the EJBMethodPermission class. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:4933.1.5.1If the method-permission element contains the unchecked element, -then the deployment tools must call the addToUncheckedPolicy method to -add the permission resulting from the translation to the -PolicyConfiguration object. - -Alternatively, if the method-permission -element contains one or more role-name elements, then the deployment tools -must call the addToRole method to add each of the permissions resulting from -the translation to the corresponding role of the PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5033.1.5.2An EJBMethodPermission object must be created for each method element -occurring in the exclude-list element of the deployment descriptor. The -name and actions of each EJBMethodPermission must be established as described -in Section 3.1.5.1, “Translating EJB method-permission Elements.” -The deployment tools must create excluded policy statements in the provider -by calling the addToExcludedPolicy method on the -PolicyConfiguration object. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5133.1.5.3For each security-role-ref element appearing in the deployment -descriptor, a corresponding EJBRoleRefPermission must be created. The name of -each EJBRoleRefPermission must be obtained as described for -EJBMethodPermission objects. The actions used to construct the permission must -be the value of the role-name (that is the reference), appearing in the -security-role-ref. The deployment tools must call the addToRole -method on the PolicyConfiguration object to add a policy statement -corresponding to the EJBRoleRefPermission to the role identified in the rolelink -appearing in the security-role-ref. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5233.1.6The server’s deployment tools must translate the declarative authorization policy -appearing in the application or module deployment descriptor(s) into policy -statements within the Policy objects used by the containers to which the -components of the application or module are being deployed. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5333.1.6When a module is deployed, it must be linked to the -PolicyConfiguration object of any other module with which it must share -the same principal-to-role mapping. When an application is deployed, the -PolicyConfiguration objects corresponding to all the modules of the -application must be linked. PolicyConfiguration objects are linked by calling the -linkConfiguration method of the PolicyConfiguration interface. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5433.1.6Once the translation is complete, a call must be made to Policy.refresh -on the Policy object used by each of the containers to which the application or -module is being deployed. The calls to Policy.refresh must occur before the -containers will accept requests for the deployed resources, but may be deferred -until after principal-to-role mapping. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5533.1.6The policy context identifiers corresponding to the deployed application or -module must be recorded in the application server so that they can be used by -containers to establish the policy context as required by Section 4.6, “Setting the -Policy Context” of the Policy Decision and Enforcement Subcontract, and such -that the Deployer may subsequently remove or modify the corresponding policy -configuration as a result of the undeployment or redeployment of the application. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5633.1.7When undeploying an application or module, the deployment tools must call the -delete method on the PolicyConfiguration objects associated with the -modules of the application and associated with the provider of each container to -which one or more modules of the application have been deployed. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5733.1.7To ensure that -there is not a period during undeployment when the removal of policy statements -on application components renders what were protected components unprotected, -the application server must stop accepting requests for the application’s -components before the policy statements are deleted. - true -
    -
    falsetechnologyactivetrue
    JACC:SPEC:5833.1.7After the policy statements -are removed a call must be made to Policy.refresh on the Policy object used -by each of the containers from which at least one module of the application was -undeployed. - true -
    -
    falsetechnologyactivefalse
    JACC:SPEC:5933.1.7To facilitate redeployment to an existing policy configuration, container -deployment tools may also support a mode in which they do not delete the -PolicyConfiguration objects associated with the application or module -being undeployed. - false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:6033.1.8Containers are not required to deploy to an existing policy configuration. - -To associate an application or module with an existing set of linked -PolicyConfiguration objects, the policy context identifiers of the existing -objects must be applied by the relevant containers in fulfilling their obligations as -defined in the Policy Decision and Enforcement Subcontract. The pre-existing -PolicyConfiguration objects may be verified for existence, by calling the -contains method of the PolicyConfigurationFactory with the policy -context identifiers corresponding to the PolicyConfiguration objects. - false -
    -
    falsetechnologyactivetrue
    JACC:SPEC:6133.1.9Containers are not required to implement redeployment functionality.false -
    -
    falsetechnologyactivefalse
    JACC:SPEC:6233.1.9To ensure redeployment does not create a situation where the removal of -policy statements on application components renders what were protected -components unprotected, the application server must stop accepting requests for -the application's components before redeployment begins. - -To redeploy a module, the deployment tools must call the delete method on the module's -PolicyConfiguration object in the provider associated with each of the -containers to which the module has been deployed. - -The deployment tools must translate the declarative authorization policy appearing in the module's -deployment descriptor into a PolicyConfiguration object (that may or may -not have the same policy context identifier as the deleted objects). - -The translation must include linking the new PolicyConfiguration object to the -PolicyConfiguration object of any other module with which the module -must share its principal-to-role mappings. - -After the translation and reconfiguration of policy is complete a call must be -made to Policy.refresh on the Policy object used by each of the containers to -which the module has been redeployed. - false -
    -
    falsetechnologyactivetrue
    - - diff --git a/internal/docs/jakartaee/JavaEESpecAssertions.xml b/internal/docs/jakartaee/JavaEESpecAssertions.xml index 5edfe4c54c..3f04ad4650 100644 --- a/internal/docs/jakartaee/JavaEESpecAssertions.xml +++ b/internal/docs/jakartaee/JavaEESpecAssertions.xml @@ -282,9 +282,6 @@
    -
    -
    -
    diff --git a/jacc/pom.xml b/jacc/pom.xml deleted file mode 100644 index b81e9bc391..0000000000 --- a/jacc/pom.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - 4.0.0 - - - jakarta.tck - project - 11.0.0-SNAPSHOT - - - jacc - jar - - jacc - jacc - - - - ${project.groupId} - libutil - - - ${project.groupId} - common - - - ${project.groupId} - ejb30 - - - javatest - javatest - - - jakarta.ejb - jakarta.ejb-api - - - jakarta.authorization - jakarta.authorization-api - - - jakarta.annotation - jakarta.annotation-api - - - - - - - maven-deploy-plugin - - true - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/build.xml deleted file mode 100644 index e579a07825..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/build.xml +++ /dev/null @@ -1,22 +0,0 @@ - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/build.xml deleted file mode 100644 index d35d8755fe..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/build.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/Client.java b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/Client.java deleted file mode 100644 index d3fb439d83..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/Client.java +++ /dev/null @@ -1,449 +0,0 @@ -/* - * Copyright (c) 2013, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.ejb.methodperm; - -import java.security.Permissions; -import java.util.Collection; -import java.util.Iterator; -import java.util.NoSuchElementException; -import java.util.Properties; -import java.util.StringTokenizer; - -import com.sun.javatest.Status; -import com.sun.ts.lib.harness.EETest; -import com.sun.ts.lib.util.TestUtil; -import com.sun.ts.tests.jacc.util.LogFileProcessor; -import com.sun.ts.tests.jacc.util.LogRecordEntry; - -import jakarta.security.jacc.EJBMethodPermission; -import jakarta.security.jacc.EJBRoleRefPermission; - -// CAUTION: *** The expected permissions constructed for various permissions -// such as WebResourcePermission, WebRoleRefPermission, -// WebUserDataPermission are based on the application -// jacc_ejb_methodperm. If the application is modified for -// any reason then the expected permissions should also be -// modified accordingly. *** -// -public class Client extends EETest { - - private Properties props = null; - - private String contextId = "jacc_ctx"; - - LogFileProcessor logProcessor = null; - - private String applicationContext; - - private boolean initialized = false; - - private Permissions unCheckedPermissions = new Permissions(); - - private Permissions excludedPermissions = new Permissions(); - - private Permissions addToRolePermissions = new Permissions(); - - public static void main(String args[]) { - Client theTests = new Client(); - Status s = theTests.run(args, System.out, System.err); - s.exit(); - } - - /** - * @class.setup_props: log.file.location; webServerHost; webServerPort; - * - * - */ - public void setup(String[] args, Properties p) throws Exception { - props = p; - if (!initialized) { - // create LogFileProcessor - logProcessor = new LogFileProcessor(props); - - // retrieve logs based on application Name - logProcessor.fetchLogs("getAppSpecificRecordCollection|appId", - "jacc_ejb_methodperm"); - - // retrieve unchecked permissions as a permission collection - unCheckedPermissions = logProcessor.getAppSpecificUnCheckedPermissions(); - - // retrieve excluded permissions as a permission collection - excludedPermissions = logProcessor.getAppSpecificExcludedPermissions(); - - // retrieve addToRole permissions as a permission collection - addToRolePermissions = logProcessor.getAppSpecificAddToRolePermissions(); - - initialized = true; - } - } - - public void cleanup() throws Exception { - - } - - /** - * @testName: EJBMethodPermissionTest - * - * @assertion_ids: JACC:SPEC:27; JACC:SPEC:28; JACC:SPEC:48; JACC:SPEC:47; - * JACC:SPEC:81; - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy the application. - * - * 3. During deployment, appserver generates permissions for - * the J2EE components based on the given deployment - * descriptor - * - * 4. Retrieve server side logs and verify the generated - * permissions matches the expected permission collection - * - */ - public void EJBMethodPermissionTest() throws Exception { - boolean verified = false; - Permissions expectedAddToRolePermissions = new Permissions(); - - // 1) retrieve server generated policy statements - // 2) construct our expected policy statements - // 3) verify expected policy statements with generated policy statements - - // step 1: retrieve server generated unchecked policy statements - // Get "addToRole" WebResourcePermissions - Permissions addToRoleEJBMethodPermissions = logProcessor - .getSpecificPermissions(addToRolePermissions, "EJBMethodPermission"); - - TestUtil.logMsg("Server generated addToRole EJBMethodPermissions"); - logProcessor.printPermissionCollection(addToRoleEJBMethodPermissions); - - // step 2: construct our expected addToRole policy statements - // Construct the expected addToRole EJBMethodPermissions - String[] params = {}; - expectedAddToRolePermissions - .add(new EJBMethodPermission("jacc_ejb_methodperm_MethodPermBean", - "protectedByRoleManager", "Remote", params)); - expectedAddToRolePermissions - .add(new EJBMethodPermission("jacc_ejb_methodperm_MethodPermBean", - "protectedByRoleAdminAndManager", "Remote", params)); - expectedAddToRolePermissions - .add(new EJBMethodPermission("jacc_ejb_methodperm_MethodPermBean", - "protectedByAnyAuthUser", "Remote", params)); - - // step 3: verify expected policy statements with generated policy - // statements - TestUtil.logMsg("verifying unchecked policy statments:"); - verified = logProcessor.verifyLogImplies(expectedAddToRolePermissions, - addToRoleEJBMethodPermissions); - - if (!verified) { - throw new Exception("EJBMethodPermissionTest failed: " - + "addToRole policy statements verification failed"); - } else { - TestUtil.logMsg("addToRole policy statements verification successful"); - } - } - - /** - * @testName: EJBMethodPermissionAddToRole - * - * @assertion_ids: JACC:SPEC:27; JACC:SPEC:28; JACC:SPEC:48; JACC:SPEC:49; - * JACC:SPEC:134; - * - * @test_Strategy: This will test JACC (v1.5) spec section 3.1.5.1 statement - * that addToRole must be called for each role-name that - * exists within method-permission. (addToRole MAY be called - * for the "**" role) - * - */ - public void EJBMethodPermissionAddToRole() throws Exception { - boolean bManagerFound = false; - boolean bAdminFound = false; - - // 1) retrieve server generated (MSG_TAG) addToRole calls - // 2) sanitize the calls so we are left with ONLY EJBMethodPermission calls - // 3) see if we are calling addToRole for Administrator and Manager - - // step 1: retrieve server generated addToRole calls - Collection records = logProcessor - .getMsgTagRecordCollection(); - - // step 2: sanitize the calls so we are left with ONLY EJBMethodPermission - // calls - Iterator iterator = records.iterator(); - while (iterator.hasNext()) { - LogRecordEntry recordEntry = (LogRecordEntry) iterator.next(); - - // Get permission type (hint, we want EJBMethodPermission) - // the format of a MSG_TAG entry in the jacc logfile is as follows: - // MSG_TAG :: :: :: :: - // - String message = recordEntry.getMessage(); - String permType = null; - String roleName = null; - String appContext = null; - String permName = null; - - try { - StringTokenizer tokens = new StringTokenizer(message, " :: "); - if (message.indexOf(" :: ") > 0) { - tokens.nextToken(); // get rid of MSG_TAG - permType = tokens.nextToken(); // permission type - TestUtil.logTrace( - "EJBMethodPermissionAddToRole: permType = " + permType); - - if ((permType != null) && (permType.equals("EJBMethodPermission"))) { - roleName = tokens.nextToken(); // get role-name - appContext = tokens.nextToken(); // app-context - permName = tokens.nextToken(); // permission name - TestUtil.logTrace("roleName = " + roleName); - TestUtil.logTrace("appContext = " + appContext); - TestUtil.logTrace("permName = " + permName); - - if ((permName != null) - && (permName.equals("jacc_ejb_methodperm_MethodPermBean"))) { - if ((roleName != null) && (roleName.equals("Manager"))) { - bManagerFound = true; - } else if ((roleName != null) - && (roleName.equals("Administrator"))) { - bAdminFound = true; - } else if ((roleName != null) && (roleName.equals("**"))) { - // this is optional for the any-authenticated-role named "**" - // (per spec) so log for information purposes only - TestUtil.logMsg( - "EJBMethodPermission addToRole called for role '**'"); - } - if (bManagerFound && bAdminFound) { - // we are done so bail - TestUtil.logMsg("bManagerFound && bAdminFound so breaking"); - break; - } - } - } - } - } catch (NoSuchElementException ex) { - // invalid MSG_TAG - try next one - TestUtil - .logMsg("Invalid MSG_TAG entry found in jacc log file: " + message); - TestUtil.logMsg(ex.getMessage()); - iterator.next(); - } - - } // while iterator.hasNext - - // step 3: see if we are calling addToRole for Administrator and Manager - TestUtil.logMsg("verifying addToRole policy statments:"); - - if (bAdminFound && bManagerFound) { - TestUtil.logMsg( - "addToRole called for method-permission roles: Administrator and Manager."); - } else { - throw new Exception("EJBMethodPermissionAddToRole failed: " - + "addToRole policy statements verification failed"); - } - - } - - /** - * @testName: EJBRoleRefPermission - * - * @assertion_ids: JACC:SPEC:135; JACC:SPEC:51; JACC:SPEC:52; JACC:SPEC:27; - * JACC:SPEC:28; - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). 2. - * Deploy the application. - * - * 3. During deployment, appserver generates permissions for - * the J2EE components based on the given deployment - * descriptor - * - * 4. Retrieve server side logs and verify the generated - * permissions matches the expected permission collection - */ - public void EJBRoleRefPermission() throws Exception { - boolean verified = false; - Permissions expectedAddToRolePermissions = new Permissions(); - - // ---------ADDTOROLE----------// - // 1) retrieve server generated addToRole policy statements - // 2) construct expected addToRole policy statements - // 3) verify expected policy statements with generated policy statements - - // Get "addToRole" WebRoleRefPermissions - Permissions addToRoleEJBRoleRefPermissions = logProcessor - .getSpecificPermissions(addToRolePermissions, "EJBRoleRefPermission"); - - TestUtil.logMsg("Server generated addToRole EJBRoleRefPermissions"); - logProcessor.printPermissionCollection(addToRoleEJBRoleRefPermissions); - - // Construct the expected excluded EJBRoleRefPermission - expectedAddToRolePermissions.add(new EJBRoleRefPermission( - "jacc_ejb_methodperm_MethodPermBean", "ADMIN")); - expectedAddToRolePermissions.add(new EJBRoleRefPermission( - "jacc_ejb_methodperm_MethodPermBean", "Administrator")); - expectedAddToRolePermissions.add( - new EJBRoleRefPermission("jacc_ejb_methodperm_MethodPermBean", "MGR")); - expectedAddToRolePermissions.add(new EJBRoleRefPermission( - "jacc_ejb_methodperm_MethodPermBean", "Manager")); - expectedAddToRolePermissions.add( - new EJBRoleRefPermission("jacc_ejb_methodperm_MethodPermBean", "EMP")); - expectedAddToRolePermissions.add(new EJBRoleRefPermission( - "jacc_ejb_methodperm_MethodPermBean", "Employee")); - expectedAddToRolePermissions.add( - new EJBRoleRefPermission("jacc_ejb_methodperm_MethodPermBean", "**")); - - TestUtil.logMsg("verifying addToRole policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedAddToRolePermissions, - addToRoleEJBRoleRefPermissions); - - if (!verified) { - throw new Exception("EJBRoleRefPermission failed: " - + "addToRole policy statements verification failed"); - } else { - TestUtil.logMsg("addToRole policy statements verification successful"); - } - } - - /** - * @testName: EJBMethodPermissionEquals - * - * @assertion_ids: JACC:JAVADOC:4; - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of EJBMethodPermission.equals() - * - * - */ - public void EJBMethodPermissionEquals() throws Exception { - boolean verified = false; - - String tempArgs[] = { "EJBMethodPermission.equals() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("EJBMethodPermissionEquals : FAILED"); - } else { - TestUtil.logMsg("EJBMethodPermissionEquals : PASSED"); - } - } - - /** - * @testName: EJBRoleRefPermissionEquals - * - * @assertion_ids: JACC:JAVADOC:9; - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of EJBRoleRefPermission.equals() - * - * - */ - public void EJBRoleRefPermissionEquals() throws Exception { - boolean verified = false; - - String tempArgs[] = { "EJBRoleRefPermission.equals() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("EJBRoleRefPermissionEquals : FAILED"); - } else { - TestUtil.logMsg("EJBRoleRefPermissionEquals : PASSED"); - } - } - - /** - * @testName: EJBMethodPermissionHashCode - * - * @assertion_ids: JACC:JAVADOC:6; - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of EJBMethodPermission.hashCode() - * - */ - public void EJBMethodPermissionHashCode() throws Exception { - boolean verified = false; - - String tempArgs[] = { "EJBMethodPermission.hashCode() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("EJBMethodPermissionHashCode : FAILED"); - } else { - TestUtil.logMsg("EJBMethodPermissionHashCode : PASSED"); - } - } - - /** - * @testName: EJBRoleRefPermissionHashCode - * - * @assertion_ids: JACC:JAVADOC:11; - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of EJBRoleRefPermission.hashCode() - * - * - */ - public void EJBRoleRefPermissionHashCode() throws Exception { - boolean verified = false; - - String tempArgs[] = { "EJBRoleRefPermission.hashCode() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("EJBRoleRefPermissionHashCode : FAILED"); - } else { - TestUtil.logMsg("EJBRoleRefPermissionHashCode : PASSED"); - } - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/MethodPermBean.java b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/MethodPermBean.java deleted file mode 100644 index 984bec8f4d..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/MethodPermBean.java +++ /dev/null @@ -1,131 +0,0 @@ -/* - * Copyright (c) 2013, 2018, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.ejb.methodperm; - -import java.security.AccessControlException; - -import com.sun.ts.lib.util.TestUtil; - -import jakarta.ejb.Remote; -import jakarta.ejb.Stateful; - -@Stateful(name = "jacc_ejb_methodperm_MethodPermBean") -@Remote({ MethodPermInterface.class }) -public class MethodPermBean implements MethodPermInterface { - - /* - * - */ - public boolean protectedByRoleManager() { - boolean rval = false; // assume fail - - debug("Enterred: MethodPermBean.protectedByRoleManager()."); - - try { - - // XXXX: this is a placeholder methoid thats not called - - debug("SUCCESS: protectedByRoleManager passed."); - rval = true; - } catch (AccessControlException ex) { - debug( - "FAILURE: protectedByRoleManager throwing AccessControlException."); - ex.printStackTrace(); - return false; - } catch (Exception ex) { - debug( - "FAILURE: protectedByRoleManager(), throwing unexpected Exception."); - ex.printStackTrace(); - return false; - } - - debug( - "Leaving MethodPermBean.protectedByRoleManager() with rval = " + rval); - - return rval; - } - - /* - * - */ - public boolean protectedByRoleAdminAndManager() { - boolean rval = false; // assume fail - - debug("Enterred: MethodPermBean.protectedByRoleAdminAndManager()."); - - try { - - // XXXX: this is a placeholder methoid thats not called - - debug("SUCCESS: protectedByRoleAdminAndManager passed."); - rval = true; - } catch (AccessControlException ex) { - debug( - "FAILURE: protectedByRoleAdminAndManager throwing AccessControlException."); - ex.printStackTrace(); - return false; - } catch (Exception ex) { - debug( - "FAILURE: protectedByRoleAdminAndManager(), throwing unexpected Exception."); - ex.printStackTrace(); - return false; - } - - debug("Leaving MethodPermBean.protectedByRoleAdminAndManager() with rval = " - + rval); - - return rval; - } - - /* - * - */ - public boolean protectedByAnyAuthUser() { - boolean rval = false; // assume fail - - debug("Enterred: MethodPermBean.protectedByAnyAuthUser()."); - - try { - - // XXXX: this is a placeholder methoid thats not called - - debug("SUCCESS: protectedByAnyAuthUser passed."); - rval = true; - } catch (AccessControlException ex) { - debug( - "FAILURE: protectedByAnyAuthUser throwing AccessControlException."); - ex.printStackTrace(); - return false; - } catch (Exception ex) { - debug( - "FAILURE: protectedByAnyAuthUser(), throwing unexpected Exception."); - ex.printStackTrace(); - return false; - } - - debug( - "Leaving MethodPermBean.protectedByAnyAuthUser() with rval = " + rval); - - return rval; - } - - private void debug(String str) { - System.out.println(str); - TestUtil.logMsg(str); - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/MethodPermInterface.java b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/MethodPermInterface.java deleted file mode 100644 index f95e4a9757..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/MethodPermInterface.java +++ /dev/null @@ -1,25 +0,0 @@ -/* - * Copyright (c) 2013, 2018 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.ejb.methodperm; - -public interface MethodPermInterface { - public boolean protectedByRoleManager(); - - public boolean protectedByRoleAdminAndManager(); - - public boolean protectedByAnyAuthUser(); -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/build.xml deleted file mode 100644 index b68ad1f020..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/build.xml +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/ejb3_sec_permsxml.ear.sun-application.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/ejb3_sec_permsxml.ear.sun-application.xml deleted file mode 100644 index 8701d42630..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/ejb3_sec_permsxml.ear.sun-application.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - 0 - - Administrator - j2ee - - - Manager - javajoe - - - Employee - javajoe - j2ee - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_client.jar.sun-application-client.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_client.jar.sun-application-client.xml deleted file mode 100644 index fd11833fd1..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_client.jar.sun-application-client.xml +++ /dev/null @@ -1,26 +0,0 @@ - - - - - - - ejb/jacc_ejb_methodperm_MethodPermBean - jacc_ejb_methodperm_MethodPermBean - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_client.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_client.xml deleted file mode 100644 index 718b667f52..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_client.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - - - jacc_ejb_methodperm_MethodPermBean_client - - ejb/jacc_ejb_methodperm_MethodPermBean - Session - com.sun.ts.tests.jacc.ejb.methodperm.MethodPermInterface - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_ejb.jar.sun-ejb-jar.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_ejb.jar.sun-ejb-jar.xml deleted file mode 100644 index 0dcc6a5065..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_ejb.jar.sun-ejb-jar.xml +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - - Administrator - j2ee - - - Manager - javajoe - - - Employee - javajoe - j2ee - - - 0 - - jacc_ejb_methodperm_MethodPermBean - jacc_ejb_methodperm_MethodPermBean - false - - j2ee - - false - -1 - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_ejb.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_ejb.xml deleted file mode 100644 index abde273083..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/methodperm/jacc_ejb_methodperm_ejb.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - XXXMethodPermBean - - - jacc_ejb_methodperm_MethodPermBean - com.sun.ts.tests.jacc.ejb.methodperm.MethodPermInterface - com.sun.ts.tests.jacc.ejb.methodperm.MethodPermBean - - ADMIN - Administrator - - - MGR - Manager - - - EMP - Employee - - - - - - - - - Administrator - - - Manager - - - Employee - - - Administrator - Manager - - jacc_ejb_methodperm_MethodPermBean - Remote - protectedByRoleAdminAndManager - - - - Manager - - jacc_ejb_methodperm_MethodPermBean - Remote - protectedByRoleManager - - - - ** - - jacc_ejb_methodperm_MethodPermBean - Remote - protectedByAnyAuthUser - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/Client.java b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/Client.java deleted file mode 100644 index 53f0a3d8e3..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/Client.java +++ /dev/null @@ -1,327 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.ejb.mr; - -import java.util.Properties; -import java.util.logging.Level; -import java.util.logging.Logger; - -import com.sun.ts.lib.porting.TSLoginContext; -import com.sun.ts.tests.ejb30.common.helper.Helper; -import com.sun.ts.tests.ejb30.common.lite.EJBLiteClientBase; - -import jakarta.ejb.EJB; - -public class Client extends EJBLiteClientBase { - @EJB(beanName = "InterMediateBean") - private InterMediate ejbref = null; - - Logger logger = null; - - // Security role references. - // Note: To test annotation @DeclareRoles, same role names are used as - // role-links. If there is a need to link different role-names for - // role-links then old-style deployment descriptor should be used for - // adding such role references. - private static final String emp_secrole_ref = "Employee"; - - private static final String admin_secrole_ref = "Administrator"; - - private static final String mgr_secrole_ref = "Manager"; - - private static final String UserNameProp = "user"; - - private static final String UserPasswordProp = "password"; - - private static final String AuthUser = "authuser"; - - private String authuser = "javajoe"; - - private String username = "j2ee"; - - private String password = "j2ee"; - - private Properties props = null; - - private TSLoginContext lc = null; - - /* - * public static void main(String[] args) { Client theTests = new Client(); - * Status s = theTests.run(args, System.out, System.err); s.exit(); } - */ - - /* - * @class.setup_props: user; password; authuser; - */ - - public void setup(String[] args, Properties p) { - super.setup(args, p); - props = p; - } - - /* - * @testName: EjbIsAuthz - * - * @assertion_ids: EJB:SPEC:827; JACC:SPEC:103; // Add JSR250 Assertion for - * RolesAllowed - * - * @test_Strategy: 1. Create a stateless session bean "InterMediateBean" with - * runas identity set to 2. Create another stateless session bean - * "TargetBean" with method EjbIsAuthz 3. Protect the method with multiple - * security roles including 4. Call the - * InterMediateBean.EjbIsAuthz() as principal . Which then - * invokes the EjbIsAuthz() on the TargetBean. 5. Since then InterMediateBean - * uses runas identity, , which is one of security roles set on the - * method permission, so access to the method EjbIsAuthz should be allowed. 6. - * Verify call returns successfully. - */ - - public void EjbIsAuthz() throws Exception { - logMsg("Starting EjbIsAuthz test"); - try { - ejbref.initLogging(props); - if (!ejbref.EjbIsAuthz(props)) - throw new Exception("EjbIsAuthz test failed"); - logMsg("EjbIsAuthz test passed"); - } catch (Exception e) { - throw new Exception("EjbIsAuthz test failed: ", e); - } - } - - /* - * @testName: EjbNotAuthz - * - * @assertion_ids: EJB:SPEC:811 ; JACC:SPEC:103; // Add JSR250 assertion for - * RolesAllowed - * - * @test_Strategy: 1. Create a stateless session bean "InterMediateBean" with - * runas identity set to 2. Create another stateless session bean - * "TargetBean" with method EjbNotAuthz 3. Protect the method with security - * role 4. Call the bean InterMediateBean.EjbNotAuthz() as - * principal . Which then invokes the EjbNotAuthz() on the - * bean TargetBean. 5. Since then InterMediateBean uses runas identity, - * , which does not share any principals with role . - * so access to the method EjbNotAuthz shouldnot be allowed. 6. Verify - * jakarta.ejb.EJBAccessException is generated. - */ - - public void EjbNotAuthz() throws Exception { - logMsg("Starting EjbNotAuthz test"); - try { - ejbref.initLogging(props); - if (!ejbref.EjbNotAuthz(props)) - throw new Exception("EjbNotAuthz test failed"); - logMsg("EjbNotAuthz test passed"); - } catch (Exception e) { - throw new Exception("EjbNotAuthz test failed:", e); - } - } - - /* - * @testName: EjbSecRoleRef - * - * @assertion_ids: EJB:SPEC:61.7; EJB:SPEC:81.4; // Add JSR 250 assertion for - * DeclareRoles - * - * @test_Strategy: 1. Create a stateless session bean "InterMediateBean" with - * runas identity set to 2. Create another stateless session bean - * "TargetBean" with method EjbSecRoleRef. 3. Protect the method with security - * role , Link a security role ref - emp_secrole_ref to role - * . 4. Call InterMediateBean.EjbSecRoleRef() as principal - * . Which then invokes EjbSecRoleRef on the bean - * TargetBean. 5. Since then InterMediateBean uses runas identity, , - * who'e principals also in role so access to the method of bean - * TargetBean should be allowed. 6. verify that return value of - * isCallerInRole(emp_secrole_ref) is true. - */ - - public void EjbSecRoleRef() throws Exception { - logMsg("Starting EjbSecRoleRef test"); - try { - ejbref.initLogging(props); - if (!ejbref.EjbSecRoleRef(emp_secrole_ref, props)) - throw new Exception("EjbSecRoleRef test failed"); - logMsg("EjbSecRoleRef test passed"); - } catch (Exception e) { - throw new Exception("EjbSecRoleRef test failed: ", e); - } - } - - /* - * @testName: MGR_InRole - * - * @assertion_ids: EJB:SPEC:827; //Add JSR 250 assertion for DeclareRoles - * - * @test_Strategy: 1. Create a stateless session bean "InterMediateBean" with - * runas identity set to 2. Create another stateless session beans - * "TargetBean" 3. Invoke InterMediateBean.InRole() with mgr_secrole_ref this - * inturn invokes TargetBean.IsCaller() with mgr_secrole_ref 4. Since - * InterMediateBean is configured to run as the - * TargetBean.IsCaller() with mgr_secrole_ref must return true. - */ - - public void MGR_InRole() throws Exception { - logMsg("Starting MGR_InRole"); - try { - ejbref.initLogging(props); - if (!ejbref.InRole(mgr_secrole_ref, props)) - throw new Exception("MGR_InRole test failed"); - logMsg("MGR_InRole test passed"); - } catch (Exception e) { - throw new Exception("MGR_InRole test failed:", e); - } - } - - /* - * @testName: ADM_InRole - * - * @assertion_ids: EJB:SPEC:61.8; // Add JSR250 assertion for DeclareRoles - * - * @test_Strategy: 1. Create a stateless session bean "InterMediateBean" with - * runas identity set to 2. Create another stateless session beans - * "TargetBean" 3. Invoke InterMediateBean.InRole() with admin_secrole_ref - * this inturn invokes TargetBean.IsCaller() with admin_secrole_ref 4. Since - * InterMediateBean is configured to run as the - * TargetBean.IsCaller() with admin_secrole_ref must return false. - */ - - public void ADM_InRole() throws Exception { - logMsg("Starting ADM_InRole test"); - try { - ejbref.initLogging(props); - if (ejbref.InRole(admin_secrole_ref, props)) - throw new Exception("ADM_InRole test failed"); - logMsg("ADM_InRole test passed"); - } catch (Exception e) { - throw new Exception("ADM_InRole test failed:", e); - } - } - - /* - * @testName: InterMediateBean_CallerPrincipal - * - * @assertion_ids: EJB:SPEC:796; // Add JSR250 assertion for RunAs - * - * @test_Strategy: 1. Create a stateless session bean InterMediateBean with - * runas identity set to 2. Verify that InterMediateBean returns the - * correct getCallerPrincipal() this should not be affected because it is - * configured to run as - */ - - public void InterMediateBean_CallerPrincipal() throws Exception { - logMsg("Starting InterMediateBean_CallerPrincipal test"); - try { - ejbref.initLogging(props); - if (!ejbref.IsCallerB1(username)) - throw new Exception("InterMediateBean_CallerPrincipal test failed"); - logMsg("InterMediateBean_CallerPrincipal test passed"); - } catch (Exception e) { - throw new Exception("InterMediateBean_CallerPrincipal test failed:", e); - } - } - - /* - * @testName: TargetBean_CallerPrincipal - * - * @assertion_ids: EJB:SPEC:796; // Add JSR250 assertion for RunAs - * - * @test_Strategy: 1. Create a stateless session bean "InterMediateBean" with - * runas identity set to 2. Create another stateless session bean - * "TargetBean". 3. Verify that TargetBean returns the correct - * getCallerPrincipal() which is the principal using runas identity, but not - * the principal invoked InterMediateBean. - */ - - public void TargetBean_CallerPrincipal() throws Exception { - logMsg("Starting TargetBean_CallerPrincipal test"); - try { - ejbref.initLogging(props); - - if (ejbref.IsCallerB2(username, props)) - throw new Exception("TargetBean_CallerPrincipal test failed"); - - if (!ejbref.IsCallerB2(authuser, props)) - throw new Exception("TargetBean_CallerPrincipal test failed"); - - logMsg("TargetBean_CallerPrincipal test passed"); - } catch (Exception e) { - throw new Exception("TargetBean_CallerPrincipal test failed:", e); - } - } - - /* - * @testName: uncheckedTest - * - * @assertion_ids: EJB:SPEC:827; note: Add JSR250 assertion for PermitAll - * - * @test_Strategy: 1. Create a stateless session bean with runas identity - * 2. Invoke InterMediateBean.uncheckedTest() this in-turn invokes - * TargetBean.uncheckedTest(). 3. Protect the TargetBean's uncheckedTest() - * with method permission "unchecked" or PermitAll 4. Verify that access is - * allowed. - */ - - public void uncheckedTest() throws Exception { - logMsg("Starting uncheckedTest "); - try { - ejbref.initLogging(props); - if (!ejbref.uncheckedTest(props)) { - logErr("uncheckedTest returned false"); - throw new Exception("uncheckedTest failed"); - } - logMsg("uncheckedTest passed."); - - } catch (Exception e) { - throw new Exception("uncheckedTest failed", e); - } - } - - /* - * @testName: excludeTest - * - * @assertion_ids: EJB:SPEC:808; // Add JSR250 assertion for DenyAll - * - * @test_Strategy: 1. Create a stateless session bean with runas identity - * 2. Invoke InterMediateBean.excludeTest(), this in-turn invokes - * TargetBean.excludeTest(). 3. Put the TargetBean's excludeTest() method in - * the exclude-list or DenyAll 4. Verify that jakarta.ejb.EJBAccessException is - * generated. - */ - - public void excludeTest() throws Exception { - logMsg("Starting excludeTest "); - try { - ejbref.initLogging(props); - if (!ejbref.excludeTest(props)) { - logErr("excludeTest returned false"); - throw new Exception("excludeTest failed"); - } - logMsg("excludeTest passed"); - } catch (Exception e) { - throw new Exception("excludeTest failed:", e); - } - } - - public void logMsg(String msg) { - logger = Helper.getLogger(); - logger.log(Level.INFO, msg); - } - - /* - * public void cleanup() throws Exception { logMsg("cleanup ok"); } - */ -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/InterMediate.java b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/InterMediate.java deleted file mode 100644 index 510ebc98ad..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/InterMediate.java +++ /dev/null @@ -1,38 +0,0 @@ -/* - * Copyright (c) 2007, 2018 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.ejb.mr; - -public interface InterMediate { - public void initLogging(java.util.Properties p); - - public boolean IsCallerB1(String caller); - - public boolean IsCallerB2(String caller, java.util.Properties p); - - public boolean InRole(String role, java.util.Properties p); - - public boolean EjbNotAuthz(java.util.Properties p); - - public boolean EjbIsAuthz(java.util.Properties p); - - public boolean EjbSecRoleRef(String role, java.util.Properties p); - - public boolean uncheckedTest(java.util.Properties p); - - public boolean excludeTest(java.util.Properties p); - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/InterMediateBean.java b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/InterMediateBean.java deleted file mode 100644 index e696895b89..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/InterMediateBean.java +++ /dev/null @@ -1,215 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.ejb.mr; - -import java.util.logging.Level; -import java.util.logging.Logger; - -import com.sun.ts.tests.ejb30.common.helper.Helper; - -import jakarta.annotation.Resource; -import jakarta.annotation.security.DeclareRoles; -import jakarta.annotation.security.RolesAllowed; -import jakarta.annotation.security.RunAs; -import jakarta.ejb.EJB; -import jakarta.ejb.EJBAccessException; -import jakarta.ejb.EJBs; -import jakarta.ejb.SessionContext; -import jakarta.ejb.Stateless; -import jakarta.ejb.TransactionAttribute; -import jakarta.ejb.TransactionAttributeType; -import jakarta.ejb.TransactionManagement; -import jakarta.ejb.TransactionManagementType; - -@Stateless(name = "InterMediateBean") -// @Remote({InterMediate.class}) - -// Set EJB References -@EJBs({ - @EJB(name = "TargetBean", beanName = "TargetBean", beanInterface = Target.class) }) -@TransactionManagement(TransactionManagementType.CONTAINER) -@DeclareRoles({ "Administrator", "Employee", "Manager" }) -@RunAs("Manager") -@RolesAllowed({ "Administrator", "Employee", "Manager" }) -public class InterMediateBean implements InterMediate { - // Lookup TargetBean and save the reference in ejb1 - @EJB(beanName = "TargetBean") - private Target ejb1 = null; - - private Logger logger = Helper.getLogger(); - - private SessionContext sctx = null; - - private static final String UserNameProp = "user"; - - private static final String UserPasswordProp = "password"; - - private String username = ""; - - private String password = ""; - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public void initLogging(java.util.Properties p) { - logger = Helper.getLogger(); - } - - @Resource - public void setSessionContext(SessionContext sc) { - sctx = sc; - } - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public boolean IsCallerB1(String caller) { - String name = sctx.getCallerPrincipal().getName(); - logMsg("IsCallerB1: " + name); - - if (name.indexOf(caller) < 0) - return false; - else - return true; - } - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public boolean IsCallerB2(String caller, java.util.Properties p) { - try { - // ejb1.initLogging(p); - logMsg("Running IsCallerB2 :" + caller); - boolean result = ejb1.IsCaller(caller); - return result; - } catch (Exception e) { - logMsg("Caught Unexpected exception e.getMessage()"); - return false; - } - } - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public boolean InRole(String role, java.util.Properties p) { - try { - // ejb1.initLogging(p); - logMsg("Running InRole : " + role); - boolean result = ejb1.EjbSecRoleRef(role); - return result; - } catch (Exception e) { - logMsg("Caught Unexpected exception e.getMessage()"); - return false; - } - } - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public boolean EjbNotAuthz(java.util.Properties p) { - try { - // ejb1.initLogging(p); - ejb1.EjbNotAuthz(); - logMsg( - "Method call did not generate an expected jakarta.ejb.EJBAccessException"); - return false; - } catch (EJBAccessException e) { - logMsg("Caught jakarta.ejb.EJBAccessException as expected"); - cleanup(ejb1); - return true; - } catch (Exception e) { - logMsg("Caught Unexpected exception e.getMessage()"); - cleanup(ejb1); - return false; - } - } - - private void cleanup(Target ejbref) { - - } - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public boolean EjbIsAuthz(java.util.Properties p) { - logMsg("In InterMediateBean.EjbIsAuthz method"); - try { - // ejb1.initLogging(p); - boolean result = ejb1.EjbIsAuthz(); - - if (!result) - return false; - - } catch (Exception e) { - logMsg("Caught Unexpected exception e.getMessage()"); - return false; - } - return true; - } - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public boolean EjbSecRoleRef(String role, java.util.Properties p) { - logMsg("In InterMediateBean.EjbSecRoleRef method"); - try { - // ejb1.initLogging(p); - boolean result = ejb1.EjbSecRoleRef(role); - - if (!result) - return false; - return true; - } catch (Exception e) { - logMsg("Caught Unexpected exception e.getMessage()"); - return false; - } - } - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public boolean uncheckedTest(java.util.Properties p) { - logMsg("In InterMediateBean.uncheckedTest method"); - try { - // ejb1.initLogging(p); - boolean result = ejb1.uncheckedTest(); - return result; - } catch (Exception e) { - logMsg("InterMediateBean.unchecktedTest failed with exception: " - + e.getMessage()); - return false; - } - } - - @RolesAllowed({ "Administrator", "Employee", "Manager" }) - @TransactionAttribute(TransactionAttributeType.NEVER) - public boolean excludeTest(java.util.Properties p) { - logMsg("In InterMediateBean.excludeTest method"); - - try { - // ejb1.initLogging(p); - boolean result = ejb1.excludeTest(); - return false; - } catch (EJBAccessException ex) { - logMsg("InterMediateBean : Got expected EJBAccessException"); - return true; - - } catch (Exception e) { - logMsg("InterMediateBean.excludeTest failed with exception: " - + e.getMessage()); - return false; - } - } - - @TransactionAttribute(TransactionAttributeType.NEVER) - public void logMsg(String msg) { - logger.log(Level.INFO, msg); - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/Target.java b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/Target.java deleted file mode 100644 index 056f1371e4..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/Target.java +++ /dev/null @@ -1,33 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.ejb.mr; - -public interface Target { - public void initLogging(java.util.Properties p); - - public boolean IsCaller(String caller); - - public boolean EjbNotAuthz(); - - public boolean EjbIsAuthz(); - - public boolean EjbSecRoleRef(String role); - - public boolean uncheckedTest(); - - public boolean excludeTest(); -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/TargetBean.java b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/TargetBean.java deleted file mode 100644 index 1e59179d8a..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/TargetBean.java +++ /dev/null @@ -1,89 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.ejb.mr; - -import java.util.logging.Logger; - -import com.sun.ts.tests.ejb30.common.helper.Helper; - -import jakarta.annotation.Resource; -import jakarta.annotation.security.DeclareRoles; -import jakarta.annotation.security.DenyAll; -import jakarta.annotation.security.PermitAll; -import jakarta.annotation.security.RolesAllowed; -import jakarta.ejb.SessionContext; -import jakarta.ejb.Stateless; -import jakarta.ejb.TransactionAttribute; -import jakarta.ejb.TransactionAttributeType; - -@Stateless(name = "TargetBean") -// @Remote({Target.class}) -@DeclareRoles({ "Administrator", "Manager", "Employee" }) - -public class TargetBean implements Target { - - private SessionContext sctx; - - private Logger logger = Helper.getLogger(); - - @RolesAllowed({ "Administrator", "Manager", "Employee" }) - @TransactionAttribute(TransactionAttributeType.REQUIRED) - public void initLogging(java.util.Properties p) { - } - - @TransactionAttribute(TransactionAttributeType.REQUIRED) - public boolean IsCaller(String caller) { - if (sctx.getCallerPrincipal().getName().indexOf(caller) < 0) - return false; - else - return true; - } - - @RolesAllowed({ "Administrator" }) - @TransactionAttribute(TransactionAttributeType.REQUIRED) - public boolean EjbNotAuthz() { - return true; - } - - @RolesAllowed({ "Administrator", "Manager", "Employee" }) - @TransactionAttribute(TransactionAttributeType.REQUIRED) - public boolean EjbIsAuthz() { - return true; - } - - @RolesAllowed({ "Manager", "Employee" }) - @TransactionAttribute(TransactionAttributeType.REQUIRED) - public boolean EjbSecRoleRef(String role) { - return sctx.isCallerInRole(role); - } - - @PermitAll - public boolean uncheckedTest() { - return true; - } - - @DenyAll - @TransactionAttribute(TransactionAttributeType.REQUIRED) - public boolean excludeTest() { - return true; - } - - @Resource - public void setSessionContext(SessionContext sc) { - sctx = sc; - } -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/build.xml deleted file mode 100644 index caf7b77f0e..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/build.xml +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/jacc_ejb_mr_ejblitesecuredjsp_vehicle_web.war.sun-ejb-jar.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/jacc_ejb_mr_ejblitesecuredjsp_vehicle_web.war.sun-ejb-jar.xml deleted file mode 100644 index 75dda5c983..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/jacc_ejb_mr_ejblitesecuredjsp_vehicle_web.war.sun-ejb-jar.xml +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - - Administrator - j2ee - - - Manager - javajoe - - - Employee - javajoe - j2ee - - - 0 - - InterMediateBean - jacc_ejb_mr_InterMediateBean - false - - javajoe - - - - supported - supported - supported - supported - - - username_password - default - true - - - supported - - - false - -1 - - - - TargetBean - jacc_ejb_mr_TargetBean - false - - - supported - supported - supported - supported - - - username_password - default - false - - - supported - - - false - -1 - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/jacc_ejb_mr_ejblitesecuredjsp_vehicle_web.war.sun-web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/jacc_ejb_mr_ejblitesecuredjsp_vehicle_web.war.sun-web.xml deleted file mode 100644 index c9344e8fa2..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/ejb/mr/jacc_ejb_mr_ejblitesecuredjsp_vehicle_web.war.sun-web.xml +++ /dev/null @@ -1,38 +0,0 @@ - - - - - - jacc_ejb_mr_ejblitesecuredjsp_vehicle_web - - Administrator - j2ee - - - Manager - javajoe - - - Employee - javajoe - j2ee - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSLogRecord.java b/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSLogRecord.java deleted file mode 100644 index 15a5b81cdc..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSLogRecord.java +++ /dev/null @@ -1,95 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/** - * $Id$ - * - * @author Raja Perumal - * 07/12/02 - */ - -package com.sun.ts.tests.jacc.provider; - -import java.util.logging.Level; -import java.util.logging.LogRecord; - -/** - * TSLogRecord is the custom LogRecord which has one additional logging field - * ContextId, in addition to the regular Logging fields. The Log fields of - * TSLogRecord are 1) sequence number 2) context Id (The logging context) 3) - * message 4) class name (The class which logs the log message) 5) method name ( - * The method which logs the log message) - **/ -public class TSLogRecord extends LogRecord { - - /** - * @serial The logging context Id - */ - private String contextId; - - /** - * Construct a LogRecord with the given level, message and context values. - * - * @param level - * a logging level value - * @param contextId - * the logging contextId - * @param msg - * the raw non-localized logging message - * - */ - TSLogRecord(Level level, String message, String contextId) { - // set the rest of the fields using parent constructor - super(level, message); - this.contextId = contextId; - - } - - /** - * Construct a LogRecord with the given level and message - * - * @param level - * a logging level value - * @param msg - * the raw non-localized logging message - * - */ - TSLogRecord(Level level, String message) { - super(level, message); - // Add jacc_ctx for default contextId - this.contextId = "jacc_ctx"; - } - - /** - * Get the contextId - * - * @ return contextId - */ - public String getContextId() { - return contextId; - } - - /** - * Set the contextId - * - * @param contextId - * the logging context Id - */ - public void setContextId(String cId) { - contextId = cId; - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSLogger.java b/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSLogger.java deleted file mode 100644 index b5c747444e..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSLogger.java +++ /dev/null @@ -1,216 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/** - * $Id$ - * - * @author Raja Perumal - * 07/13/02 - */ - -package com.sun.ts.tests.jacc.provider; - -import java.util.logging.FileHandler; -import java.util.logging.Filter; -import java.util.logging.Handler; -import java.util.logging.Level; -import java.util.logging.LogManager; -import java.util.logging.Logger; - -/** - * TSLogger is the custom Logger which extends java.util.Logger - * - **/ -public class TSLogger extends Logger { - - /** - * @serial The logging context Id - */ - private String contextId; - - private int levelValue = Level.INFO.intValue(); - - private int offValue = Level.OFF.intValue(); - - private Filter filter; - - private String name; - - // Note : The logger instance should not be - // stored in this instance variable, - // it should be kept at the log Manager using - // - // LogManager.addLogger(TSlogger); - // - // and it can be retrieved using - // - // LogManager.getLogger(name); - // - // Since Logger and TSLogger are of different types - // we cannot use the above logic and hence we have - // no choice except to store it here. - // - private static TSLogger tsLogger = null; - - protected TSLogger(String name) { - super(name, null); - this.name = name; - levelValue = Level.INFO.intValue(); - } - - /** - * Find or create a logger for a named subsystem. If a logger has already been - * created with the given name it is returned. Otherwise a new logger is - * created. - *

    - * If a new logger is created its log level will be configured based on the - * LogManager configuration and it will configured to also send logging output - * to its parent's handlers. It will be registered in the LogManager global - * namespace. - * - * @param name - * A name for the logger. This should be a dot-separated name and - * should normally be based on the package name or class name of the - * subsystem, such as java.net or javax.swing - * @return a suitable Logger - */ - public static synchronized TSLogger getTSLogger(String name) { - TSLogger result = null; - - LogManager manager = LogManager.getLogManager(); - - // TSLogger result = manager.getLogger(name); - // if (result == null){ - // result = new TSLogger(name); - // manager.addLogger(result); - // result = manager.getLogger(name); - // } - - if (tsLogger != null) { - if (tsLogger.getName().equals(name)) - result = tsLogger; - } else { - result = new TSLogger(name); - manager.addLogger(result); - } - - return result; - } - - /** - * Log a message, with no arguments. - *

    - * If the logger is currently enabled for the given message level then the - * given message is forwarded to all the registered output Handler objects. - *

    - * - * @param level - * One of the message level identifiers, e.g. SEVERE - * @param msg - * The string message (or a key in the message catalog) - */ - public void log(Level level, String msg) { - // assign default context (jacc_ctx) to all messages ??? - log(level, msg, "jacc_ctx"); - } - - /** - * Log a message, with no arguments. - *

    - * If the logger is currently enabled for the given message level then the - * given message is forwarded to all the registered output Handler objects. - *

    - * - * @param level - * One of the message level identifiers, e.g. SEVERE - * @param msg - * The string message (or a key in the message catalog) - * @param contextId - * the logging context Id - */ - public void log(Level level, String msg, String contextId) { - if (level.intValue() < levelValue || levelValue == offValue) { - return; - } - TSLogRecord lr = new TSLogRecord(level, msg, contextId); - String rbn = null; - - Logger target = this; - while (target != null) { - rbn = target.getResourceBundleName(); - if (rbn != null) { - break; - } - target = target.getParent(); - } - - if (rbn != null) { - lr.setResourceBundleName(rbn); - // lr.setResourceBundle("null"); - } - - log(lr); - - } - - /** - * Log a TSLogRecord. - * - * @param record - * the TSLogRecord to be published - */ - public void log(TSLogRecord record) { - if (record.getLevel().intValue() < levelValue || levelValue == offValue) { - return; - } - synchronized (this) { - if (filter != null && !filter.isLoggable(record)) { - return; - } - } - - // Post the LogRecord to all our Handlers, and then to - // our parents' handlers, all the way up the tree. - - TSLogger logger = this; - while (logger != null) { - Handler targets[] = logger.getHandlers(); - - if (targets != null) { - for (int i = 0; i < targets.length; i++) { - // targets[i].publish(record); - - // Publish record only if the - // handler is of type FileHandler - // Do not publish to all parent handler - // Parent handler may not be able to - // Format the TSLogRecord, because - // TSLogRecord is the custom record. - if (targets[i] instanceof FileHandler) - targets[i].publish(record); - } - } - - if (!logger.getUseParentHandlers()) { - break; - } - - // logger = (TSLogger)logger.getParent(); - logger = null; - } - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicy.java b/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicy.java deleted file mode 100644 index ef72dbfe7e..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicy.java +++ /dev/null @@ -1,634 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/** - * $Id$ - * - * @author Raja Perumal - * 08/14/02 - */ - -package com.sun.ts.tests.jacc.provider; - -import java.io.File; -import java.security.CodeSource; -import java.security.Permission; -import java.security.PermissionCollection; -import java.security.ProtectionDomain; -import java.util.StringTokenizer; -import java.util.logging.FileHandler; -import java.util.logging.Level; - -import com.sun.ts.lib.util.sec.security.provider.PolicyFile; - -import jakarta.security.jacc.EJBMethodPermission; -import jakarta.security.jacc.EJBRoleRefPermission; -import jakarta.security.jacc.PolicyConfiguration; -import jakarta.security.jacc.PolicyConfigurationFactory; -import jakarta.security.jacc.PolicyContext; -import jakarta.security.jacc.WebResourcePermission; -import jakarta.security.jacc.WebRoleRefPermission; -import jakarta.security.jacc.WebUserDataPermission; - -/** - * This is a delegating Policy Implementation class which delegates the - * permission evaluation to vendor's policy implentation defined by - * "vendor.jakarta.security.jacc.policy.provider" - * - * In case the vendor doesn't provide Policy implementation default jdk policy - * will be used. - * - * Note: Since J2EE 1.3 appservers are not required to support JSR115, the 1.3 - * policy implementation defined by "jakarta.security.auth.policy.provider" will - * not used for testing in this TCK - */ -public final class TSPolicy extends java.security.Policy { - private java.security.Policy policy = null; - - public static final String VENDOR_POLICY_PROVIDER = "vendor.jakarta.security.jacc.policy.provider"; - - private static ClassLoader classLoader = null; - - public static boolean POLICY_INSTALLED = false; - - public static TSLogger logger = null; - - boolean firstInvocationForJACCPermissions = true; - - boolean multipleSetPolicyAllowed = false; - - String[] tokenArray = new String[2]; - - String methodInterfaceName = null; - - String methodName = null; - - // This constructor will be used by vendor AppServer - public TSPolicy() { - initializeTSLogger(); - if (!POLICY_INSTALLED) - loadPolicy(); - - // invoke equals and hashCode method on all JACC Permissions. - if (firstInvocationForJACCPermissions) { - jaccPermissionsEquals(); - jaccPermissionsHashCode(); - firstInvocationForJACCPermissions = false; - } - } - - /** - * Evaluates the global policy and returns a PermissionCollection object - * specifying the set of permissions allowed for code from the specified code - * source. - * - * @param codesource - * the CodeSource associated with the caller. This encapsulates the - * original location of the code (where the code came from) and the - * public key(s) of its signer. - * - * @return the set of permissions allowed for code from codesource - * according to the policy.The returned set of permissions must be a - * new mutable instance and it must support heterogeneous Permission - * types. - * - */ - public PermissionCollection getPermissions(CodeSource codesource) { - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicy", "getPermissions"); - } - // print permission collection as logger info ? - return policy.getPermissions(codesource); - } - - /** - * Evaluates the global policy and returns a PermissionCollection object - * specifying the set of permissions allowed given the characteristics of the - * protection domain. - * - * @param domain - * the ProtectionDomain associated with the caller. - * - * @return the set of permissions allowed for the domain according to - * the policy.The returned set of permissions must be a new mutable - * instance and it must support heterogeneous Permission types. - * - * @see java.security.ProtectionDomain - * @see java.security.SecureClassLoader - * @since 1.4 - */ - public PermissionCollection getPermissions(ProtectionDomain domain) { - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicy", "getPermissions"); - } - // print permission collection as logger info ? - return policy.getPermissions(domain); - } - - /** - * Evaluates the global policy for the permissions granted to the - * ProtectionDomain and tests whether the permission is granted. - * - * @param domain - * the ProtectionDomain to test - * @param permission - * the Permission object to be tested for implication. - * - * @return true if "permission" is a proper subset of a permission granted to - * this ProtectionDomain. - * - * @see java.security.ProtectionDomain - * @since 1.4 - */ - public boolean implies(ProtectionDomain domain, Permission permission) { - // invoke policyContextKey1() only if - // permission instanceof WebResourcePermission and - // permission.getName().equals(/secured.jsp) // for secured.jsp - if ((permission instanceof WebResourcePermission) - && (permission.getName().equals("/secured.jsp"))) { - logger.log(Level.INFO, "Calling policyContextKey1()"); - policyContextKey1(); - } - - if (permission instanceof EJBMethodPermission) { - - // Get method interface name (such as "Remote", "Home", etc..) - // and method name from permissions.getActions() string. - tokenArray = getTokensFromString(permission.getActions()); - - // Get method interface name and methodName from tokenArray - methodName = tokenArray[0]; - methodInterfaceName = tokenArray[1]; - - // inovke policyContextKey2() and policyContextKey3() only if - // permission.getName().equals("jacc_providerContracts_JACCEntity") and - // methodInterfaceName.equals("Remote) and - // methodName.equals("getArg1") - if ((permission.getName().equals("jacc_providerContracts_JACCEntity")) - && methodName.equals("getArg1") - && methodInterfaceName.equals("Remote")) - - { - logger.log(Level.INFO, "Calling policyContextKey2()"); - // policyContextKey2(); - logger.log(Level.INFO, "Calling policyContextKey3()"); - policyContextKey3(); - } - } - - // If there is a PolicyContext.getContextID, verify new getPolicyConfiguration() methods work - String contextId = PolicyContext.getContextID(); - if(contextId != null) { - try { - // Should be non-null PolicyConfiguration - PolicyConfigurationFactory pcf = PolicyConfigurationFactory.getPolicyConfigurationFactory(); - PolicyConfiguration pc = pcf.getPolicyConfiguration(); - if(pc != null) { - logger.log(Level.INFO, "PolicyConfigurationFactory.getPolicyConfiguration() : PASSED"); - } else { - logger.log(Level.INFO, "PolicyConfigurationFactory.getPolicyConfiguration() : FAILED"); - } - // Should be non-null PolicyConfiguration and match no-arg getPolicyConfiguration() - PolicyConfiguration pc2 = pcf.getPolicyConfiguration(contextId); - if(pc2 == null || !pc.equals(pc2)) { - logger.log(Level.INFO, "PolicyConfigurationFactory.getPolicyConfiguration(String) : FAILED"); - } else { - logger.log(Level.INFO, "PolicyConfigurationFactory.getPolicyConfiguration(String) : PASSED"); - } - - } catch (Exception e) { - logger.log(Level.INFO, "PolicyConfigurationFactory.getPolicyConfiguration() : FAILED"); - } - } - - return policy.implies(domain, permission); - } - - /** - * Refreshes/reloads the policy configuration. The behavior of this method - * depends on the implementation. For example, calling refresh on - * a file-based policy will cause the file to be re-read. - * - */ - public void refresh() { - policy.refresh(); - if (logger != null) - logger.log(Level.INFO, "TSPolicy.refresh() invoked"); - } - - /** - * Loads vendor's policy implementation or JDK's default policy Note: - * LoadPolicy does not set the policy using setPolicy(policy), since setPolicy - * method will be called by the underlying provider, this task is delegated to - * the underlying provider. - */ - private void loadPolicy() { - String javaPolicy = System.getProperty(VENDOR_POLICY_PROVIDER); - if (javaPolicy == null) { - logger.log(Level.FINE, "Loading Default Policy"); - policy = (java.security.Policy) new PolicyFile(); - policy.refresh(); - POLICY_INSTALLED = true; - logger.log(Level.INFO, "Default policy loaded"); - } else { - try { - logger.log(Level.FINE, "Loading Policy = " + javaPolicy); - // Object obj = Class.forName(javaPolicy).newInstance(); - classLoader = TSPolicy.class.getClassLoader(); - Class clazz = classLoader.loadClass(javaPolicy); - Object obj = (Object) clazz.newInstance(); - - if (obj instanceof java.security.Policy) { - policy = (java.security.Policy) obj; - logger.log(Level.INFO, "vendor's policy loaded!"); - POLICY_INSTALLED = true; - } else { - logger.log(Level.SEVERE, - "vendor's policy is not of type java.security.Policy"); - throw new RuntimeException( - javaPolicy + "is not a type of java.security.Policy"); - } - } catch (ClassNotFoundException cnfe) { - // problem with property value or classpath - logger.log(Level.SEVERE, "vendor's Policy instantiation error", cnfe); - throw new RuntimeException(cnfe); - } catch (IllegalAccessException iae) { - // problem with policy class definition - logger.log(Level.SEVERE, "vendor's Policy instantiation error", iae); - throw new RuntimeException(iae); - } catch (InstantiationException ie) { - // problem with policy instantiation - logger.log(Level.SEVERE, "vendor's Policy instantiation error", ie); - throw new RuntimeException(ie); - } - } - } - - private static void initializeTSLogger() { - String logFileLocation = null; - if (logger != null) - return; - else { - try { - logFileLocation = System.getProperty("log.file.location"); - if (logFileLocation != null) { - logger = TSLogger.getTSLogger("jacc"); - boolean appendMode = true; - - // clean the content of JACCLog.txt if it exists - File file = new File(logFileLocation + "/JACCLog.txt"); - if (file.exists()) { - // delete the file, if it exists - file.delete(); - } - - // create a new file - System.out.println( - "XXXX: in initializeTSLogger() - about to create JACCLog.txt"); - FileHandler fileHandler = new FileHandler( - logFileLocation + "/JACCLog.txt", appendMode); - fileHandler.setFormatter(new TSXMLFormatter()); - logger.addHandler(fileHandler); - setTSLogger(logger); - } else { - // use default logging mechanism - logger = TSLogger.getTSLogger("jacc"); - setTSLogger(logger); - logger.log(Level.SEVERE, - "log.file.location not set: Using default logger"); - } - } catch (Exception e) { - throw new RuntimeException("TSLogger Initialization failed", e); - } - } - } - - public static TSLogger getTSLogger() { - return logger; - } - - public static void setTSLogger(TSLogger lgr) { - logger = lgr; - } - - /** - * testName: policyContextKey1 - * - * @assertion_ids: JACC:SPEC:99; JACC:JAVADOC:30 - * - * @test_Strategy: 1) call - * PolicyContext.getContext("jakarta.servlet.http.HttpServletRequest") - * 2) verify the return value is an instance of - * HttpServletRequest - * - */ - private void policyContextKey1() { - try { - // Get HttpServletRequest object - jakarta.servlet.http.HttpServletRequest ctx = PolicyContext - .getContext("jakarta.servlet.http.HttpServletRequest"); - logger.log(Level.INFO, "PolicyContext.getContext() " + "test passed for" - + "jakarta.servlet.http.HttpServletRequest"); - logger.log(Level.INFO, "PolicyContextKey1: PASSED"); - } catch (ClassCastException e) { - logger.log(Level.INFO, - "PolicyContext.getContext()" + "returned incorrect value for key " - + "jakarta.servlet.http.HttpServletRequest"); - logger.log(Level.SEVERE, "PolicyContextKey1: FAILED"); - } catch (Exception e) { - logger.log(Level.SEVERE, "PolicyContextKey1: FAILED"); - } - } - - /** - * testName: policyContextKey3 - * - * @assertion_ids: JACC:SPEC:97; JACC:JAVADOC:30 - * - * @test_Strategy: 1) call - * PolicyContext.getContext("javax.security.auth.Subject.container) - * 2) verify the return value is an instance of - * javax.security.auth.Subject - * - */ - private void policyContextKey3() { - try { - // Get Subject - javax.security.auth.Subject subject = PolicyContext - .getContext("javax.security.auth.Subject.container"); - logger.log(Level.INFO, "PolicyContext.getContext() " + "test passed for" - + "javax.security.auth.Subject.container"); - logger.log(Level.INFO, "PolicyContextKey3: PASSED"); - } catch (ClassCastException e) { - logger.log(Level.INFO, - "PolicyContext.getContext()" + "returned incorrect value for key " - + "javax.security.auth.Subject.container"); - logger.log(Level.INFO, "PolicyContextKey3: FAILED"); - } catch (Exception e) { - logger.log(Level.SEVERE, "PolicyContextKey3: FAILED"); - } - } - - /** - * Gets the method interface name and method Name from the given permission's - * action string - */ - public String[] getTokensFromString(String actions) { - String[] array = new String[2]; - StringTokenizer strtoken; - - // Get first token and the remaining string - strtoken = new StringTokenizer(actions, ","); - if (actions.indexOf(",") > 0) { - // get methodName - array[0] = strtoken.nextToken(); - - if (strtoken.hasMoreTokens()) { - // get methodInterfaceName - array[1] = strtoken.nextToken(); - } - } - return array; - } - - /** - * testName: jaccPermissionsEquals - * - * assertion_ids: JACC:JAVADOC:4; JACC:JAVADOC:9; JACC:JAVADOC:43; - * JACC:JAVADOC:47; JACC:JAVADOC:53 - * - * test_Strategy: 1) verify EJBMethodPermission.equals() or 2) verify - * EJBRoleRefPermission.equals() or 3) verify WebResourcePermission.equals() - * or 4) verify WebRoleRefPermission.equals() or 5) verify - * WebUserDataPermission.equals() - * - */ - private void jaccPermissionsEquals() { - try { - logger.log(Level.FINE, "Checking EJBMethodPermission.equals()"); - - EJBMethodPermission emp = new EJBMethodPermission("DummyEJB", - "dummyMethod,Home,String"); - - // call equals method onto itself - boolean result = emp.equals(emp); - - if (result) { - logger.log(Level.INFO, "EJBMethodPermission.equals() : PASSED"); - } else { - logger.log(Level.INFO, "EJBMethodPermission.equals() : FAILED"); - logger.log(Level.INFO, "Calling EJBMethodPermission.equals()" - + " onto itself returned false"); - } - - } catch (Exception e) { - logger.log(Level.SEVERE, "EJBMethodPermission.equals() : FAILED"); - } - - try { - EJBRoleRefPermission errp = new EJBRoleRefPermission("DummyEJB", - "dummyRole"); - // call equals method onto itself - boolean result = errp.equals(errp); - if (result) { - logger.log(Level.INFO, "EJBRoleRefPermission.equals() : PASSED"); - } else { - logger.log(Level.INFO, "EJBRoleRefPermission.equals() : FAILED"); - logger.log(Level.INFO, "Calling EJBRoleRefPermission.equals()" - + " onto itself returned false"); - } - } catch (Exception e) { - logger.log(Level.SEVERE, "EJBRoleRefPermission.equals() : FAILED"); - } - - try { - WebResourcePermission wrp = new WebResourcePermission("/dummyEntry", - "POST"); - - // call equals method onto itself - boolean result = wrp.equals(wrp); - if (result) { - logger.log(Level.INFO, "WebResourcePermission.equals() : PASSED"); - } else { - logger.log(Level.INFO, "WebResourcePermission.equals() : FAILED"); - logger.log(Level.INFO, "Calling WebResourcePermission.equals()" - + " onto itself returned false"); - } - } catch (Exception e) { - logger.log(Level.SEVERE, "WebResourcePermission.equals() : FAILED"); - } - - try { - WebRoleRefPermission wrrp = new WebRoleRefPermission("dummyReosource", - "dummyRole"); - - // call equals method onto itself - boolean result = wrrp.equals(wrrp); - if (result) { - logger.log(Level.INFO, "WebRoleRefPermission.equals() : PASSED"); - } else { - logger.log(Level.INFO, "WebRoleRefPermission.equals() : FAILED"); - logger.log(Level.INFO, "Calling WebRoleRefPermission.equals()" - + " onto itself returned false"); - } - } catch (Exception e) { - logger.log(Level.SEVERE, "WebRoleRefPermission.equals() : FAILED"); - } - - try { - WebUserDataPermission wudp = new WebUserDataPermission( - "/dummyResource.jsp", "GET,POST:CONFIDENTIAL"); - - // call equals method onto itself - boolean result = wudp.equals(wudp); - if (result) { - logger.log(Level.INFO, "WebUserDataPermission.equals() : PASSED"); - } else { - logger.log(Level.INFO, "WebUserDataPermission.equals() : FAILED"); - logger.log(Level.INFO, "Calling WebUserDataPermission.equals()" - + " onto itself returned false"); - } - } catch (Exception e) { - logger.log(Level.SEVERE, "WebUserDataPermission.equals() : FAILED"); - } - - } - - /** - * testName: jaccPermissionsHashCode - * - * assertion_ids: JACC:JAVADOC:6; JACC:JAVADOC:11; JACC:JAVADOC:42; - * JACC:JAVADOC:49; JACC:JAVADOC:55 - * - * test_Strategy: 1) verify EJBMethodPermission.hashCode(); or 2) verify - * EJBRoleRefPermission.hashCode(); or 3) verify - * WebResourcePermission.hashCode() or 4) verify - * WebRoleRefPermission.hashCode() or 5) verify - * WebUserDataPermission.hashCode() - */ - - private void jaccPermissionsHashCode() { - try { - EJBMethodPermission emp = new EJBMethodPermission("DummyEJB", - "dummyMethod,Home,String"); - - // Get EJBMethodPermission's hashcode - int hashCode1 = emp.hashCode(); - - // Get EJBMethodPermission's hashcode again - int hashCode2 = emp.hashCode(); - - if (hashCode1 == hashCode2) { - logger.log(Level.INFO, "EJBMethodPermission.hashCode() : PASSED"); - } else { - logger.log(Level.INFO, "EJBMethodPermission.hashCode() : FAILED"); - logger.log(Level.INFO, "EJBMethodPermission.hashCode()" - + " returned different values within the same application."); - - } - - } catch (Exception e) { - logger.log(Level.SEVERE, "EJBMethodPermission.hashCode() : FAILED"); - } - - try { - EJBRoleRefPermission errp = new EJBRoleRefPermission("DummyEJB", - "dummyRole"); - - // Get EJBRoleRefPermission's hashcode - int hashCode3 = errp.hashCode(); - - // Get EJBRoleRefPermission's hashcode again - int hashCode4 = errp.hashCode(); - - if (hashCode3 == hashCode4) { - logger.log(Level.INFO, "EJBRoleRefPermission.hashCode() : PASSED"); - } else { - logger.log(Level.INFO, "EJBRoleRefPermission.hashCode() : FAILED"); - logger.log(Level.INFO, "EJBRoleRefPermission.hashCode()" - + " returned different values within the same application."); - } - - } catch (Exception e) { - logger.log(Level.SEVERE, "EJBRoleRefPermission.hashCode() : FAILED"); - } - - try { - WebResourcePermission wrp = new WebResourcePermission("/dummyEntry", - "POST"); - - // Get WebResourcePermission's hashcode - int hashCode5 = wrp.hashCode(); - - // Get WebResourcePermission's hashcode again - int hashCode6 = wrp.hashCode(); - - if (hashCode5 == hashCode6) { - logger.log(Level.INFO, "WebResourcePermission.hashCode() : PASSED"); - } else { - logger.log(Level.INFO, "WebResourcePermission.hashCode() : FAILED"); - logger.log(Level.INFO, "WebResourcePermission.hashCode()" - + " returned different values within the same application."); - } - - } catch (Exception e) { - logger.log(Level.SEVERE, "WebResourcePermission.hashCode() : FAILED"); - } - - try { - WebRoleRefPermission wrrp = new WebRoleRefPermission("dummyReosource", - "dummyRole"); - - // Get WebRoleRefPermission's hashcode - int hashCode7 = wrrp.hashCode(); - - // Get WebRoleRefPermission's hashcode again - int hashCode8 = wrrp.hashCode(); - - if (hashCode7 == hashCode8) { - logger.log(Level.INFO, "WebRoleRefPermission.hashCode() : PASSED"); - } else { - logger.log(Level.INFO, "WebRoleRefPermission.hashCode() : FAILED"); - logger.log(Level.INFO, "WebRoleRefPermission.hashCode()" - + " returned different values within the same application."); - } - - } catch (Exception e) { - logger.log(Level.SEVERE, "WebRoleRefPermission.hashCode() : FAILED"); - } - - try { - WebUserDataPermission wudp = new WebUserDataPermission( - "/dummyResource.jsp", "GET,POST:CONFIDENTIAL"); - - // Get WebUserDataPermission's hashcode - int hashCode9 = wudp.hashCode(); - - // Get WebUserDataPermission's hashcode again - int hashCode10 = wudp.hashCode(); - - if (hashCode9 == hashCode10) { - logger.log(Level.INFO, "WebUserDataPermission.hashCode() : PASSED"); - } else { - logger.log(Level.INFO, "WebUserDataPermission.hashCode() : FAILED"); - logger.log(Level.INFO, "WebUserDataPermission.hashCode()" - + " returned different values within the same application."); - } - } catch (Exception e) { - logger.log(Level.SEVERE, "WebUserDataPermission.hashCode() : FAILED"); - } - } -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicyConfigurationFactoryImpl.java b/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicyConfigurationFactoryImpl.java deleted file mode 100644 index 796d5da2f0..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicyConfigurationFactoryImpl.java +++ /dev/null @@ -1,262 +0,0 @@ -/* - * Copyright (c) 2007, 2022 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/** - * $Id$ - * - * @author Raja Perumal - * 08/01/02 - */ - -package com.sun.ts.tests.jacc.provider; - -import java.util.logging.Level; - -import jakarta.security.jacc.PolicyConfiguration; -import jakarta.security.jacc.PolicyConfigurationFactory; -import jakarta.security.jacc.PolicyContext; -import jakarta.security.jacc.PolicyContextException; - -/** - * JACC PolicyConfigurationFactory This is a delegating - * PolicyConfigurationFactory which delegates the policy configurations to - * vendor implementation of PolicyConfigurationFactory class. - * - */ -public class TSPolicyConfigurationFactoryImpl - extends PolicyConfigurationFactory { - private static TSLogger lgr = null; - - private static String FACTORY_NAME = "vendor.jakarta.security.jacc.PolicyConfigurationFactory.provider"; - - private static PolicyConfigurationFactory pcFactory; - - private static TSPolicyConfigurationImpl policyConfiguration = null; - - private static ClassLoader classLoader = null; - - public TSPolicyConfigurationFactoryImpl() throws PolicyContextException { - try { - - pcFactory = TSPolicyConfigurationFactoryImpl - .getPolicyConfigurationFactory(); - } catch (PolicyContextException pce) { - if (lgr != null) - lgr.severe("Failed to get PolicyConfigurationFactory"); - throw new PolicyContextException(pce); - } - } - - /** - * This method is used to obtain an instance of the provider specific class - * that implements the PolicyConfiguration interface that corresponds to the - * identified policy context within the provider. The methods of the - * PolicyConfiguration interface are used to define the policy statements of - * the identified policy context. - *

    - * If at the time of the call, the identified policy context does not exist in - * the provider, then the policy context will be created in the provider and - * the Object that implements the context's PolicyConfiguration Interface will - * be returned. If the state of the identified context is "deleted" or - * "inService" it will be transitioned to the "open" state as a result of the - * call. The states in the lifecycle of a policy context are defined by the - * PolicyConfiguration interface. - *

    - * For a given value of policy context identifier, this method must always - * return the same instance of PolicyConfiguration and there must be at most - * one actual instance of a PolicyConfiguration with a given policy context - * identifier (during a process context). - *

    - * To preserve the invariant that there be at most one PolicyConfiguration - * object for a given policy context, it may be necessary for this method to - * be thread safe. - *

    - * - * @param contextId - * A String identifying the policy context whose PolicyConfiguration - * interface is to be returned. The value passed to this parameter - * must not be null. - *

    - * @param remove - * A boolean value that establishes whether or not the policy - * statements of an existing policy context are to be removed before - * its PolicyConfiguration object is returned. If the value passed to - * this parameter is true, the policy statements of an existing - * policy context will be removed. If the value is false, they will - * not be removed. - * - * @return an Object that implements the PolicyConfiguration Interface matched - * to the Policy provider and corresponding to the identified policy - * context. - * - * @throws java.lang.SecurityException - * when called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the getPolicyConfiguration method - * signature. The exception thrown by the implementation class will - * be encapsulated (during construction) in the thrown - * PolicyContextException. - */ - - public PolicyConfiguration getPolicyConfiguration(String contextId, - boolean remove) throws PolicyContextException { - PolicyConfiguration polConf = null; - // check if we can invoke method - if (lgr.isLoggable(Level.FINER)) { - lgr.entering("PolicyConfigurationFactoryImpl", "getPolicyConfiguration"); - } - polConf = new TSPolicyConfigurationImpl(contextId, remove, lgr); - lgr.log(Level.INFO, - "PolicyConfigurationFactory.getPolicyConfiguration() invoked"); - lgr.log(Level.FINER, - "Getting PolicyConfiguration object with id = " + contextId); - policyConfiguration = (TSPolicyConfigurationImpl) polConf; - - return polConf; - } - - /** - * This static method uses a system property to find and instantiate (via a - * public constructor) a provider specific factory implementation class. The - * name of the provider specific factory implementation class is obtained from - * the value of the system property, - *

    - *

    -   *     vendor.jakarta.security.jacc.PolicyConfigurationFactory.provider
    -   * 
    - *

    - * - * @return the singleton instance of the provider specific - * PolicyConfigurationFactory implementation class. - * - * @throws SecurityException - * when called by an AccessControlContext that has not been granted - * the "getPolicy" SecurityPermission. - * - * @throws PolicyContextException - * when the class named by the system property could not be found - * including because the value of the system property has not been - * set. - */ - - public static PolicyConfigurationFactory getPolicyConfigurationFactory() - throws PolicyContextException { - // Get TSLogger - getTSLogger(); - if (pcFactory != null) - return pcFactory; - String classname = System.getProperty(FACTORY_NAME); - if (classname == null) { - lgr.severe("factory.name.notset"); - throw new PolicyContextException( - "PolicyConfigurationFactory name not set!"); - } - try { - // Class clazz = Class.forName(classname); - classLoader = TSPolicyConfigurationFactoryImpl.class.getClassLoader(); - Class clazz = classLoader.loadClass(classname); - pcFactory = (PolicyConfigurationFactory) clazz.newInstance(); - - if (pcFactory != null) { - lgr.log(Level.INFO, "PolicyConfigurationFactory instantiated"); - } - } catch (Exception e) { - lgr.log(Level.SEVERE, "factory.instantiation.error", e); - throw new PolicyContextException(e); - } - return pcFactory; - } - - /** - * This method determines if the identified policy context exists with state - * "inService" in the Policy provider associated with the factory. - *

    - * - * @param contextId - * A string identifying a policy context - * - * @return true if the identified policy context exists within the provider - * and its state is "inService", false otherwise. - * - * @throws java.lang.SecurityException - * when called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the inService method signature. The - * exception thrown by the implementation class will be encapsulated - * (during construction) in the thrown PolicyContextException. - */ - public boolean inService(String contextId) throws PolicyContextException { - // check if we can invoke method - if (lgr.isLoggable(Level.FINER)) { - lgr.entering("PolicyConfigurationFactoryImpl", "inService"); - } - lgr.log(Level.INFO, "PolicyConfigurationFactory.inService() invoked"); - lgr.log(Level.FINER, - "PolicyConfiguration.inService() invoked for context id = " - + contextId); - - // check if we can invoke method - if (lgr.isLoggable(Level.FINER)) { - lgr.entering("PolicyConfigurationFactoryImpl", "getPolicyConfiguration"); - } - - return pcFactory.inService(contextId); - } - - public PolicyConfiguration getPolicyConfiguration(String contextID){ - if (lgr.isLoggable(Level.FINER)) { - lgr.entering("PolicyConfigurationFactoryImpl", "getPolicyConfiguration(String)"); - } - PolicyConfiguration polConf = pcFactory.getPolicyConfiguration(contextID); - lgr.log(Level.INFO, - "PolicyConfigurationFactory.getPolicyConfiguration(String) invoked"); - return polConf; - } - - public PolicyConfiguration getPolicyConfiguration(){ - String contextId = PolicyContext.getContextID(); - PolicyConfiguration polConf = null; - // check if we can invoke method - if (lgr.isLoggable(Level.FINER)) { - lgr.entering("PolicyConfigurationFactoryImpl", "getPolicyConfiguration()"); - } - polConf = pcFactory.getPolicyConfiguration(contextId); - lgr.log(Level.INFO, - "PolicyConfigurationFactory.getPolicyConfiguration(String) invoked"); - lgr.log(Level.FINER, - "Getting PolicyConfiguration object with id = " + contextId); - policyConfiguration = (TSPolicyConfigurationImpl) polConf; - - return polConf; - } - - private static void getTSLogger() { - if (lgr != null) - return; - else { - // TSLogger already intialized by TSPolicy, - // get the instance of TSLogger from TSPolicy - TSPolicy tsPolicy = (TSPolicy) java.security.Policy.getPolicy(); - lgr = tsPolicy.getTSLogger(); - } - } -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicyConfigurationImpl.java b/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicyConfigurationImpl.java deleted file mode 100644 index 7384a76fb5..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSPolicyConfigurationImpl.java +++ /dev/null @@ -1,1004 +0,0 @@ -/* - * Copyright (c) 2007, 2022 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/* - * $Id$ - * - * @author Raja Perumal - */ - -package com.sun.ts.tests.jacc.provider; - -import java.security.Permission; -import java.security.PermissionCollection; -import java.util.Date; -import java.util.Enumeration; -import java.util.Map; -import java.util.Vector; -import java.util.logging.Level; - -import jakarta.security.jacc.EJBMethodPermission; -import jakarta.security.jacc.EJBRoleRefPermission; -import jakarta.security.jacc.PolicyConfiguration; -import jakarta.security.jacc.PolicyConfigurationFactory; -import jakarta.security.jacc.PolicyContextException; -import jakarta.security.jacc.WebResourcePermission; -import jakarta.security.jacc.WebRoleRefPermission; -import jakarta.security.jacc.WebUserDataPermission; - -/** - * Jacc PolicyConfiguration delegates the policy configuration tasks to vendor's - * PolicyConfiguration implementation class. - * - */ -public class TSPolicyConfigurationImpl implements PolicyConfiguration { - private PolicyConfiguration policyConfiguration = null; - - private PolicyConfigurationFactory pcf = null; - - private static TSLogger logger = null; - - private String applicationContext = null; - - private String appTime = null; - - private Vector applicationLinkTable = new Vector(); - - public TSPolicyConfigurationImpl(String contextId, boolean remove, - TSLogger lgr) throws PolicyContextException { - Date date = new Date(); - appTime = "" + date.getTime(); - logger = lgr; - - // Add timeStamp to the contextId, - applicationContext = contextId; - - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "TSPolicyConfigurationImpl"); - } - - // set vendor's PolicyConfigurationFactory - pcf = TSPolicyConfigurationFactoryImpl.getPolicyConfigurationFactory(); - - // **** This covers two assertions JACC:SPEC:33 and JACC:SPEC:56 **** - // set vendor's PolicyConfiguration - policyConfiguration = pcf.getPolicyConfiguration(contextId, remove); - - // This(appId record) will be used as an identifier - // for isolating the logs associated with each test run. - if (logger.isLoggable(Level.INFO)) { - logger.log(Level.INFO, - "appId :: " + stuffData(applicationContext) + " , " + appTime); - } - - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "TSPolicyConfigurationImpl"); - } - } - - /** - * This method returns this object's policy context identifier. - * - * @return this object's policy context identifier. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the getContextID method signature. The - * exception thrown by the implementation class will be encapsulated - * (during construction) in the thrown PolicyContextException. - */ - public String getContextID() throws PolicyContextException { - - boolean bWasInservice = policyConfiguration.inService(); - - String contextId = policyConfiguration.getContextID(); - - // if the state was inService for our getContextID call, then it must remain - // in that state as its next transitional state (per javadoc table) - if (bWasInservice) { - assertIsInserviceState("getContextID"); - } else { - // state was not inService so make sure it is still NOT in the - // inService state after calling policyConfiguration.getContextID() - assertStateNotInservice("getContextID"); - } - - if (logger.isLoggable(Level.FINER)) { - logger.log(Level.FINER, "contextId =" + contextId); - } - return contextId; - } - - /** - * Used to add permissions to a named role in this PolicyConfiguration. If the - * named Role does not exist in the PolicyConfiguration, it is created as a - * result of the call to this function. - *

    - * It is the job of the Policy provider to ensure that all the permissions - * added to a role are granted to principals "mapped to the role". - *

    - * - * @param roleName - * the name of the Role to which the permissions are to be added. - *

    - * @param permissions - * the collection of permissions to be added to the role. The - * collection may be either a homogenous or heterogenous collection. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the addToRole method signature. The - * exception thrown by the implementation class will be encapsulated - * (during construction) in the thrown PolicyContextException. - */ - public void addToRole(String roleName, PermissionCollection permissions) - throws PolicyContextException { - String permissionType = null; - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "addToRole"); - } - if (roleName == null || permissions == null) - return; - - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - policyConfiguration.addToRole(roleName, permissions); - assertStateNotInservice("addToRole"); - - if (logger.isLoggable(Level.INFO)) { - StringBuffer sbuf = new StringBuffer(""); - int bufLength = 0; - for (Enumeration en = permissions.elements(); en.hasMoreElements();) { - sbuf.append("addToRole :: "); - sbuf.append(applicationContext + " , "); - sbuf.append(appTime + " , "); - Permission p = (Permission) en.nextElement(); - - // Get the permission type, - // valid permission types are - // 1) WebResourcePermission - // 2) WebUserDataPermission - // 3) WebRoleRefPermission - // 4) EJBMethodPermission - // 5) EJBRoleRefPermission - permissionType = getPermissionType(p); - sbuf.append(permissionType + " , "); - sbuf.append(p.getName() + " , "); - sbuf.append(p.getActions()); - logger.log(Level.INFO, sbuf.toString()); - // Re-initialize string buffer. - bufLength = sbuf.length(); - sbuf.delete(0, bufLength); - - if (permissionType.equals("WebResourcePermission") - || permissionType.equals("WebRoleRefPermission") - || permissionType.equals("EJBMethodPermission") - || permissionType.equals("EJBRoleRefPermission")) { - // logged so we can check roleNames and resourcePerms - logger.log(Level.INFO, "MSG_TAG :: " + permissionType + " :: " - + roleName + " :: " + applicationContext + " :: " + p.getName()); - } else { - // logger.log(Level.INFO, "MSG_TAG :: nothing logged for " + - // permissionType + " :: " + roleName + " :: " + applicationContext + - // " :: " + p.getName()); - } - - } - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "addToRole"); - } - } - - /** - * Used to add a single permission to a named role in this - * PolicyConfiguration. If the named Role does not exist in the - * PolicyConfiguration, it is created as a result of the call to this - * function. - *

    - * It is the job of the Policy provider to ensure that all the permissions - * added to a role are granted to principals "mapped to the role". - *

    - * - * @param roleName - * the name of the Role to which the permission is to be added. - *

    - * @param permission - * the permission to be added to the role. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the addToRole method signature. The - * exception thrown by the implementation class will be encapsulated - * (during construction) in the thrown PolicyContextException. - */ - public void addToRole(String roleName, Permission permission) - throws PolicyContextException { - String permissionType = null; - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "addToRole"); - } - if (roleName == null || permission == null) - return; - - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - - policyConfiguration.addToRole(roleName, permission); - assertStateNotInservice("addToRole"); - - // Get the permission type, - // valid permission types are - // 1) WebResourcePermission - // 2) WebUserDataPermission - // 3) WebRoleRefPermission - // 4) EJBMethodPermission - // 5) EJBRoleRefPermission - permissionType = getPermissionType(permission); - if (logger.isLoggable(Level.INFO)) { - String sbuf = new String("addToRole :: " + applicationContext + " , " - + appTime + " , " + permissionType + " , " + permission.getName() - + " , " + permission.getActions()); - logger.log(Level.INFO, sbuf); - } - - if (permissionType.equals("WebResourcePermission") - || permissionType.equals("WebRoleRefPermission") - || permissionType.equals("EJBMethodPermission") - || permissionType.equals("EJBRoleRefPermission")) { - // logged so we can check roleNames and resourcePerms - logger.log(Level.INFO, "MSG_TAG :: " + permissionType + " :: " + roleName - + " :: " + applicationContext + " :: " + permission.getName()); - } else { - // logger.log(Level.INFO, "MSG_TAG :: nothing logged for " + - // permissionType + " :: " + roleName + " :: " + applicationContext + " :: - // " + permission.getName()); - } - - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "addToRole"); - } - } - - /** - * Used to add unchecked policy statements to this PolicyConfiguration. - *

    - * - * @param permissions - * the collection of permissions to be added as unchecked policy - * statements. The collection may be either a homogenous or - * heterogenous collection. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the addToUncheckedPolicy method signature. - * The exception thrown by the implementation class will be - * encapsulated (during construction) in the thrown - * PolicyContextException. - */ - public void addToUncheckedPolicy(PermissionCollection permissions) - throws PolicyContextException { - String permissionType = null; - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "addToUncheckedPolicy"); - } - if (permissions == null) - return; - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - policyConfiguration.addToUncheckedPolicy(permissions); - assertStateNotInservice("addToUncheckedPolicy"); - - if (logger.isLoggable(Level.INFO)) { - StringBuffer sbuf = new StringBuffer(""); - int bufLength = 0; - - for (Enumeration en = permissions.elements(); en.hasMoreElements();) { - sbuf.append("unchecked :: "); - sbuf.append(applicationContext + " , "); - sbuf.append(appTime + " , "); - - Permission p = (Permission) en.nextElement(); - // Get the permission type, - // valid permission types are - // 1) WebResourcePermission - // 2) WebUserDataPermission - // 3) WebRoleRefPermission - // 4) EJBMethodPermission - // 5) EJBRoleRefPermission - permissionType = getPermissionType(p); - - sbuf.append(permissionType + " , "); - sbuf.append(p.getName() + " , "); - sbuf.append(p.getActions()); - - logger.log(Level.INFO, sbuf.toString()); - // Re-initialize string buffer - bufLength = sbuf.length(); - sbuf.delete(0, bufLength); - } - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "addToUncheckedPolicy"); - } - } - - /** - * Used to add a single unchecked policy statement to this - * PolicyConfiguration. - *

    - * - * @param permission - * the permission to be added to the unchecked policy statements. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the addToUncheckedPolicy method signature. - * The exception thrown by the implementation class will be - * encapsulated (during construction) in the thrown - * PolicyContextException. - */ - public void addToUncheckedPolicy(Permission permission) - throws PolicyContextException { - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "addToUncheckedPolicy"); - } - - if (permission == null) - return; - - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - policyConfiguration.addToUncheckedPolicy(permission); - assertStateNotInservice("addToUncheckedPolicy"); - - // Get the permission type, - // valid permission types are - // 1) WebResourcePermission - // 2) WebUserDataPermission - // 3) WebRoleRefPermission - // 4) EJBMethodPermission - // 5) EJBRoleRefPermission - String permissionType = getPermissionType(permission); - if (logger.isLoggable(Level.INFO)) { - logger.log(Level.INFO, - "unchecked :: " + applicationContext + " , " + appTime + " , " - + permissionType + " , " + permission.getName() + " , " - + permission.getActions()); - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "addToUncheckedPolicy"); - } - } - - /** - * Used to add excluded policy statements to this PolicyConfiguration. - *

    - * - * @param permissions - * the collection of permissions to be added to the excluded policy - * statements. The collection may be either a homogenous or - * heterogenous collection. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the addToExcludedPolicy method signature. - * The exception thrown by the implementation class will be - * encapsulated (during construction) in the thrown - * PolicyContextException. - */ - public void addToExcludedPolicy(PermissionCollection permissions) - throws PolicyContextException { - String permissionType = null; - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "addToExcludedPolicy"); - } - if (permissions == null) - return; - - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - policyConfiguration.addToExcludedPolicy(permissions); - assertStateNotInservice("addToExcludedPolicy"); - - if (logger.isLoggable(Level.INFO)) { - StringBuffer sbuf = new StringBuffer(""); - int bufLength = 0; - for (Enumeration en = permissions.elements(); en.hasMoreElements();) { - sbuf.append("excluded :: "); - sbuf.append(applicationContext + " , "); - sbuf.append(appTime + " , "); - Permission p = (Permission) en.nextElement(); - - // Get the permission type, - // valid permission types are - // 1) WebResourcePermission - // 2) WebUserDataPermission - // 3) WebRoleRefPermission - // 4) EJBMethodPermission - // 5) EJBRoleRefPermission - permissionType = getPermissionType(p); - sbuf.append(permissionType + " , "); - sbuf.append(p.getName() + " , "); - sbuf.append(p.getActions()); - logger.log(Level.INFO, sbuf.toString()); - // Re-initialize string buffer. - bufLength = sbuf.length(); - sbuf.delete(0, bufLength); - } - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "addToExcludedPolicy"); - } - } - - /** - * Used to add a single excluded policy statement to this PolicyConfiguration. - *

    - * - * @param permission - * the permission to be added to the excluded policy statements. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the addToExcludedPolicy method signature. - * The exception thrown by the implementation class will be - * encapsulated (during construction) in the thrown - * PolicyContextException. - */ - public void addToExcludedPolicy(Permission permission) - throws PolicyContextException { - String permissionType = null; - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "addToExcludedPolicy"); - } - if (permission == null) - return; - - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - policyConfiguration.addToExcludedPolicy(permission); - assertStateNotInservice("addToExcludedPolicy"); - - // Get the permission type, - // valid permission types are - // 1) WebResourcePermission - // 2) WebUserDataPermission - // 3) WebRoleRefPermission - // 4) EJBMethodPermission - // 5) EJBRoleRefPermission - permissionType = getPermissionType(permission); - if (logger.isLoggable(Level.INFO)) { - logger.log(Level.INFO, - "excluded :: " + applicationContext + " , " + appTime + " , " - + permissionType + " , " + permission.getName() + " , " - + permission.getActions()); - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "addToExcludedPolicy"); - } - } - - /** - * Used to remove a role and all its permissions from this - * PolicyConfiguration. - *

    - * - * @param roleName - * the name of the Role to remove from this PolicyConfiguration. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the removeRole method signature. The - * exception thrown by the implementation class will be encapsulated - * (during construction) in the thrown PolicyContextException. - */ - public void removeRole(String roleName) throws PolicyContextException { - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "removeRole"); - } - if (roleName == null) - return; - - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - policyConfiguration.removeRole(roleName); - assertStateNotInservice("removeRole"); - - if (logger.isLoggable(Level.INFO)) { - logger.log(Level.INFO, "Removed Role :: " + roleName); - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "removeRole"); - } - } - - /** - * Used to remove any unchecked policy statements from this - * PolicyConfiguration. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the removeUncheckedPolicy method signature. - * The exception thrown by the implementation class will be - * encapsulated (during construction) in the thrown - * PolicyContextException. - */ - public void removeUncheckedPolicy() throws PolicyContextException { - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "removeUncheckedPolicy"); - } - - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - policyConfiguration.removeUncheckedPolicy(); - assertStateNotInservice("removeUncheckedPolicy"); - - if (logger.isLoggable(Level.INFO)) { - logger.log(Level.INFO, "Removed all unchecked policy statements"); - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "removeUncheckedPolicy"); - } - } - - /** - * Used to remove any excluded policy statements from this - * PolicyConfiguration. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the removeExcludedPolicy method signature. - * The exception thrown by the implementation class will be - * encapsulated (during construction) in the thrown - * PolicyContextException. - */ - public void removeExcludedPolicy() throws PolicyContextException { - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "removeExcludedPolicy"); - } - - policyConfiguration = pcf.getPolicyConfiguration(applicationContext, false); - policyConfiguration.removeExcludedPolicy(); - assertStateNotInservice("removeExcludedPolicy"); - - if (logger.isLoggable(Level.INFO)) { - logger.log(Level.INFO, "Removed all excluded policy statements"); - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "removeExcludedPolicy"); - } - } - - /** - * This method is used to set to "inService" the state of the policy context - * whose interface is this PolicyConfiguration Object. Only those policy - * contexts whose state is "inService" will be included in the policy contexts - * processed by the Policy.refresh method. A policy context whose state is - * "inService" may be returned to the "open" state by calling the - * getPolicyConfiguration method of the PolicyConfiguration factory with the - * policy context identifier of the policy context. - *

    - * When the state of a policy context is "inService", calling any method other - * than commit, delete, getContextID, or inService on its PolicyConfiguration - * Object will cause an UnsupportedOperationException to be thrown. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" when this method is - * called. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the commit method signature. The exception - * thrown by the implementation class will be encapsulated (during - * construction) in the thrown PolicyContextException. - */ - public void commit() throws PolicyContextException { - // Date date= new Date(); - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "commit"); - } - - boolean bWasInservice = policyConfiguration.inService(); - policyConfiguration.commit(); - - assertIsInserviceState("commit"); - - if (logger.isLoggable(Level.INFO)) { - logger.log(Level.INFO, "PolicyConfiguration.commit() called"); - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "commit"); - } - } - - /** - * Creates a relationship between this configuration and another such that - * they share the same principal-to-role mappings. PolicyConfigurations are - * linked to apply a common principal-to-role mapping to multiple seperately - * manageable PolicyConfigurations, as is required when an application is - * composed of multiple modules. - *

    - * Note that the policy statements which comprise a role, or comprise the - * excluded or unchecked policy collections in a PolicyConfiguration are - * unaffected by the configuration being linked to another. - *

    - * - * @param link - * a reference to a different PolicyConfiguration than this - * PolicyConfiguration. - *

    - * The relationship formed by this method is symetric, transitive and - * idempotent. If the argument PolicyConfiguration does not have a - * different Policy context identifier than this PolicyConfiguration - * no relationship is formed, and an exception, as described below, - * is thrown. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws java.lang.UnsupportedOperationException - * if the state of the policy context whose interface is this - * PolicyConfiguration Object is "deleted" or "inService" when this - * method is called. - * - * @throws java.lang.IllegalArgumentException - * if called with an argument PolicyConfiguration whose Policy - * context is equivalent to that of this PolicyConfiguration. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the linkConfiguration method signature. The - * exception thrown by the implementation class will be encapsulated - * (during construction) in the thrown PolicyContextException. - */ - public void linkConfiguration(PolicyConfiguration link) - throws PolicyContextException { - String contextId = null; - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "linkConfiguration"); - } - - if (link != null) { - contextId = link.getContextID(); - - // Check if the application name already exists - if (applicationLinkTable != null) { - - // Now add the contextId that is being linked to applicationLinkTable - if (!applicationLinkTable.contains(contextId)) { - applicationLinkTable.add(contextId); - } - - // Now add this.applicationContextId to applicationLinkTable - if (!applicationLinkTable.contains(applicationContext)) { - applicationLinkTable.add(applicationContext); - } - } - - if (logger.isLoggable(Level.INFO)) { - StringBuffer sbuf = new StringBuffer(""); - int bufLength = 0; - sbuf.append("link :: "); - for (Enumeration appEnum = applicationLinkTable.elements(); appEnum - .hasMoreElements();) { - String stuffedAppName = stuffData((String) appEnum.nextElement()); - sbuf.append(stuffedAppName); - if (appEnum.hasMoreElements()) - sbuf.append(","); - } - sbuf.append(" : "); - sbuf.append(appTime); - - // Log all the linked application names - logger.log(Level.INFO, sbuf.toString()); - } - } - - // policyConfiguration.linkConfiguration(link); - // Note: - // The Passed varibale "link" may be an instance of - // delegating Provider's PolicyConfiguration, so before - // linking it with Vendor's PolicyConfiguration, first - // get the vendor's equivalent PolicyConfiguration from "link" - - // get contextId from link - String vendorContextId = link.getContextID(); - - // get vendor's Policy configuration from "link" - // Note: pcf is vendor's PolicyConfigurationFactory - PolicyConfiguration vendorPC = pcf.getPolicyConfiguration(vendorContextId, - false); - - // Now link the vendor's PolicyConfiguration - - boolean bWasInservice = policyConfiguration.inService(); - policyConfiguration.linkConfiguration(vendorPC); - - assertStateNotInservice("linkConfiguration"); - - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "linkConfiguration"); - } - } - - /** - * Causes all policy statements to be deleted from this PolicyConfiguration - * and sets its internal state such that calling any method, other than - * delete, getContextID, or inService on the PolicyConfiguration will be - * rejected and cause an UnsupportedOperationException to be thrown. - *

    - * This operation has no affect on any linked PolicyConfigurations other than - * removing any links involving the deleted PolicyConfiguration. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the delete method signature. The exception - * thrown by the implementation class will be encapsulated (during - * construction) in the thrown PolicyContextException. - */ - public void delete() throws PolicyContextException { - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "delete"); - } - - policyConfiguration.delete(); - assertStateNotInservice("delete"); - - if (logger.isLoggable(Level.INFO)) { - logger.log(Level.INFO, "Deleted all policy statements"); - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "delete"); - } - } - - /** - * This method is used to determine if the policy context whose interface is - * this PolicyConfiguration Object is in the "inService" state. - * - * @return true if the state of the associated policy context is "inService"; - * false otherwise. - * - * @throws java.lang.SecurityException - * if called by an AccessControlContext that has not been granted - * the "setPolicy" SecurityPermission. - * - * @throws jakarta.security.jacc.PolicyContextException - * if the implementation throws a checked exception that has not - * been accounted for by the inService method signature. The - * exception thrown by the implementation class will be encapsulated - * (during construction) in the thrown PolicyContextException. - */ - public boolean inService() throws PolicyContextException { - if (logger.isLoggable(Level.FINER)) { - logger.entering("TSPolicyConfigurationImpl", "inService"); - } - - boolean bWasInservice = policyConfiguration.inService(); - - boolean ret = policyConfiguration.inService(); - - // if the state was inService befor our policyConfiguration.inService() - // call, then it must remain in that state as its next transitional - // state (per javadoc table) - if (bWasInservice) { - assertIsInserviceState("inService"); - } else { - // state was not inService so must've been OPEN or DELETED but - // either way, the next state must remain the same so we know - // we should NOT trasition to different state - assertStateNotInservice("inService"); - } - - if (logger.isLoggable(Level.FINE)) { - logger.log(Level.FINE, "PolicyConfiguration.inService() called"); - } - if (logger.isLoggable(Level.FINER)) { - logger.exiting("TSPolicyConfigurationImpl", "inService"); - } - return ret; - } - - public String getPermissionType(Permission permission) { - if (permission instanceof WebResourcePermission) - return "WebResourcePermission"; - else if (permission instanceof WebUserDataPermission) - return "WebUserDataPermission"; - else if (permission instanceof WebRoleRefPermission) - return "WebRoleRefPermission"; - else if (permission instanceof EJBMethodPermission) - return "EJBMethodPermission"; - else if (permission instanceof EJBRoleRefPermission) - return "EJBRoleRefPermission"; - else - return null; - } - - // This method process the input string and stuffs the character twice if - // the processed character is not an alphabet - public static String stuffData(String inputStr) { - - char[] outStr = new char[2048]; - char[] str = inputStr.toCharArray(); - for (int i = 0, j = 0; i < str.length; i++) { - int a = (new Character(str[i])).getNumericValue(str[i]); - - // Don't stuff extra character if the character is an alphabet - // - // Numeric values for alphabets falls in 10 to 35, this includes - // both upper and lower cases - if ((a > 9) && (a < 36)) { - outStr[j++] = str[i]; - - } else { // stuff the character - outStr[j++] = str[i]; - outStr[j++] = str[i]; - } - } - return ((new String(outStr)).trim()); - } - - public PermissionCollection getExcludedPermissions(){ - return policyConfiguration.getExcludedPermissions(); - } - - public PermissionCollection getUncheckedPermissions(){ - return policyConfiguration.getUncheckedPermissions(); - } - - public Map getPerRolePermissions(){ - return policyConfiguration.getPerRolePermissions(); - } - - private void assertIsInserviceState(String callingMethod) { - - try { - if (!policyConfiguration.inService()) { - String msg1 = "ERROR - our policy config should be in the INSERVICE state."; - String msg2 = "In the wrong state after having called: " - + callingMethod; - debugOut(msg1); - debugOut(msg2); - logger.log(Level.SEVERE, msg1); - } - } catch (SecurityException ex) { - String err = "ERROR - got securityException calling policyConfiguration.inService()."; - err += " You likely need to have 'setPolicy' grant set"; - debugOut(err); - debugOut(ex.toString()); - } catch (Exception ex) { - debugOut("ERROR - Exception calling policyConfiguration.inService(): " - + ex.toString()); - ex.printStackTrace(); - } - } - - private void assertStateNotInservice(String callingMethod) { - - try { - if (policyConfiguration.inService()) { - String msg1 = "ERROR - our policy config should not be in the INSERVICE state."; - String msg2 = "In the wrong state after having called: " - + callingMethod; - debugOut(msg1); - debugOut(msg2); - logger.log(Level.SEVERE, msg1); - } - } catch (SecurityException ex) { - String err = "ERROR - got securityException calling policyConfiguration.inService()."; - err += " You likely need to have 'setPolicy' grant set"; - debugOut(err); - debugOut(ex.toString()); - } catch (Exception ex) { - debugOut("ERROR - Exception calling policyConfiguration.inService(): " - + ex.toString()); - ex.printStackTrace(); - } - } - - private void debugOut(String str) { - System.out.println(str); - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSXMLFormatter.java b/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSXMLFormatter.java deleted file mode 100644 index 5f73b052db..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/provider/TSXMLFormatter.java +++ /dev/null @@ -1,213 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/** - * $Id$ - * - * @author Raja Perumal - * 07/13/02 - */ - -package com.sun.ts.tests.jacc.provider; - -import java.util.ResourceBundle; -import java.util.logging.Handler; -import java.util.logging.Level; -import java.util.logging.LogRecord; -import java.util.logging.XMLFormatter; - -/** - * TSXMLFormatter formats TSLogRecord in XML format. - * - */ -public class TSXMLFormatter extends XMLFormatter { - - private String contextId; - - /** - * Override parent class format method - * - * @param lrecord - * the LogRecord to be formatted. - * @return a formatted log record - */ - public String format(LogRecord lrecord) { - - String message = lrecord.getMessage(); - Level level = lrecord.getLevel(); - TSLogRecord record = new TSLogRecord(level, message); - - return format(record); - } - - /** - * Format the given message to XML. - * - * @param record - * the log record to be formatted. - * @return a formatted log record - */ - public String format(TSLogRecord record) { - - // TSLogRecord record = (TSLogRecord)lrecord; - StringBuffer sb = new StringBuffer(500); - sb.append("\n"); - - sb.append(" "); - sb.append(record.getSequenceNumber()); - sb.append("\n"); - - sb.append(" "); - sb.append(record.getContextId()); - sb.append("\n"); - - sb.append(" "); - escape(sb, record.getLevel().toString()); - sb.append("\n"); - - if (record.getSourceClassName() != null) { - sb.append(" "); - escape(sb, record.getSourceClassName()); - sb.append("\n"); - } - - if (record.getSourceMethodName() != null) { - sb.append(" "); - escape(sb, record.getSourceMethodName()); - sb.append("\n"); - - } - - sb.append(" "); - sb.append(record.getThreadID()); - sb.append("\n"); - - if (record.getMessage() != null) { - // Format the message string and its accompanying parameters. - String message = formatMessage(record); - sb.append(" "); - escape(sb, message); - sb.append(""); - sb.append("\n"); - } - - // If the message is being localized, output the key, resource - // bundle name, and params. - ResourceBundle bundle = record.getResourceBundle(); - try { - if (bundle != null && bundle.getString(record.getMessage()) != null) { - sb.append(" "); - escape(sb, record.getMessage()); - sb.append("\n"); - - sb.append(" "); - escape(sb, record.getResourceBundleName()); - sb.append("\n"); - - Object parameters[] = record.getParameters(); - for (int i = 0; i < parameters.length; i++) { - sb.append(" "); - try { - escape(sb, parameters[i].toString()); - } catch (Exception ex) { - sb.append("???"); - } - sb.append("\n"); - } - } - } catch (Exception ex) { - // The message is not in the catalog. Drop through. - } - - if (record.getThrown() != null) { - // Report on the state of the throwable. - Throwable th = record.getThrown(); - sb.append(" \n"); - sb.append(" "); - escape(sb, th.toString()); - sb.append("\n"); - - StackTraceElement trace[] = th.getStackTrace(); - for (int i = 0; i < trace.length; i++) { - StackTraceElement frame = trace[i]; - sb.append(" \n"); - sb.append(" "); - escape(sb, frame.getClassName()); - sb.append("\n"); - - sb.append(" "); - escape(sb, frame.getMethodName()); - sb.append("\n"); - - // Check for a line number. - if (frame.getLineNumber() >= 0) { - sb.append(" "); - sb.append(frame.getLineNumber()); - sb.append("\n"); - } - sb.append(" \n"); - } - sb.append(" \n"); - } - - sb.append("\n"); - return sb.toString(); - } - - // Append to the given StringBuffer an escaped version of the - // given text string where XML special characters have been escaped. - // For a null string we appebd "" - private void escape(StringBuffer sb, String text) { - if (text == null) { - text = ""; - } - - for (int i = 0; i < text.length(); i++) { - char ch = text.charAt(i); - if (ch == '<') { - sb.append("<"); - } else if (ch == '>') { - sb.append(">"); - } else if (ch == '&') { - sb.append("&"); - } else { - sb.append(ch); - } - } - } - - /** - * Return the header string for a set of XML formatted records. - * - * @param h - * The target handler. - * @return header string - */ - public String getHead(Handler h) { - StringBuffer sb = new StringBuffer(); - sb.append("\n"); - // sb.append("\n"); - sb.append("\n"); - return sb.toString(); - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/AccessToAll.jsp b/jacc/src/main/java/com/sun/ts/tests/jacc/util/AccessToAll.jsp deleted file mode 100644 index 032bded073..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/AccessToAll.jsp +++ /dev/null @@ -1,58 +0,0 @@ -<%-- - - Copyright (c) 2006, 2018 Oracle and/or its affiliates. All rights reserved. - - This program and the accompanying materials are made available under the - terms of the Eclipse Public License v. 2.0, which is available at - http://www.eclipse.org/legal/epl-2.0. - - This Source Code may also be made available under the following Secondary - Licenses when the conditions for such availability set forth in the - Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - version 2 with the GNU Classpath Exception, which is available at - https://www.gnu.org/software/classpath/license.html. - - SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - ---%> - - - -<%@ page language="java" %> - - - JSP with WildCard Auth Constraint - -

    JSP with WildCard Auth Constraint

    - - <% - - out.println("The user principal is: " + request.getUserPrincipal().getName() + "
    "); - out.println("getRemoteUser(): " + request.getRemoteUser() + "
    " ); - - if (request.isUserInRole("ADM")){ - out.println("USR_IN_ROLE_ADM"); - }else - out.println("USR_NOT_IN_ROLE_ADM"); - - if (request.isUserInRole("MGR")){ - out.println("USR_IN_ROLE_MGR"); - }else - out.println("USR_NOT_IN_ROLE_MGR"); - - if (request.isUserInRole("EMP")){ - out.println("USR_IN_ROLE_EMP"); - }else - out.println("USR_NOT_IN_ROLE_EMP"); - - if (request.isUserInRole("VP")){ - out.println("USR_IN_ROLE_VP"); - }else - out.println("USR_NOT_IN_ROLE_VP"); - - %> - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/FetchLogClient.java b/jacc/src/main/java/com/sun/ts/tests/jacc/util/FetchLogClient.java deleted file mode 100644 index 485d00c51b..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/FetchLogClient.java +++ /dev/null @@ -1,218 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/* - * @(#)FetchLogClient.java 1.4 03/05/16 - */ - -package com.sun.ts.tests.jacc.util; - -import java.io.InputStream; -import java.io.ObjectInputStream; -import java.io.ObjectOutputStream; -import java.net.HttpURLConnection; -import java.net.URL; -import java.util.Collection; -import java.util.Iterator; -import java.util.Properties; -import java.util.logging.FileHandler; -import java.util.logging.Level; - -import com.sun.javatest.Status; -import com.sun.ts.lib.harness.EETest; -import com.sun.ts.lib.porting.TSURL; -import com.sun.ts.lib.util.TestUtil; -import com.sun.ts.tests.jacc.provider.TSLogger; -import com.sun.ts.tests.jacc.provider.TSXMLFormatter; - -public class FetchLogClient extends EETest { - private Properties props = null; - - private TSURL tsURL = new TSURL(); - - private String webServerHost = "unknown"; - - private int webServerPort = 8000; - - private String SERVLET = "/jaccRoot/FetchLogs"; - - private String logFileLocation = null; - - public static void main(String args[]) { - FetchLogClient theTests = new FetchLogClient(); - Status s = theTests.run(args, System.out, System.err); - s.exit(); - } - - /** - * @class.setup_props: log.file.location; webServerHost; webServerPort; - * - * - */ - public void setup(String[] args, Properties p) throws Exception { - props = p; - boolean pass = true; - try { - logFileLocation = p.getProperty("log.file.location"); - if (logFileLocation == null) - pass = false; - - webServerHost = p.getProperty("webServerHost"); - if (webServerHost == null) - pass = false; - else if (webServerHost.equals("")) - pass = false; - - try { - webServerPort = Integer.parseInt(p.getProperty("webServerPort")); - } catch (Exception e) { - TestUtil.printStackTrace(e); - - pass = false; - } - - TestUtil.logMsg("webServerHost = " + webServerHost); - TestUtil.logMsg("webServerPort = " + webServerPort); - TestUtil.logMsg("log.file.location = " + logFileLocation); - - if (!pass) { - TestUtil - .logErr("Please specify web server host & port" + "in ts.jte file"); - throw new Exception("Setup Failed: WebServer host/port not set"); - } - TestUtil.logMsg("Setup ok"); - } catch (Exception e) { - throw new Exception("Setup Failed:", e); - } - - } - - public void cleanup() throws Exception { - } - - /** - * testName: fetchLogClientTest - * - * @assertion: This is a sample test used for fetching log messages created by - * TSlogger. - */ - public void fetchLogClientTest() throws Exception { - - long seqNum = 0L; - String contextId = null; - Collection recordCollection = null; - Properties props = null; - URL url = null; - - try { - - // Create a tsLogger - TSLogger tsLogger = TSLogger.getTSLogger("jacc"); - FileHandler tsFileHandler = new FileHandler( - logFileLocation + "/jacc_log.txt"); - tsFileHandler.setFormatter(new TSXMLFormatter()); - tsLogger.addHandler(tsFileHandler); - - // create some log messages - tsLogger.log(Level.INFO, "message-1", "jacc_ctx"); - tsLogger.log(Level.INFO, "message-2", "jacc_ctx"); - tsLogger.log(Level.INFO, "PolicyConfigurationFactory instantiated", - "jacc_ctx"); - tsLogger.log(Level.INFO, "message-4", "new_ctx"); - tsLogger.log(Level.INFO, "message-5", "new_ctx"); - - tsFileHandler.close(); - - url = tsURL.getURL("http", webServerHost, webServerPort, SERVLET); - - props = new Properties(); - props.put("LogFilePath", logFileLocation + "/jacc_log.txt"); - props.put("LogQueryString", "findLogsByContextId"); - props.put("LogQueryParams", "jacc_ctx"); - - HttpURLConnection conn = (HttpURLConnection) url.openConnection(); - conn.setDoOutput(true); - conn.setDoInput(true); - conn.setUseCaches(false); - conn.setRequestProperty("Content-Type", - "java-internal/" + props.getClass().getName()); - - ObjectOutputStream oos = new ObjectOutputStream(conn.getOutputStream()); - oos.writeObject(props); - oos.flush(); - oos.close(); - - InputStream is = conn.getInputStream(); - ObjectInputStream ois = new ObjectInputStream(is); - - String header = (String) ois.readObject(); - - // read the header information, - // - // if the header is equal to "RecordCollection header" - // then the remaining data is a recordCollection object - // else report log file processing failure. - // - if (header.equals("RecordCollection header")) { - recordCollection = (Collection) ois.readObject(); - - printCollection(recordCollection); - - } else { - TestUtil.logErr("Log File processing failed"); - TestUtil.logErr("Log file does not exists in the server" - + " or you don't have read permission for log file"); - TestUtil.logErr("Check permissions for log file "); - TestUtil.logErr("See User guide for Configuring log file permissions"); - } - - ois.close(); - - } catch (Exception e) { - TestUtil.logErr(e.getMessage()); - TestUtil.printStackTrace(e); - } - - } - - public void printCollection(Collection recordCollection) { - RecordEntry recordEntry = null; - Iterator iterator = recordCollection.iterator(); - - while (iterator.hasNext()) { - recordEntry = (RecordEntry) iterator.next(); - printRecordEntry(recordEntry); - } - } - - public void printRecordEntry(RecordEntry rec) { - TestUtil.logMsg("*******Log Content*******"); - TestUtil.logMsg("seqence no =" + rec.getSequenceNumber()); - TestUtil.logMsg("ContextId =" + rec.getContextId()); - TestUtil.logMsg("Message =" + rec.getMessage()); - if (rec.getClassName() != null) - TestUtil.logMsg("Class name =" + rec.getClassName()); - if (rec.getMethodName() != null) - TestUtil.logMsg("Method name =" + rec.getMethodName()); - if (rec.getLevel() != null) - TestUtil.logMsg("Level =" + rec.getLevel()); - if (rec.getThrown() != null) - TestUtil.logMsg("Thrown =" + rec.getThrown()); - TestUtil.logMsg(""); - - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/FetchLogs.java b/jacc/src/main/java/com/sun/ts/tests/jacc/util/FetchLogs.java deleted file mode 100644 index ba4450535e..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/FetchLogs.java +++ /dev/null @@ -1,747 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/* - * @(#)FetchLogs.java 1.10 04/02/27 - */ - -package com.sun.ts.tests.jacc.util; - -import java.io.ByteArrayInputStream; -import java.io.File; -import java.io.FileInputStream; -import java.io.IOException; -import java.io.ObjectOutputStream; -import java.io.OutputStream; -import java.io.SequenceInputStream; -import java.util.Collection; -import java.util.Enumeration; -import java.util.Iterator; -import java.util.Properties; -import java.util.StringTokenizer; -import java.util.Vector; - -import javax.xml.parsers.DocumentBuilder; -import javax.xml.parsers.DocumentBuilderFactory; -import javax.xml.parsers.ParserConfigurationException; - -import org.w3c.dom.Document; -import org.w3c.dom.Element; -import org.w3c.dom.Node; -import org.w3c.dom.NodeList; -import org.xml.sax.SAXException; - -import com.sun.ts.lib.util.TestUtil; - -import jakarta.servlet.ServletConfig; -import jakarta.servlet.ServletException; -import jakarta.servlet.http.HttpServlet; -import jakarta.servlet.http.HttpServletRequest; -import jakarta.servlet.http.HttpServletResponse; - -/** - * - * @deprecated This class should not be used anymore and is here for historical - * purposes. - * - * FetchLogs servlet is used for collecting logs from the server. - * - * FetchLogs servlet gets the logfile location from its input - * parameters and locates the log file in the server, parses it and - * extracts a subset of logs based on various parameters such as - * "contextId" or "sequenceNumber" and builds Collection of logs of - * type (RecordEntry) and returns the Collection - * - */ -public class FetchLogs extends HttpServlet { - Collection recordCollection = new Vector(); - - Collection appIdRecordCollection = new Vector(); - - Collection linkRecordCollection = new Vector(); - - Collection appSpecificRecordCollection = new Vector(); - - public void init(ServletConfig config) throws ServletException { - super.init(config); - } - - public void doPost(HttpServletRequest request, HttpServletResponse response) - throws ServletException, IOException { - doGet(request, response); - } - - public void doGet(HttpServletRequest request, HttpServletResponse response) - throws ServletException, IOException { - Properties props = new Properties(); - File logfile = null; - - try { - DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory - .newInstance(); - DocumentBuilder documentBuilder = documentBuilderFactory - .newDocumentBuilder(); - - OutputStream outStream = response.getOutputStream(); - ObjectOutputStream ostream = new ObjectOutputStream(outStream); - String logFileLocation = request.getParameter("LogFilePath"); - - if (logFileLocation != null) - logfile = new File(logFileLocation); - - if ((logfile == null) || (!logfile.exists())) { - String header = "Log file does not exists"; - ostream.writeObject(header); - - TestUtil.logErr("Log File : " + logFileLocation + " does not exists"); - TestUtil.logErr("Check permissions for log file "); - TestUtil.logErr("See User guide for Configuring log file permissions"); - } else { - // The generated log file jacc_log.txt is an ever growing - // log file, since it is an ever growing log file, - // there will not be any end tag at the end of the - // log file. - // - // This will cause the SAXParser to throw fatal error message - // "XML Document structures must start and end with the - // same entity" - // - // In order to avoid this error message the FileInputStream - // should have the end tag , this can be achieved by - // creating a SequenceInputStream which includes a - // FileInputStream and a ByteArrayInputStream, where the - // ByteArrayInputStream contains the bytes for - // - String endLogTag = ""; - ByteArrayInputStream bais = new ByteArrayInputStream( - endLogTag.getBytes()); - SequenceInputStream sis = new SequenceInputStream( - new FileInputStream(logFileLocation), bais); - - Document document = documentBuilder.parse(sis); - Element rootElement = document.getDocumentElement(); - NodeList nodes = rootElement.getChildNodes(); - - String queryString = request.getParameter("LogQueryString"); - String queryParams = request.getParameter("LogQueryParams"); - // TestUtil.logMsg("LogFilePath =" + logFileLocation); - // TestUtil.logMsg("LogQueryString =" + queryString); - // TestUtil.logMsg("LogQueryParams =" + queryParams); - - // Add a header to inform the client that the following - // data is a recordCollection Object. - ostream.writeObject(new String("RecordCollection header")); - - // Get appId records(appId records are records which identifies - // the records with application name and time stamp ). - // - // for extracting appId records, process each record and - // search whether the record starts with "appId" string. - // - // if the log records starts with "appId" - // i.e if (log records starts with "appId") then - // add the records to appIdRecordCollection - // else if (log records starts with "link") then - // add the records to linkRecordCollection - // else - // add the records to recordCollection - // - // Note: In the process of locating appId records - // the remaining records are also processed and - // stored as "linkRecordCollection" and - // "recordCollection" based on the content of the records - if (queryString.equals("getAppSpecificRecordCollection")) { - // This call populates both appIdRecordCollection and - // the rest of record collection - appIdRecordCollection = getAppIdRecordCollection("appId", nodes); - // printCollection(appIdRecordCollection); - - // write recordCollection - ostream.writeObject(recordCollection); - // printCollection(recordCollection); - - // Parse through all appId records and - // find the current application name - String applicationName = getCurrentApplicationName(); - - // Parse all link records and find all the - // applications that are linked to the current application - Vector linkedApplicationNames = getLinkedApplicationNames(); - - // Using the application names, isolate the - // application specific logs from the rest of the logs - Collection newAppSpecificRecordCollection = getAppSpecificRecordCollection( - applicationName, linkedApplicationNames); - // printCollection(newAppSpecificRecordCollection); - - // write applicaiton specific record Collection - ostream.writeObject(newAppSpecificRecordCollection); - } else { - recordCollection = processLogs(queryString, queryParams, nodes); - // write recordCollection - ostream.writeObject(recordCollection); - } - // printCollection(appIdRecordCollection); - // write appIdRecordCollection - // ostream.writeObject(appIdRecordCollection); - } - ostream.flush(); - ostream.close(); - } catch (ParserConfigurationException pce) { - TestUtil.logErr("PaserConfigurationException :" + pce.getMessage()); - TestUtil.printStackTrace(pce); - throw new ServletException(pce.getMessage(), pce); - } catch (SAXException se) { - TestUtil.logErr("SAXException :" + se.getMessage()); - TestUtil.printStackTrace(se); - throw new ServletException(se.getMessage(), se); - } catch (IOException ioe) { - TestUtil.logErr("IOException :" + ioe.getMessage()); - TestUtil.printStackTrace(ioe); - ioe.printStackTrace(); - throw new ServletException("log file not found :" + ioe.getMessage(), - ioe); - } catch (SecurityException se) { - TestUtil.logErr("SecurityException :" + se.getMessage()); - TestUtil.printStackTrace(se); - se.printStackTrace(); - throw new ServletException(se.getMessage(), se); - } catch (Exception e) { - TestUtil.logErr("Exception :" + e.getMessage()); - TestUtil.printStackTrace(e); - throw new ServletException(e.getMessage(), e); - } - } - - public Collection processLogs(String queryString, String queryParams, - NodeList nodes) throws Exception { - Collection recordCollection = null; - if (queryString.equals("findLogsByContextId")) { - recordCollection = findLogsByContextId(queryParams, nodes); - } else if (queryString.equals("findLogsBySequenceNumber")) { - recordCollection = findLogsBySequenceNumber(queryParams, nodes); - } else if (queryString.equals("findLogsBySubStringMatch")) { - recordCollection = findLogsBySubStringMatch(queryParams, nodes); - } else if (queryString.equals("findLogsByPrefix")) { - recordCollection = findLogsByPrefix(queryParams, nodes); - } else if (queryString.equals("pullAllLogRecords")) { - recordCollection = pullAllLogRecords(queryParams, nodes); - } else { - TestUtil.logErr("InCorrect query string :+queryString"); - throw new Exception("InCorrect query string :" + queryString); - } - return recordCollection; - } - - /** - * Locates the logs based on the given contextId - */ - public Collection findLogsByContextId(String queryParams, NodeList nodes) - throws Exception { - Collection recordCollection = new Vector(); - String nodeName; - String nodeValue; - Node childNode; - Node recordNode; - NodeList recordNodeChildren; - - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - // get all the child nodes for the first record - recordNodeChildren = recordNode.getChildNodes(); - - for (int j = 0; j < recordNodeChildren.getLength(); j++) { - childNode = recordNodeChildren.item(j); - nodeName = childNode.getNodeName(); - if (nodeName.equals("contextId")) { - nodeValue = getText(childNode); - if (nodeValue.equals(queryParams)) { - // create a new record entry and - // add it to the collection - RecordEntry recordEntry = new RecordEntry(recordNode); - recordCollection.add(recordEntry); - } - } - } - } - return recordCollection; - } - - /** - * Fetches all JACC specific server side logs from jacc_log.txt - */ - public Collection pullAllLogRecords(String queryParams, NodeList nodes) - throws Exception { - Collection recordCollection = new Vector(); - Node childNode; - Node recordNode; - NodeList recordNodeChildren; - - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - // get all the child nodes for the first record - recordNodeChildren = recordNode.getChildNodes(); - for (int j = 0; j < recordNodeChildren.getLength(); j++) { - childNode = recordNodeChildren.item(j); - // create a new record entry and - // add it to the collection - RecordEntry recordEntry = new RecordEntry(recordNode); - recordCollection.add(recordEntry); - } - } - return recordCollection; - } - - /** - * Locates the logs based on SubStringMatch - */ - public Collection findLogsBySubStringMatch(String queryParams, NodeList nodes) - throws Exception { - Collection recordCollection = new Vector(); - String nodeName; - String nodeValue; - Node childNode; - Node recordNode; - NodeList recordNodeChildren; - - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - // get all the child nodes for the first record - recordNodeChildren = recordNode.getChildNodes(); - for (int j = 0; j < recordNodeChildren.getLength(); j++) { - childNode = recordNodeChildren.item(j); - nodeName = childNode.getNodeName(); - if (nodeName.equals("message")) { - nodeValue = getText(childNode); - if (nodeValue.indexOf(queryParams) > 0) { - // create a new record entry and - // add it to the collection - RecordEntry recordEntry = new RecordEntry(recordNode); - recordCollection.add(recordEntry); - } - } - } - } - return recordCollection; - } - - /** - * Locates the logs based on the given prefix string - */ - public Collection findLogsByPrefix(String queryParams, NodeList nodes) - throws Exception { - Collection recordCollection = new Vector(); - String nodeName; - String nodeValue; - Node childNode; - Node recordNode; - NodeList recordNodeChildren; - - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - // get all the child nodes for the first record - recordNodeChildren = recordNode.getChildNodes(); - for (int j = 0; j < recordNodeChildren.getLength(); j++) { - childNode = recordNodeChildren.item(j); - nodeName = childNode.getNodeName(); - if (nodeName.equals("message")) { - nodeValue = getText(childNode); - if (nodeValue.startsWith(queryParams)) { - // create a new record entry that matches the - // query criteria - RecordEntry matchingRecordEntry = new RecordEntry(recordNode); - recordCollection.add(matchingRecordEntry); - } - } - } - } - return recordCollection; - } - - /** - * This method retrieves the appId records. - * - * i.e if (log records starts with "appId") then add the records to - * appIdRecordCollection else add the records to recordCollection - * - * Note: In the process of locating appId records the remaining records are - * also isolated and stored in a collection called "recordCollection" - */ - public Collection getAppIdRecordCollection(String queryParams, NodeList nodes) - throws Exception { - String nodeName; - String nodeValue; - Node childNode; - Node recordNode; - NodeList recordNodeChildren; - - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - // get all the child nodes for the first record - recordNodeChildren = recordNode.getChildNodes(); - for (int j = 0; j < recordNodeChildren.getLength(); j++) { - childNode = recordNodeChildren.item(j); - nodeName = childNode.getNodeName(); - if (nodeName.equals("message")) { - nodeValue = getText(childNode); - if (nodeValue.startsWith(queryParams)) { - // create a new record entry that matches the - // query criteria i.e "appId" - RecordEntry matchingRecordEntry = new RecordEntry(recordNode); - this.appIdRecordCollection.add(matchingRecordEntry); - } else if (nodeValue.startsWith("link")) { - // create a new record entry for link records - RecordEntry linkRecordEntry = new RecordEntry(recordNode); - this.linkRecordCollection.add(linkRecordEntry); - } else { - // create a new record entry that do not - // match the query criteria - RecordEntry nonMatchingRecordEntry = new RecordEntry(recordNode); - this.recordCollection.add(nonMatchingRecordEntry); - } - } - } - } - return appIdRecordCollection; - } - - /** - * Locates logs based on the given sequenceNumber - */ - public Collection findLogsBySequenceNumber(String queryParams, NodeList nodes) - throws Exception { - Collection recordCollection = new Vector(); - String nodeName; - String nodeValue; - Node childNode; - Node recordNode; - NodeList recordNodeChildren; - int sequenceNumber = (new Integer(queryParams)).intValue(); - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - // get all the child nodes for the first record - recordNodeChildren = recordNode.getChildNodes(); - for (int j = 0; j < recordNodeChildren.getLength(); j++) { - childNode = recordNodeChildren.item(j); - nodeName = childNode.getNodeName(); - if (nodeName.equals("sequence")) { - nodeValue = getText(childNode); - int nodeValueInInt = (new Integer(nodeValue)).intValue(); - if (nodeValueInInt == sequenceNumber) { - // create a new record entry and - // add it to the collection - RecordEntry recordEntry = new RecordEntry(recordNode); - recordCollection.add(recordEntry); - } - } - } - } - return recordCollection; - } - - public String getText(Node textNode) { - String result = ""; - NodeList nodes = textNode.getChildNodes(); - for (int i = 0; i < nodes.getLength(); i++) { - Node node = nodes.item(i); - if (node.getNodeType() == Node.TEXT_NODE) { - result = node.getNodeValue(); - break; - } - } - return result; - } - - public void printCollection(Collection recordCollection) { - RecordEntry recordEntry = null; - Iterator iterator = recordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (RecordEntry) iterator.next(); - printRecordEntry(recordEntry); - } - } - - public void printRecordEntry(RecordEntry rec) { - System.out.println("*******Log Content*******"); - System.out.println("seqence no =" + rec.getSequenceNumber()); - System.out.println("ContextId =" + rec.getContextId()); - System.out.println("Message =" + rec.getMessage()); - if (rec.getClassName() != null) - System.out.println("Class name =" + rec.getClassName()); - if (rec.getMethodName() != null) - System.out.println("Method name =" + rec.getMethodName()); - if (rec.getLevel() != null) - System.out.println("Level =" + rec.getLevel()); - if (rec.getThrown() != null) - System.out.println("Thrown =" + rec.getThrown()); - System.out.println(); - - } - - // This method returns the current application name by analysing - // all the appId log records. - // - // The appId log record contains the Application name and the timeStamp - // For example, let us examine the following 3 appId log records. - // - // appId :: MyApp , 1058312446598 - // appId :: App , 1058312463706 - // appId :: adminapp , 1058312480593 - // - // In the above 3 appId records - // a) the first field "appId :: " identifies this as a appId record - // b) the second field indicates the application name - // c) the third field refers to the timestamp at which the record was - // created. - // - // By comparing the timestamps we can locate the latest of all appId records - // and return the application name associated with it. - public String getCurrentApplicationName() { - RecordEntry recordEntry = null; - String temp = null; - String timeStampString = null; - String appName = null; - String prevAppName = null; - long prevRecordTimeStamp = 0; - long recordTimeStamp = 0; - String[] tokenArray = new String[2]; - - if (appIdRecordCollection == null) { - TestUtil.logMsg("Record collection empty : No appId records found"); - return null; - } - - Iterator iterator = appIdRecordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (RecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - // Remove the string "appId :: " from the message - temp = message.substring(9, message.length()); - - // Get appName and timeStampString - tokenArray = temp.split(" , "); - appName = tokenArray[0]; - timeStampString = tokenArray[1]; - - // now unstuff application name - appName = unStuffData(appName); - - // TestUtil.logMsg("appName ="+appName); - // TestUtil.logMsg("timeStampString ="+timeStampString); - - // Get long value from the string - recordTimeStamp = (new Long(timeStampString)).longValue(); - if (recordTimeStamp < prevRecordTimeStamp) { - recordTimeStamp = prevRecordTimeStamp; - appName = prevAppName; - } - } - return appName; - } - - // This method returns the linked application names by analysing - // all the link log records. - // - // The link log record contains the list of Application names - // and the timeStamp. - // For example, let us examine the following 2 link log records. - // - // link :: MyApp,SecondApp : 1058312446598 - // link :: App,SecondApp,ThirdApp : 1058312463706 - // - // In the above 3 link records - // a) the first field "link :: " identifies this as a link record - // b) the second field indicates the application names that are - // linked to. - // Note: Linked application names are idenified using - // the comma separator. - // c) the last field indicates the timestamp at which the record was - // created. - // - // By comparing the timestamps we can locate the latest link records - // and return the application names linked to it. - public Vector getLinkedApplicationNames() { - RecordEntry recordEntry = null; - String temp = null; - String timeStampString = null; - String appNames = null; - String prevAppName = null; - long prevRecordTimeStamp = 0; - long recordTimeStamp = 0; - String[] tokenArray = new String[2]; - Vector applicationNames = new Vector(); - - if (linkRecordCollection == null) { - TestUtil.logMsg("Record collection empty : No link records found"); - return null; - } - - Iterator iterator = linkRecordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (RecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - // Remove the string "link :: " from the message - temp = message.substring(8, message.length()); - - // Get appName and timeStampString - tokenArray = temp.split(" : "); - appNames = tokenArray[0]; - timeStampString = tokenArray[1]; - - // now unstuff application name - appNames = unStuffData(appNames); - - // Get long value from the string - recordTimeStamp = (new Long(timeStampString)).longValue(); - if (recordTimeStamp < prevRecordTimeStamp) { - recordTimeStamp = prevRecordTimeStamp; - appNames = prevAppName; - } - } - - StringTokenizer strtoken; - - if (appNames != null) { - // create a vector with applicationNames - strtoken = new StringTokenizer(appNames, ","); - if (appNames.indexOf(",") > 0) { - // if the appNames string contains multiple applications - // add all of them to the vector applicationNames - while (strtoken.hasMoreTokens()) { - applicationNames.add(strtoken.nextToken()); - } - } else if (appNames != null) { - // if the appNames string contains only one application - // add it to the vector applicationNames - applicationNames.add(appNames); - } - } else { - // else return null - return null; - } - - return applicationNames; - } - - /* - * This method reads all non-appId records from the record collection and - * isolates current appSpecific records from the rest using the given - * applicationName and the linkedApplicationNames. - */ - public Collection getAppSpecificRecordCollection(String applicationName, - Vector linkedApplicationNames) { - RecordEntry recordEntry = null; - - if (recordCollection == null) { - TestUtil.logMsg("Record collection empty : No records found"); - return null; - } - Iterator iterator = this.recordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (RecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - // if recordEntry contains the specified applicationName - // Add the record to appSpecificRecordCollection - if (message.indexOf(applicationName) > 0) { - appSpecificRecordCollection.add(recordEntry); - } - } - - if (linkedApplicationNames != null) { - // retrieve all the records associated with - // linked applications. - for (Enumeration appEnum = linkedApplicationNames.elements(); appEnum - .hasMoreElements();) { - applicationName = (String) appEnum.nextElement(); - - iterator = this.recordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (RecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - // if recordEntry contains the specified applicationName - // Add the record to appSpecificRecordCollection - if (message.indexOf(applicationName) > 0) { - appSpecificRecordCollection.add(recordEntry); - } - } - - } - } - return appSpecificRecordCollection; - } - - // This method tokenize the given string and - // return first token and the remaining - // string a string array based on the given delimeter - public static String[] getTokens(String str, String delimeter) { - String[] array = new String[2]; - StringTokenizer strtoken; - - // Get first token and the remaining string - strtoken = new StringTokenizer(str, delimeter); - if (str.indexOf(delimeter) > 0) { - array[0] = strtoken.nextToken(); - array[1] = str.substring(array[0].length() + 3, str.length()); - } - // TestUtil.logMsg("Input String ="+str); - // TestUtil.logMsg("array[0] ="+array[0]); - // TestUtil.logMsg("array[1] ="+array[1]); - return array; - } - - // This will remove the stuffed characters in the input string - // Note: The non-alphabets in the input string was already stuffed by - // the same character, this method unstuff those characters - public static String unStuffData(String inputStr) { - char[] outStr = new char[2048]; - char[] str = inputStr.toCharArray(); - for (int i = 0, j = 0; i < str.length;) { - - int a = (new Character(str[i])).getNumericValue(str[i]); - - // Don't stuff extra character if the character is an alphabet - // - // Numeric values for alphabets falls in 10 to 35, this includes - // both upper and lower cases - if ((a > 9) && (a < 36)) { - outStr[j++] = str[i++]; - } else { // unstuff the character - outStr[j++] = str[i++]; // just skip the next character - // Remove only the stuffed characters not data separators - if ((i + 1) < str.length) { - if (str[i + 1] == str[i]) { - // just skip the next character - i++; - } - } - i++; - } - } - - return ((new String(outStr)).trim()); - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/LogFileProcessor.java b/jacc/src/main/java/com/sun/ts/tests/jacc/util/LogFileProcessor.java deleted file mode 100644 index 35866e67ff..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/LogFileProcessor.java +++ /dev/null @@ -1,1447 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.util; - -import java.io.ByteArrayInputStream; -import java.io.File; -import java.io.FileInputStream; -import java.io.SequenceInputStream; -import java.security.Permission; -import java.security.PermissionCollection; -import java.security.Permissions; -import java.util.Collection; -import java.util.Enumeration; -import java.util.Iterator; -import java.util.Properties; -import java.util.StringTokenizer; -import java.util.Vector; - -import javax.xml.parsers.DocumentBuilder; -import javax.xml.parsers.DocumentBuilderFactory; - -import org.w3c.dom.Document; -import org.w3c.dom.Element; -import org.w3c.dom.Node; -import org.w3c.dom.NodeList; - -import com.sun.ts.lib.util.TestUtil; - -import jakarta.security.jacc.EJBMethodPermission; -import jakarta.security.jacc.EJBRoleRefPermission; -import jakarta.security.jacc.WebResourcePermission; -import jakarta.security.jacc.WebRoleRefPermission; -import jakarta.security.jacc.WebUserDataPermission; - -/** - * - * @author Raja Perumal - */ -/** - * LogFileProcessor does the following operations - * - * 1) Fetches log records from JACCLog.txt - * - * 2) Checks for the existance of search string in the log for example to verify - * whether server log contains a string "Java EE rocks" use the following code - * - * LogFileProcessor logProcessor = new LogFileProcessor(properties); boolean - * contains = logProcessor.verifyLogContains("Java EE rocks"); - * - * where "properties" contains the following key value pair 1) log.file.location - * - * 3) Prints the collection of log records. - * - */ -public class LogFileProcessor { - - private String logFileLocation = null; - - private Collection recordCollection = new Vector(); - - private Collection appIdRecordCollection = new Vector(); - - private Collection linkRecordCollection = new Vector(); - - private Collection appSpecificRecordCollection = new Vector(); - - private Permissions appSpecificUnCheckedPermissions = new Permissions(); - - private Permissions appSpecificExcludedPermissions = new Permissions(); - - private Permissions appSpecificAddToRolePermissions = new Permissions(); - - public LogFileProcessor() { - } - - public LogFileProcessor(Properties props) { - setup(props); - } - - /** - * setup method - */ - public void setup(Properties p) { - boolean pass = true; - try { - if (p != null) { - TestUtil - .logMsg("setting logFileLocation based on passed in Properties"); - logFileLocation = p.getProperty("log.file.location"); - } else { - TestUtil.logMsg( - "setting logFileLocation based on passed in System.getProperty()"); - logFileLocation = System.getProperty("log.file.location"); - } - if (logFileLocation == null) { - pass = false; - } - TestUtil.logMsg("log.file.location = " + logFileLocation); - - if (!pass) { - TestUtil.logErr("Setup Failed "); - TestUtil.logErr("Please verify the following in ts.jte"); - TestUtil.logErr("log.file.location"); - } - TestUtil.logMsg("Setup ok"); - - } catch (Exception e) { - TestUtil.logErr("Setup Failed "); - TestUtil.logErr("Please verify the following in ts.jte"); - TestUtil.logErr("log.file.location"); - } - - } - - public Permissions getAppSpecificUnCheckedPermissions() { - return appSpecificUnCheckedPermissions; - } - - public Permissions getAppSpecificExcludedPermissions() { - return appSpecificExcludedPermissions; - } - - public Permissions getAppSpecificAddToRolePermissions() { - return appSpecificAddToRolePermissions; - } - - /* - * This is convenience method for pulling out a list of permissions from - * records that are identified with passed in that match all of the following: - * - permission category (e.g. "excluded", "unchecked", "addToRole") - - * permission type ("WebResourcePermission", etc) - with an appcontext that - * contains the passed in appContext value. If you want a complete matching - * appContext, then pass the whole thing in. - */ - public Permissions getAppSpecificPermissions(String permCat, String permType, - String appContext) { - Permissions permsToReturn = new Permissions(); - LogRecordEntry recordEntry = null; - Permission p = null; - - if (appSpecificRecordCollection == null) { - return null; - } - - Iterator iterator = appSpecificRecordCollection.iterator(); - - while (iterator.hasNext()) { - recordEntry = (LogRecordEntry) iterator.next(); - p = getPermissionFromRecordEntry(recordEntry, permCat, permType, - appContext); - if (p != null) { - permsToReturn.add(p); - } - } - - // printPermissionCollection(permsToReturn); - return permsToReturn; - } - - public void fetchLogs(String accessMethod) { - fetchLogs(accessMethod, null); - } - - /** - * FetchLogs pull logs from the server. - * - */ - public void fetchLogs(String accessMethod, String appName) { - - File logfile = null; - - try { - DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory - .newInstance(); - DocumentBuilder documentBuilder = documentBuilderFactory - .newDocumentBuilder(); - - logFileLocation += "/JACCLog.txt"; - - if (logFileLocation != null) { - logfile = new File(logFileLocation); - } - if ((logfile == null) || (!logfile.exists())) { - // String header = "Log file does not exists"; - // ostream.writeObject(header); - - System.out - .println("Log File : " + logFileLocation + " does not exists"); - System.out.println("Check permissions for log file "); - System.out - .println("See User guide for Configuring log file permissions"); - } else { - // LogRecords will be added to JACCLog.txt as long as the server is - // up and running. Since TSSLog.txt is continuously updated with - // more record there will not be any end tag at the end of the - // log file. - // - // This will cause the SAXParser to throw fatal error message - // "XML Document structures must start and end with the - // same entity" - // - // In order to avoid this error message the FileInputStream - // should have the end tag , this can be achieved by - // creating a SequenceInputStream which includes a - // FileInputStream and a ByteArrayInputStream, where the - // ByteArrayInputStream contains the bytes for - // - String endLogTag = ""; - ByteArrayInputStream bais = new ByteArrayInputStream( - endLogTag.getBytes()); - SequenceInputStream sis = new SequenceInputStream( - new FileInputStream(logFileLocation), bais); - - Document document = documentBuilder.parse(sis); - Element rootElement = document.getDocumentElement(); - NodeList nodes = rootElement.getChildNodes(); - - String queryString = "pullAllRecords"; - String queryParams = "fullLog"; - - StringTokenizer strtoken = new StringTokenizer(accessMethod, "|"); - - if (accessMethod.indexOf("|") > 0) { - queryString = strtoken.nextToken(); - queryParams = strtoken.nextToken(); - } - - if (queryString.equals("pullAllRecords")) { - recordCollection = pullAllLogRecords(queryParams, nodes); - // printCollection(recordCollection); - } else if (queryString.equals("getAppSpecificRecordCollection")) { - - // Get appId records(appId records are records which identifies - // the records with application name and time stamp ). - // - // for extracting appId records, process each record and - // search whether the record starts with "appId" string. - // - // if the log records starts with "appId" - // i.e if (log records starts with "appId") then - // add the records to appIdRecordCollection - // else if (log records starts with "link") then - // add the records to linkRecordCollection - // else - // add the records to recordCollection - // - // Note: In the process of locating appId records - // the remaining records are also processed and - // stored as "linkRecordCollection" and - // "recordCollection" based on the content of the records - - // This call populates both appIdRecordCollection and - // the rest of record collection - appIdRecordCollection = getAppIdRecordCollection("appId", nodes); - // printCollection(appIdRecordCollection); - // printCollection(recordCollection); - - // Parse through all appId records and - // find the current application name - String applicationName = null; - if (appName == null) { - applicationName = getCurrentApplicationName(); - } else { - applicationName = getCurrentApplicationName(appName); - } - - // Parse all link records and find all the - // applications that are linked to the current application - Vector linkedApplicationNames = getLinkedApplicationNames(); - - // Using the application names, isolate the - // application specific logs from the rest of the logs - Collection newAppSpecificRecordCollection = getAppSpecificRecordCollection( - applicationName, linkedApplicationNames); - // printCollection(newAppSpecificRecordCollection); - - } - - // From the record collection read all the records - // and construct list of Permissions such as - // - // 1) appSpecificUnCheckedPermissions - // 2) appSpecificExcludedPermissions - // 3) appSpecificAddToRolePermissions - // - // Where "appSpecificUnCheckedPermissions" contains all the - // application specific unchecked permission collection. - // - // "appSpecificExcludedPermissions" contains all the - // application specific excluded permission collection. - // - // "appSpecificAddToRolePermissions" contains all the - // application specific add to role permission collection. - // - getPermissionCollection(); - } - - } catch (Exception e) { - TestUtil.logErr(e.getMessage()); - TestUtil.printStackTrace(e); - e.printStackTrace(); - } - - } - - public PermissionCollection getPermissionCollection() { - PermissionCollection pColl = new Permissions(); - LogRecordEntry recordEntry = null; - Permission p = null; - - if (appSpecificRecordCollection == null) { - return null; - } - Iterator iterator = appSpecificRecordCollection.iterator(); - - while (iterator.hasNext()) { - recordEntry = (LogRecordEntry) iterator.next(); - p = getPermissionFromRecordEntry(recordEntry); - if (p != null) { - pColl.add(p); - } - } - // printPermissionCollection(pColl); - return pColl; - } - - // Parse record entry and extract permissions from the following - // type of log records "unchecked", "excluded" and "addToRole" - // - // unchecked :: appName , 1058323788497 , EJBMethodPermission , MEJBBean , - // getMBeanCount,Remote - // addToRole :: appName3 , 1058323977373 , WebResourcePermission , - // /secured.jsp , GET,POST - // excluded :: appName2 , 1058323977373 , WebUserDataPermission , - // /excluded.jsp , GET,POST - // - // In the above records - // - // 1) First field identifies the category of record - // 2) second field identifies the application name - // 3) thrid field identifies the timestamp in which - // the record was created. - // 4) fourth field identifies the Permission type such as - // a) WebResourcePermission b) WebRoleRefPermission - // c) WebUserDataPermission d) EJBMehodPermission - // e) EJBRoleRefPermission - // 5) fifth field identifies the permission name - // 6) sixth field identifies the permission action. - // - public Permission getPermissionFromRecordEntry(LogRecordEntry recordEntry) { - - String permissionCategory = null; - String applicationContext = null; - String temp = null; - String message = null; - String permissionType = null; - String permissionName = null; - String permissionAction = null; - String permissionNameAndAction = null; - String applicationTimeStamp = null; - String[] tokenArray = new String[2]; - StringTokenizer permCategoryToken = null; - StringTokenizer strtok = null; - boolean isUnChecked = false; - boolean isExcluded = false; - boolean isAddToRole = false; - - Permission p = null; - - if (recordEntry != null) { - message = recordEntry.getMessage(); - // Get permission category - // i.e "unchecked, excluded or addTorole" - permCategoryToken = new StringTokenizer(message, " :: "); - if (message.indexOf(" :: ") > 0) { - permissionCategory = permCategoryToken.nextToken(); - temp = message.substring(permissionCategory.length() + 4, - message.length()); - } - // TestUtil.logMsg("PermissionCategory ="+permissionCategory); - - if (permissionCategory != null) { - if (permissionCategory.equals("unchecked")) { - isUnChecked = true; - } else if (permissionCategory.equals("excluded")) { - isExcluded = true; - } else if (permissionCategory.equals("addToRole")) { - isAddToRole = true; - } - } - - // i.e Proceed only if the permission Category is one of the following - // a) unchecked - // b) excluded - // c) addToRole - // else return null - if (isUnChecked || isExcluded || isAddToRole) { - // Get ApplicationContext - tokenArray = getTokens(temp, " , "); - applicationContext = tokenArray[0]; - temp = tokenArray[1]; - TestUtil.logTrace("Application Context =" + applicationContext); - - // Get Application time stamp - tokenArray = getTokens(temp, " , "); - applicationTimeStamp = tokenArray[0]; - temp = tokenArray[1]; - TestUtil.logTrace("Application Time stamp =" + applicationTimeStamp); - - // Get permission Type - tokenArray = getTokens(temp, " , "); - permissionType = tokenArray[0]; - permissionNameAndAction = tokenArray[1]; - TestUtil.logTrace("PermissionType =" + permissionType); - - // extract permission name and action - tokenArray = getTokens(permissionNameAndAction, " , "); - permissionName = tokenArray[0]; - permissionAction = tokenArray[1]; - TestUtil.logTrace("permissionName = " + permissionName); - TestUtil.logTrace("permissionAction = " + permissionAction); - - // Change string "null" to just null - // i.e "null" --> null - if (permissionAction.equals("null")) { - permissionAction = null; // Construct permissions based on their - // permission type - } - if (permissionType.equals("WebResourcePermission")) { - p = new WebResourcePermission(permissionName, permissionAction); - } else if (permissionType.equals("WebRoleRefPermission")) { - p = new WebRoleRefPermission(permissionName, permissionAction); - } else if (permissionType.equals("WebUserDataPermission")) { - p = new WebUserDataPermission(permissionName, permissionAction); - } else if (permissionType.equals("EJBMethodPermission")) { - p = new EJBMethodPermission(permissionName, permissionAction); - } else if (permissionType.equals("EJBRoleRefPermission")) { - p = new EJBRoleRefPermission(permissionName, permissionAction); // Add - // permissions - // to - // their - // corresponding - // permission - // collection - // based on their permission category type - } - if (isUnChecked) { - appSpecificUnCheckedPermissions.add(p); - } else if (isExcluded) { - appSpecificExcludedPermissions.add(p); - } else if (isAddToRole) { - appSpecificAddToRolePermissions.add(p); - - } - } - } - - return p; - } - - public Permission getPermissionFromRecordEntry(LogRecordEntry recordEntry, - String permCat, String permType, String appContext) { - String permissionCategory = null; - String applicationContext = null; - String temp = null; - String message = null; - String permissionType = null; - String permissionName = null; - String permissionAction = null; - String permissionNameAndAction = null; - String applicationTimeStamp = null; - String[] tokenArray = new String[2]; - StringTokenizer permCategoryToken = null; - - Permission p = null; - - if (recordEntry != null) { - message = recordEntry.getMessage(); - // Get permission category - // i.e "unchecked, excluded or addToRole" - permCategoryToken = new StringTokenizer(message, " :: "); - if (message.indexOf(" :: ") > 0) { - permissionCategory = permCategoryToken.nextToken(); - temp = message.substring(permissionCategory.length() + 4, - message.length()); - } - - if ((permissionCategory == null) - || (!permissionCategory.equals(permCat))) { - TestUtil.logTrace(permissionCategory + " != " + permCat); - return null; - } - TestUtil.logTrace(permissionCategory + " == " + permCat); - - // Get ApplicationContext - tokenArray = getTokens(temp, " , "); - applicationContext = tokenArray[0]; - temp = tokenArray[1]; - if (!applicationContext.contains(appContext)) { - TestUtil.logTrace(applicationContext + " != " + appContext); - return null; - } - TestUtil.logTrace("applicationContext =" + applicationContext); - - // Get Application time stamp - tokenArray = getTokens(temp, " , "); - applicationTimeStamp = tokenArray[0]; - temp = tokenArray[1]; - TestUtil.logTrace("Application Time stamp =" + applicationTimeStamp); - - // Get permission Type - tokenArray = getTokens(temp, " , "); - permissionType = tokenArray[0]; - permissionNameAndAction = tokenArray[1]; - TestUtil.logTrace("PermissionType =" + permissionType); - - // extract permission name and action - tokenArray = getTokens(permissionNameAndAction, " , "); - permissionName = tokenArray[0]; - permissionAction = tokenArray[1]; - TestUtil.logTrace("permissionName = " + permissionName); - TestUtil.logTrace("permissionAction = " + permissionAction); - - if (permissionAction.equals("null")) { - permissionAction = null; // Construct permissions based on their - // permission type - } - - if (!permissionType.equals(permType)) { - return null; - } - - if (permissionType.equals("WebResourcePermission")) { - p = new WebResourcePermission(permissionName, permissionAction); - } else if (permissionType.equals("WebRoleRefPermission")) { - p = new WebRoleRefPermission(permissionName, permissionAction); - } else if (permissionType.equals("WebUserDataPermission")) { - p = new WebUserDataPermission(permissionName, permissionAction); - } else if (permissionType.equals("EJBMethodPermission")) { - p = new EJBMethodPermission(permissionName, permissionAction); - } else if (permissionType.equals("EJBRoleRefPermission")) { - p = new EJBRoleRefPermission(permissionName, permissionAction); - } - } - - return p; - } - - public Permissions getSpecificPermissions(Permissions suppliedPermCollection, - String permissionType) { - Permission p = null; - Permissions expectedPermissionCollection = new Permissions(); - - if (permissionType.equals("WebResourcePermission")) { - for (Enumeration en = suppliedPermCollection.elements(); en - .hasMoreElements();) { - p = (Permission) en.nextElement(); - if (p instanceof WebResourcePermission) { - expectedPermissionCollection.add(p); - } - } - } else if (permissionType.equals("WebUserDataPermission")) { - for (Enumeration en = suppliedPermCollection.elements(); en - .hasMoreElements();) { - p = (Permission) en.nextElement(); - - if (p instanceof WebUserDataPermission) { - expectedPermissionCollection.add(p); - } - } - } else if (permissionType.equals("WebRoleRefPermission")) { - for (Enumeration en = suppliedPermCollection.elements(); en - .hasMoreElements();) { - p = (Permission) en.nextElement(); - if (p instanceof WebRoleRefPermission) { - expectedPermissionCollection.add(p); - } - } - } else if (permissionType.equals("EJBMethodPermission")) { - for (Enumeration en = suppliedPermCollection.elements(); en - .hasMoreElements();) { - p = (Permission) en.nextElement(); - if (p instanceof EJBMethodPermission) { - expectedPermissionCollection.add(p); - } - } - } else if (permissionType.equals("EJBRoleRefPermission")) { - for (Enumeration en = suppliedPermCollection.elements(); en - .hasMoreElements();) { - p = (Permission) en.nextElement(); - if (p instanceof EJBRoleRefPermission) { - expectedPermissionCollection.add(p); - } - } - } - return expectedPermissionCollection; - } - - /** - * Fetches all JSR196 SPI logs from JACCLog.txt - */ - public static Collection pullAllLogRecords(String queryParams, NodeList nodes) - throws Exception { - Collection recordCollection = new Vector(); - Node recordNode; - - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - - if (recordNode.getNodeName().equals("record")) { - LogRecordEntry recordEntry = new LogRecordEntry(recordNode); - recordCollection.add(recordEntry); - - } - } - return recordCollection; - } - - public void setAppIdRecordCollection(Collection recordCollection) { - this.appIdRecordCollection = recordCollection; - } - - public Collection getAppIdRecordCollection() { - return this.appIdRecordCollection; - } - - public void setRecordCollection(Collection recordCollection) { - this.recordCollection = recordCollection; - } - - public Collection getRecordCollection() { - return this.recordCollection; - } - - public void setAppSpecificRecordCollection(Collection recordCollection) { - this.appSpecificRecordCollection = recordCollection; - } - - public Collection getAppSpecificRecordCollection() { - return this.appSpecificRecordCollection; - } - - /** - * Checks for the existance of search string in the log. For example to verify - * whether server log contains a string "Java EE rocks" use the following code - * - * LogFileProcessor logProcessor = new LogFileProcessor(properties); boolean - * contains = logProcessor.verifyLogContains("Java EE rocks"); - * - * where "properties" contains the key value pair for 1) log.file.location - */ - public boolean verifyLogContains(String args[]) { - LogRecordEntry recordEntry = null; - TestUtil.logMsg("Searching log records for record :" + args[0]); - if (recordCollection == null) { - TestUtil.logMsg("Record collection empty : No log records found"); - return false; - } else { - TestUtil.logMsg( - "Record collection has: " + recordCollection.size() + " records."); - } - - int numberOfArgs = args.length; - int numberOfMatches = 0; - - boolean argsMatchIndex[] = new boolean[args.length]; - for (int i = 0; i < args.length; i++) { - // initialize all argsMatchIndex to "false" (i.e no match) - argsMatchIndex[i] = false; - - // From the given string array(args) if there is a record match - // for the search string, then the corresponding argsMatchIndex[i] - // will be set to true(to indicate a match) - // i.e argsMatchIndex[i] = true; - // - // For example if the string array contains - // String args[]={"JK", "EMERSON", "J.B.Shaw}; - // - // And if the string "JK" and "J.B.Shaw" are found in the records - // then the argsMatchIndex will be set as shown below - // argsMatchIndex[] ={true, false, true}; - // - } - - Iterator iterator = recordCollection.iterator(); - while (iterator.hasNext()) { - // loop thru all message tag/entries in the log file - recordEntry = (LogRecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - // loop through all arguments to search for a match - for (int i = 0; i < numberOfArgs; i++) { - - // Search only unique record matches ignore repeat occurances - if (argsMatchIndex[i] != true) { - // see if one of the search argument matches with - // the logfile message entry and if so return true - if ((message != null) && message.equals(args[i])) { - TestUtil.logMsg("Matching Record :"); - TestUtil.logMsg(recordEntry.getMessage()); - - // Increment match count - numberOfMatches++; - - // Mark the matches in argsMatchIndex - argsMatchIndex[i] = true; - - continue; - } - } - - } - - // Return true if, we found matches for all strings - // in the given string array - if (numberOfMatches == numberOfArgs) { - return true; - } - } - - // Print unmatched Strings(i.e no matches were found for these strings) - TestUtil.logMsg( - "No Matching log Record(s) found for the following String(s) :"); - for (int i = 0; i < numberOfArgs; i++) { - if (argsMatchIndex[i] == false) { - TestUtil.logMsg(args[i]); - } - } - - return false; - } - - /** - * Checks for the existance of one of the search string(from a given String - * array. - * - * For example to verify whether server log contains one of the following - * String String[] arr ={"aaa", "bbb", "ccc"}; - * - * LogFileProcessor logProcessor = new LogFileProcessor(properties); boolean - * contains = logProcessor.verifyLogContainsOneOf(arr); - * - * This method will return true if the log file contains one of the specified - * String (say "aaa" ) - * - * where "properties" contains the key value pair for 1) log.file.location - */ - public boolean verifyLogContainsOneOf(String args[]) { - LogRecordEntry recordEntry = null; - boolean result = false; - - TestUtil - .logMsg("Searching log records for the presence of one of the String" - + " from a given string array"); - if (recordCollection == null) { - TestUtil.logMsg("Record collection empty : No log records found"); - return false; - } else { - TestUtil.logMsg( - "Record collection has: " + recordCollection.size() + " records."); - } - - int numberOfArgs = args.length; - - Iterator iterator = recordCollection.iterator(); - searchLabel: while (iterator.hasNext()) { - // loop thru all message tag/entries in the log file - recordEntry = (LogRecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - // loop through all arguments to search for a match - for (int i = 0; i < numberOfArgs; i++) { - - // see if one of the search argument matches with - // the logfile message entry and if so return true - if ((message != null) && message.equals(args[i])) { - TestUtil.logMsg("Matching Record :"); - TestUtil.logMsg(recordEntry.getMessage()); - result = true; - - // If a match is found no need to search further - break searchLabel; - } - } - - } - - if (!result) { - // Print unmatched Strings(i.e no matches were found for these strings) - TestUtil.logMsg( - "No Matching log Record(s) found for the following String(s) :"); - for (int i = 0; i < numberOfArgs; i++) { - TestUtil.logMsg(args[i]); - } - } - - return result; - } - - /** - * This method looks for the presence of the given substring (from the array - * of strings "args") in the serverlog, which starts with the given - * "srchStrPrefix" search-string-prefix. - * - * - * For example to verify whether server log contains one of the following - * Strings in a server log with appContextId as the message prefix we can - * issue the following command - * - * String[] arr ={"aaa", "bbb", "ccc"}; String srchStrPrefix ="appContextId"; - * - * LogFileProcessor logProcessor = new LogFileProcessor(properties); boolean - * contains = logProcessor.verifyLogContainsOneOf(arr); - * - * "appContextId= xxxx aaa yyyyyyyyyyyyyyyyy" "appContextId= yyyy bbb - * xxxxxxxxxxxxxxxxx" - * - * This method will return true if the log file contains one of the specified - * String (say "aaa" ) in the message log with "appContextId" as its message - * prefix. - * - * where "properties" contains the key value pair for 1) log.file.location - */ - public boolean verifyLogContainsOneOfSubString(String args[], - String srchStrPrefix) { - LogRecordEntry recordEntry = null; - boolean result = false; - - TestUtil - .logMsg("Searching log records for the presence of one of the String" - + " from a given string array"); - if (recordCollection == null) { - TestUtil.logMsg("Record collection empty : No log records found"); - return false; - } else { - TestUtil.logMsg( - "Record collection has: " + recordCollection.size() + " records."); - } - - int numberOfArgs = args.length; - - Iterator iterator = recordCollection.iterator(); - searchLabel: while (iterator.hasNext()) { - // loop thru all message tag/entries in the log file - recordEntry = (LogRecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - // loop through all arguments to search for a match - for (int i = 0; i < numberOfArgs; i++) { - - // see if one of the search argument matches with - // the logfile message entry and if so return true - if ((message != null) && (message.startsWith(srchStrPrefix, 0)) - && (message.indexOf(args[i]) > 0)) { - TestUtil.logMsg("Matching Record :"); - TestUtil.logMsg(recordEntry.getMessage()); - result = true; - - // If a match is found no need to search further - break searchLabel; - } - } - - } - - if (!result) { - // Print unmatched Strings(i.e no matches were found for these strings) - TestUtil.logMsg( - "No Matching log Record(s) found for the following String(s) :"); - for (int i = 0; i < numberOfArgs; i++) { - TestUtil.logMsg(args[i]); - } - } - - return result; - } - - /** - * verifyLogImplies() takes the individual expectedPermissions and and checks - * whether the generatedPermissions.implies() is true. - */ - public boolean verifyLogImplies(Permissions expectedPermissions, - Permissions generatedPermissions) { - boolean verified = false; - Permission p; - - for (Enumeration en = expectedPermissions.elements(); en - .hasMoreElements();) { - p = (Permission) en.nextElement(); - - verified = generatedPermissions.implies(p); - if (!verified) { - TestUtil.logErr( - "The following permission doesn't match with server generated Permissions"); - TestUtil.logErr("permissionName = " + p.getName()); - TestUtil.logErr("permissionAction = " + p.getActions()); - - TestUtil.logErr("\n\n"); - TestUtil.logErr("Print Expected Permissions :"); - printPermissions(expectedPermissions); - TestUtil.logErr("\n\n"); - TestUtil.logErr("Print Generated Permissions :"); - printPermissions(generatedPermissions); - return false; - } - } - - // following code compares each generatedPermission with - // expectedPermissionCollection and lists the extra permissions - for (Enumeration en = generatedPermissions.elements(); en - .hasMoreElements();) { - p = (Permission) en.nextElement(); - verified = expectedPermissions.implies(p); - if (!verified) { - TestUtil.logMsg( - "The following server generated permission doesn't match with the expected Permissions"); - TestUtil.logMsg("permissionName = " + p.getName()); - TestUtil.logMsg("permissionAction = " + p.getActions()); - } - } - - return true; - } - - public void printCollection(Collection recordCollection) { - LogRecordEntry recordEntry = null; - Iterator iterator = recordCollection.iterator(); - - while (iterator.hasNext()) { - recordEntry = (LogRecordEntry) iterator.next(); - printRecordEntry(recordEntry); - } - } - - // Print heterogeneous collection of permissions - public void printPermissions(Permissions perms) { - int count = 0; - for (Enumeration en = perms.elements(); en.hasMoreElements();) { - count++; - Permission p = (Permission) en.nextElement(); - TestUtil.logMsg("-------------"); - TestUtil.logMsg(count + ") permissionType = " + p.getClass().getName()); - TestUtil.logMsg(count + ") permissionName = " + p.getName()); - TestUtil.logMsg(count + ") permissionAction = " + p.getActions()); - } - - } - - public void printPermissionCollection(PermissionCollection permCollection) { - String permissionType = null; - int count = 0; - - for (Enumeration en = permCollection.elements(); en.hasMoreElements();) { - count++; - - Permission p = (Permission) en.nextElement(); - if (p instanceof WebResourcePermission) { - permissionType = "WebResourcePermission"; - } else if (p instanceof WebUserDataPermission) { - permissionType = "WebUserDataPermission"; - } else if (p instanceof WebRoleRefPermission) { - permissionType = "WebRoleRefPermission"; - } else if (p instanceof EJBMethodPermission) { - permissionType = "EJBMethodPermission"; - } else if (p instanceof EJBRoleRefPermission) { - permissionType = "EJBRoleRefPermission"; - } - TestUtil.logMsg("-------------"); - TestUtil.logMsg(count + ") permissionType = " + permissionType); - TestUtil.logMsg(count + ") permissionName = " + p.getName()); - TestUtil.logMsg(count + ") permissionAction = " + p.getActions()); - } - } - - public void printRecordEntry(LogRecordEntry rec) { - TestUtil.logMsg("*******Log Content*******"); - - TestUtil.logMsg("Milli Seconds =" + rec.getMilliSeconds()); - TestUtil.logMsg("Seqence no =" + rec.getSequenceNumber()); - TestUtil.logMsg("Message =" + rec.getMessage()); - if (rec.getClassName() != null) { - TestUtil.logMsg("Class name =" + rec.getClassName()); - } - if (rec.getMethodName() != null) { - TestUtil.logMsg("Method name =" + rec.getMethodName()); - } - if (rec.getLevel() != null) { - TestUtil.logMsg("Level =" + rec.getLevel()); - } - if (rec.getThrown() != null) { - TestUtil.logMsg("Thrown =" + rec.getThrown()); - } - TestUtil.logMsg(""); - } - - public String extractQueryToken(String str, String ContextId) { - StringTokenizer strtok; - String DELIMETER = "|"; - String qstring = null; - String qparams = null; - - strtok = new StringTokenizer(ContextId, DELIMETER); - if (ContextId.indexOf(DELIMETER) > 0) { - qstring = strtok.nextToken(); - if (strtok.hasMoreTokens()) { - qparams = strtok.nextToken(); - } - } - - // return query string or query params based on the content - // of the string str - if (str.equals("LogQueryString")) { - return qstring; - } else { - return qparams; - } - } - - // This method tokenize the given string and - // return first token and the remaining - // string a string array based on the given delimeter - public static String[] getTokens(String str, String delimeter) { - String[] array = new String[2]; - StringTokenizer strtoken; - - // Get first token and the remaining string - strtoken = new StringTokenizer(str, delimeter); - if (str.indexOf(delimeter) > 0) { - array[0] = strtoken.nextToken(); - array[1] = str.substring(array[0].length() + 3, str.length()); - } else { - // With JSR115 Maintenance review change the permission name - // for WebRoleRefPermission can be an empty string. - // this results in permissionName="" - // i.e the input string will have a value such as - // str=" , " - array[0] = ""; - array[1] = strtoken.nextToken(); - } - - // TestUtil.logMsg("Input String ="+str); - // TestUtil.logMsg("array[0] ="+array[0]); - // TestUtil.logMsg("array[1] ="+array[1]); - return array; - } - - // - // Locates the logs based on the given prefix string - // - // For example to locate all commit records i.e records such as - // - // commit :: MyApp1058312446320 , recordTimeStamp=1058312446598 - // - // Use the following method to pull all the commit records - // - // fingLogsByPrefix("commit", nodes); - public Collection findLogsByPrefix(String queryParams, NodeList nodes) - throws Exception { - Collection recordCollection = new Vector(); - String nodeName; - String nodeValue; - Node childNode; - Node recordNode; - NodeList recordNodeChildren; - - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - - // get all the child nodes for the first record - recordNodeChildren = recordNode.getChildNodes(); - - for (int j = 0; j < recordNodeChildren.getLength(); j++) { - childNode = recordNodeChildren.item(j); - nodeName = childNode.getNodeName(); - if (nodeName.equals("message")) { - nodeValue = getText(childNode); - if (nodeValue.startsWith(queryParams)) { - // create a new record entry and - // add it to the collection - LogRecordEntry recordEntry = new LogRecordEntry(recordNode); - - recordCollection.add(recordEntry); - } - } - } - } - return recordCollection; - } - - public String getText(Node textNode) { - String result = ""; - NodeList nodes = textNode.getChildNodes(); - - for (int i = 0; i < nodes.getLength(); i++) { - Node node = nodes.item(i); - - if (node.getNodeType() == Node.TEXT_NODE) { - result = node.getNodeValue(); - break; - } - } - return result; - } - - /** - * This method retrieves the appId records. - * - * i.e if (log records starts with "appId") then add the records to - * appIdRecordCollection else add the records to recordCollection - * - * Note: In the process of locating appId records the remaining records are - * also isolated and stored in a collection called "recordCollection" - */ - public Collection getAppIdRecordCollection(String queryParams, NodeList nodes) - throws Exception { - String nodeName; - String nodeValue; - Node childNode; - Node recordNode; - NodeList recordNodeChildren; - - for (int i = 0; i < nodes.getLength(); i++) { - // Take the first record - recordNode = nodes.item(i); - // get all the child nodes for the first record - recordNodeChildren = recordNode.getChildNodes(); - for (int j = 0; j < recordNodeChildren.getLength(); j++) { - childNode = recordNodeChildren.item(j); - nodeName = childNode.getNodeName(); - if (nodeName.equals("message")) { - nodeValue = getText(childNode); - if (nodeValue.startsWith(queryParams)) { - // create a new record entry that matches the - // query criteria i.e "appId" - LogRecordEntry matchingRecordEntry = new LogRecordEntry(recordNode); - this.appIdRecordCollection.add(matchingRecordEntry); - } else if (nodeValue.startsWith("link")) { - // create a new record entry for link records - LogRecordEntry linkRecordEntry = new LogRecordEntry(recordNode); - this.linkRecordCollection.add(linkRecordEntry); - } else { - // create a new record entry that do not - // match the query criteria - LogRecordEntry nonMatchingRecordEntry = new LogRecordEntry( - recordNode); - this.recordCollection.add(nonMatchingRecordEntry); - } - } - } - } - return appIdRecordCollection; - } - - public String getCurrentApplicationName() { - return getCurrentAppName(null); - } - - public String getCurrentApplicationName(String appName) { - return getCurrentAppName(appName); - } - - // This method returns the current application name by analysing - // all the appId log records. - // - // The appId log record contains the Application name and the timeStamp - // For example, let us examine the following 3 appId log records. - // - // appId :: MyApp , 1058312446598 - // appId :: App , 1058312463706 - // appId :: adminapp , 1058312480593 - // - // In the above 3 appId records - // a) the first field "appId :: " identifies this as a appId record - // b) the second field indicates the application name - // c) the third field refers to the timestamp at which the record was - // created. - // - // By comparing the timestamps we can locate the latest of all appId records - // and return the application name associated with it. - private String getCurrentAppName(String matchAppName) { - LogRecordEntry recordEntry = null; - String temp = null; - String timeStampString = null; - String appName = null; - String prevAppName = null; - long prevRecordTimeStamp = 0; - long recordTimeStamp = 0; - String[] tokenArray = new String[2]; - - if ((appIdRecordCollection == null) || (appIdRecordCollection.isEmpty())) { - TestUtil.logMsg("Record collection empty : No appId records found"); - return null; - } - - Iterator iterator = appIdRecordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (LogRecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - // Remove the string "appId :: " from the message - temp = message.substring(9, message.length()); - - // Get appName and timeStampString - tokenArray = temp.split(" , "); - appName = tokenArray[0]; - timeStampString = tokenArray[1]; - - // now unstuff application name - appName = unStuffData(appName); - - TestUtil.logMsg("appName =" + appName); - TestUtil.logMsg("timeStampString =" + timeStampString); - - // Get long value from the string - if (matchAppName == null) { - // warning: what this does is look for the newest record - // and use that as the appname. If multiple apps - // are deployed at same time - this could return - // a record that belongs to a different app. - recordTimeStamp = (new Long(timeStampString)).longValue(); - if (recordTimeStamp < prevRecordTimeStamp) { - recordTimeStamp = prevRecordTimeStamp; - appName = prevAppName; - } - } else { - // we want an appname that matches/contains the passed in appName - if (appName.contains(matchAppName)) { - break; - } - } - } - return appName; - } - - // This method returns the linked application names by analysing - // all the link log records. - // - // The link log record contains the list of Application names - // and the timeStamp. - // For example, let us examine the following 2 link log records. - // - // link :: MyApp,SecondApp : 1058312446598 - // link :: App,SecondApp,ThirdApp : 1058312463706 - // - // In the above 3 link records - // a) the first field "link :: " identifies this as a link record - // b) the second field indicates the application names that are - // linked to. - // Note: Linked application names are idenified using - // the comma separator. - // c) the last field indicates the timestamp at which the record was - // created. - // - // By comparing the timestamps we can locate the latest link records - // and return the application names linked to it. - public Vector getLinkedApplicationNames() { - LogRecordEntry recordEntry = null; - String temp = null; - String timeStampString = null; - String appNames = null; - String prevAppName = null; - long prevRecordTimeStamp = 0; - long recordTimeStamp = 0; - String[] tokenArray = new String[2]; - Vector applicationNames = new Vector(); - - if (linkRecordCollection == null) { - TestUtil.logMsg("Record collection empty : No link records found"); - return null; - } - Iterator iterator = linkRecordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (LogRecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - // Remove the string "link :: " from the message - temp = message.substring(8, message.length()); - - // Get appName and timeStampString - tokenArray = temp.split(" : "); - appNames = tokenArray[0]; - timeStampString = tokenArray[1]; - - // now unstuff application name - appNames = unStuffData(appNames); - - // Get long value from the string - recordTimeStamp = (new Long(timeStampString)).longValue(); - if (recordTimeStamp < prevRecordTimeStamp) { - recordTimeStamp = prevRecordTimeStamp; - appNames = prevAppName; - } - } - - StringTokenizer strtoken; - - if (appNames != null) { - // create a vector with applicationNames - strtoken = new StringTokenizer(appNames, ","); - if (appNames.indexOf(",") > 0) { - // if the appNames string contains multiple applications - // add all of them to the vector applicationNames - while (strtoken.hasMoreTokens()) { - applicationNames.add(strtoken.nextToken()); - } - } else if (appNames != null) { - // if the appNames string contains only one application - // add it to the vector applicationNames - applicationNames.add(appNames); - } - } else { - // else return null - return null; - } - - return applicationNames; - } - - /* - * This returns the collection of records that have a message field that - * contains the keyword "MSG_TAG". This is a generic flag used to put a phrase - * or info into a records message field so that we can easily search on those - * MSG_TAG fields later on. - */ - public Collection getMsgTagRecordCollection() { - LogRecordEntry recordEntry = null; - Collection msgTagRecordCollection = new Vector(); - - TestUtil.logTrace("getMsgTagRecordCollection(): Record collection size : " - + recordCollection.size()); - if (recordCollection == null) { - TestUtil.logTrace("Record collection empty : No records found"); - return null; - } - Iterator iterator = this.recordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (LogRecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - if (message.indexOf("MSG_TAG") > -1) { - TestUtil.logTrace("getMsgTagRecordCollection(): message = " + message); - msgTagRecordCollection.add(recordEntry); - } - } - TestUtil - .logTrace("getMsgTagRecordCollection(): returning collection size of: " - + msgTagRecordCollection.size()); - return msgTagRecordCollection; - } - - /* - * This method reads all non-appId records from the record collection and - * isolates current appSpecific records from the rest using the given - * applicationName and the linkedApplicationNames. - */ - public Collection getAppSpecificRecordCollection(String applicationName, - Vector linkedApplicationNames) { - LogRecordEntry recordEntry = null; - - if (recordCollection == null) { - TestUtil.logMsg("Record collection empty : No records found"); - return null; - } - Iterator iterator = this.recordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (LogRecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - // if recordEntry contains the specified applicationName - // Add the record to appSpecificRecordCollection - if (message.indexOf(applicationName) > 0) { - appSpecificRecordCollection.add(recordEntry); - } - } - - if (linkedApplicationNames != null) { - // retrieve all the records associated with - // linked applications. - for (Enumeration appEnum = linkedApplicationNames.elements(); appEnum - .hasMoreElements();) { - applicationName = (String) appEnum.nextElement(); - - iterator = this.recordCollection.iterator(); - while (iterator.hasNext()) { - recordEntry = (LogRecordEntry) iterator.next(); - String message = recordEntry.getMessage(); - - // if recordEntry contains the specified applicationName - // Add the record to appSpecificRecordCollection - if (message.indexOf(applicationName) > 0) { - appSpecificRecordCollection.add(recordEntry); - } - } - - } - } - return appSpecificRecordCollection; - } - - // This will remove the stuffed characters in the input string - // Note: The non-alphabets in the input string was already stuffed by - // the same character, this method unstuff those characters - public static String unStuffData(String inputStr) { - char[] outStr = new char[2048]; - char[] str = inputStr.toCharArray(); - - TestUtil.logMsg("unStuffData called with: " + inputStr); - - for (int i = 0, j = 0; i < str.length;) { - - int a = Character.getNumericValue(str[i]); - - // Don't stuff extra character if the character is an alphabet - // - // Numeric values for alphabets falls in 10 to 35, this includes - // both upper and lower cases - if ((a > 9) && (a < 36)) { - outStr[j++] = str[i++]; - } else { // unstuff the character - outStr[j] = str[i]; // just skip the next character - // Remove only the stuffed characters not data separators - if (((i + 1) < str.length) && (str[i + 1] == str[i])) { - // just skip the next character - i++; - } - i++; - j++; - } - } - - TestUtil.logMsg("unStuffData returning: " + (new String(outStr)).trim()); - return ((new String(outStr)).trim()); - } -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/LogRecordEntry.java b/jacc/src/main/java/com/sun/ts/tests/jacc/util/LogRecordEntry.java deleted file mode 100644 index 6a47f3628b..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/LogRecordEntry.java +++ /dev/null @@ -1,147 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.util; - -import java.io.Serializable; - -import org.w3c.dom.Node; -import org.w3c.dom.NodeList; - -public class LogRecordEntry implements Serializable { - - private long milliSeconds; - - private long sequenceNumber; - - private String level; - - private String className; - - private String methodName; - - private String message; - - private String thrown; - - public LogRecordEntry(Node recordNode) throws Exception { - if (!recordNode.getNodeName().equals("record")) { - throw new Exception("Unexpected tag :" + recordNode.getNodeName()); - } - NodeList nodes = recordNode.getChildNodes(); - - for (int i = 0; i < nodes.getLength(); i++) { - Node node = nodes.item(i); - String childNode = node.getNodeName(); - - if (childNode.equals("millis")) { - milliSeconds = (new Long(getText(node))).longValue(); - - } else if (childNode.equals("sequence")) { - sequenceNumber = (new Long(getText(node))).longValue(); - - } else if (childNode.equals("level")) { - level = getText(node); - - } else if (childNode.equals("class")) { - className = getText(node); - - } else if (childNode.equals("method")) { - methodName = getText(node); - - } else if (childNode.equals("message")) { - message = getText(node); - - } else if (childNode.equals("exception")) { - thrown = getText(node); - - } - - } - } - - public long getMilliSeconds() { - return this.milliSeconds; - } - - public void setMilliSeconds(long milliSec) { - milliSeconds = milliSec; - } - - public long getSequenceNumber() { - return this.sequenceNumber; - } - - public void setSequenceNumber(long seqNum) { - sequenceNumber = seqNum; - } - - public String getMessage() { - return this.message; - } - - public void setMessage(String msg) { - message = msg; - } - - public String getLevel() { - return this.level; - } - - public void setLevel(String lvl) { - level = lvl; - } - - public String getClassName() { - return this.className; - } - - public void setClassName(String cName) { - className = cName; - } - - public String getMethodName() { - return this.methodName; - } - - public void setMethodName(String mName) { - methodName = mName; - } - - public String getThrown() { - return this.thrown; - } - - public void setThrown(String thrwn) { - thrown = thrwn; - } - - public String getText(Node textNode) { - String result = ""; - NodeList nodes = textNode.getChildNodes(); - - for (int i = 0; i < nodes.getLength(); i++) { - Node node = nodes.item(i); - - if (node.getNodeType() == Node.TEXT_NODE) { - result = node.getNodeValue(); - break; - } - } - return result; - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/RecordEntry.java b/jacc/src/main/java/com/sun/ts/tests/jacc/util/RecordEntry.java deleted file mode 100644 index bb93b84735..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/RecordEntry.java +++ /dev/null @@ -1,147 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/* - * $Id$ - */ - -package com.sun.ts.tests.jacc.util; - -import java.io.Serializable; - -import org.w3c.dom.Node; -import org.w3c.dom.NodeList; - -public class RecordEntry implements Serializable { - - private long sequenceNumber; - - private String contextId; - - private String message; - - private String className; - - private String methodName; - - private String level; - - private String thrown; - - public RecordEntry(Node recordNode) throws Exception { - if (!recordNode.getNodeName().equals("record")) { - throw new Exception("Unexpected tag :" + recordNode.getNodeName()); - } - NodeList nodes = recordNode.getChildNodes(); - - for (int i = 0; i < nodes.getLength(); i++) { - Node node = nodes.item(i); - String childNode = node.getNodeName(); - - if (childNode.equals("sequence")) { - sequenceNumber = (new Long(getText(node))).longValue(); - } else if (childNode.equals("contextId")) { - contextId = getText(node); - } else if (childNode.equals("logger")) {// logger = getText(node); - } else if (childNode.equals("level")) { - level = getText(node); - } else if (childNode.equals("class")) { - className = getText(node); - } else if (childNode.equals("method")) { - methodName = getText(node); - } else if (childNode.equals("thread")) {// thread = - // (new Integer(getText(node))).getInt(); - } else if (childNode.equals("message")) { - message = getText(node); - } else if (childNode.equals("exception")) { - thrown = getText(node); - } - - } - } - - public long getSequenceNumber() { - return this.sequenceNumber; - } - - public void setSequenceNumber(long seqNum) { - sequenceNumber = seqNum; - } - - public String getContextId() { - return this.contextId; - } - - public void setContextId(String cId) { - contextId = cId; - } - - public String getMessage() { - return this.message; - } - - public void setMessage(String msg) { - message = msg; - } - - public String getLevel() { - return this.level; - } - - public void setLevel(String lvl) { - level = lvl; - } - - public String getClassName() { - return this.className; - } - - public void setClassName(String cName) { - className = cName; - } - - public String getMethodName() { - return this.methodName; - } - - public void setMethodName(String mName) { - methodName = mName; - } - - public String getThrown() { - return this.thrown; - } - - public void setThrown(String thrwn) { - thrown = thrwn; - } - - public String getText(Node textNode) { - String result = ""; - NodeList nodes = textNode.getChildNodes(); - - for (int i = 0; i < nodes.getLength(); i++) { - Node node = nodes.item(i); - - if (node.getNodeType() == Node.TEXT_NODE) { - result = node.getNodeValue(); - break; - } - } - return result; - } - -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/anyauthuser.jsp b/jacc/src/main/java/com/sun/ts/tests/jacc/util/anyauthuser.jsp deleted file mode 100644 index ab0c42612a..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/anyauthuser.jsp +++ /dev/null @@ -1,41 +0,0 @@ -<%-- - - Copyright (c) 2013, 2018 Oracle and/or its affiliates. All rights reserved. - - This program and the accompanying materials are made available under the - terms of the Eclipse Public License v. 2.0, which is available at - http://www.eclipse.org/legal/epl-2.0. - - This Source Code may also be made available under the following Secondary - Licenses when the conditions for such availability set forth in the - Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - version 2 with the GNU Classpath Exception, which is available at - https://www.gnu.org/software/classpath/license.html. - - SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - ---%> - - -<%@ page language="java" %> - - - JSP with Any Authenticated User Auth Constraint - -

    JSP with Double-WildCard Auth Constraint

    - - <% - - out.println("The user principal is: " + request.getUserPrincipal().getName() + "
    "); - out.println("getRemoteUser(): " + request.getRemoteUser() + "
    " ); - - if (request.isUserInRole("**")){ - out.println("USR_IN_ROLE_STARSTAR"); - } else { - out.println("USR_NOT_IN_ROLE_STARSTAR"); - } - - %> - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/util/build.xml deleted file mode 100644 index f3b3141eab..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/build.xml +++ /dev/null @@ -1,35 +0,0 @@ - - - - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/excluded.jsp b/jacc/src/main/java/com/sun/ts/tests/jacc/util/excluded.jsp deleted file mode 100644 index 06aba36726..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/excluded.jsp +++ /dev/null @@ -1,40 +0,0 @@ -<%-- - - Copyright (c) 2006, 2018 Oracle and/or its affiliates. All rights reserved. - - This program and the accompanying materials are made available under the - terms of the Eclipse Public License v. 2.0, which is available at - http://www.eclipse.org/legal/epl-2.0. - - This Source Code may also be made available under the following Secondary - Licenses when the conditions for such availability set forth in the - Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - version 2 with the GNU Classpath Exception, which is available at - https://www.gnu.org/software/classpath/license.html. - - SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - ---%> - - - -<%@ page language="java" %> - - -JSP used for verifying excluded policy statement - -

    JSP used for excluded policy statement

    - -<% - -out.println("The user principal is: " + request.getUserPrincipal().getName() + "
    "); -out.println("getRemoteUser(): " + request.getRemoteUser() + "
    " ); - -%> - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/jacc_util.ear.sun-application.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/util/jacc_util.ear.sun-application.xml deleted file mode 100644 index 0a62bd5599..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/jacc_util.ear.sun-application.xml +++ /dev/null @@ -1,28 +0,0 @@ - - - - - - - jacc_util_web.war - jacc_util_web - - 0 - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/jacc_util_web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/util/jacc_util_web.xml deleted file mode 100644 index f4d38ca6ea..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/jacc_util_web.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - - jacc_util - - FetchLogs - com.sun.ts.tests.jacc.util.FetchLogs - - - FetchLogs - /FetchLogs - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/secured.jsp b/jacc/src/main/java/com/sun/ts/tests/jacc/util/secured.jsp deleted file mode 100644 index cd4e79bacd..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/secured.jsp +++ /dev/null @@ -1,48 +0,0 @@ -<%-- - - Copyright (c) 2006, 2018 Oracle and/or its affiliates. All rights reserved. - - This program and the accompanying materials are made available under the - terms of the Eclipse Public License v. 2.0, which is available at - http://www.eclipse.org/legal/epl-2.0. - - This Source Code may also be made available under the following Secondary - Licenses when the conditions for such availability set forth in the - Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - version 2 with the GNU Classpath Exception, which is available at - https://www.gnu.org/software/classpath/license.html. - - SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - ---%> - - - -<%@ page language="java" %> - - -JSP with Security Constraint - -

    JSP with Security Constraint

    - -<% - -out.println("The user principal is: " + request.getUserPrincipal().getName() + "
    "); -out.println("getRemoteUser(): " + request.getRemoteUser() + "
    " ); - -// Surround these with !'s so they are easier to search for. -// (i.e. we can search for !true! or !false!) -out.println("isUserInRole(\"ADM\"): !" + request.isUserInRole("ADM") + "!
    "); -out.println("isUserInRole(\"MGR\"): !" + request.isUserInRole("MGR") + "!
    "); -out.println("isUserInRole(\"VP\"): !" + request.isUserInRole("VP") + "!
    "); -out.println("isUserInRole(\"EMP\"): !" + request.isUserInRole("EMP") + "!
    "); -out.println("isUserInRole(\"Administrator\"): !" + request.isUserInRole("Administrator") + "!
    "); - -%> - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/sslprotected.jsp b/jacc/src/main/java/com/sun/ts/tests/jacc/util/sslprotected.jsp deleted file mode 100644 index 74efe762ed..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/sslprotected.jsp +++ /dev/null @@ -1,40 +0,0 @@ -<%-- - - Copyright (c) 2006, 2018 Oracle and/or its affiliates. All rights reserved. - - This program and the accompanying materials are made available under the - terms of the Eclipse Public License v. 2.0, which is available at - http://www.eclipse.org/legal/epl-2.0. - - This Source Code may also be made available under the following Secondary - Licenses when the conditions for such availability set forth in the - Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - version 2 with the GNU Classpath Exception, which is available at - https://www.gnu.org/software/classpath/license.html. - - SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - ---%> - - - -<%@ page language="java" %> - - -SSL Proteected - -

    SSL protected JSP

    - -<% - -out.println("The user principal is: " + request.getUserPrincipal().getName() + "
    "); -out.println("getRemoteUser(): " + request.getRemoteUser() + "
    " ); - -%> - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/util/unchecked.jsp b/jacc/src/main/java/com/sun/ts/tests/jacc/util/unchecked.jsp deleted file mode 100644 index 46537b64e4..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/util/unchecked.jsp +++ /dev/null @@ -1,40 +0,0 @@ -<%-- - - Copyright (c) 2006, 2018 Oracle and/or its affiliates. All rights reserved. - - This program and the accompanying materials are made available under the - terms of the Eclipse Public License v. 2.0, which is available at - http://www.eclipse.org/legal/epl-2.0. - - This Source Code may also be made available under the following Secondary - Licenses when the conditions for such availability set forth in the - Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - version 2 with the GNU Classpath Exception, which is available at - https://www.gnu.org/software/classpath/license.html. - - SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - ---%> - - - -<%@ page language="java" %> - - -JSP used for verifying unchecked permission - -

    JSP used for unchecked permission

    - -<% - -out.println("The user principal is: " + request.getUserPrincipal().getName() + "
    "); -out.println("getRemoteUser(): " + request.getRemoteUser() + "
    " ); - -%> - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/build.xml deleted file mode 100644 index d35d8755fe..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/build.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/Client.java b/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/Client.java deleted file mode 100644 index 4ace07f494..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/Client.java +++ /dev/null @@ -1,347 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.web.containerContracts; - -import java.io.BufferedReader; -import java.io.IOException; -import java.io.InputStream; -import java.io.InputStreamReader; -import java.net.URL; -import java.net.URLConnection; -import java.util.Properties; - -import com.sun.javatest.Status; -import com.sun.ts.lib.harness.ServiceEETest; -import com.sun.ts.lib.porting.TSHttpsURLConnection; -import com.sun.ts.lib.porting.TSURL; -import com.sun.ts.lib.util.BASE64Encoder; -import com.sun.ts.lib.util.TSNamingContext; -import com.sun.ts.lib.util.TestUtil; -import com.sun.ts.tests.jacc.util.LogFileProcessor; - -public class Client extends ServiceEETest { - - private Properties props = null; - - private String hostname = null; - - private int portnum = 0; - - private String pageBase = "/jacc_web_containerContracts_web"; - - private String securedPage = "/secured.jsp"; - - private String sslProtectedPage = "/sslprotected.jsp"; - - private String authusername = ""; - - private String authpassword = ""; - - private String username = ""; - - private String password = ""; - - private int securedPortNum = 0; - - private TSNamingContext nctx = null; - - private LogFileProcessor logProcessor = null; - - public static void main(String args[]) { - Client theTests = new Client(); - Status s = theTests.run(args, System.out, System.err); - s.exit(); - } - - /** - * @class.setup_props: log.file.location; webServerHost; webServerPort; - * authuser; authpassword; user; password; - * securedWebServicePort; platform.mode; - * porting.ts.HttpsURLConnection.class.1; - * - */ - public void setup(String[] args, Properties p) throws Exception { - props = p; - - try { - hostname = p.getProperty("webServerHost"); - portnum = Integer.parseInt(p.getProperty("webServerPort")); - securedPortNum = Integer.parseInt(p.getProperty("securedWebServicePort")); - authusername = p.getProperty("authuser"); - authpassword = p.getProperty("authpassword"); - username = p.getProperty("user"); - password = p.getProperty("password"); - - nctx = new TSNamingContext(); - - // create LogFileProcessor - logProcessor = new LogFileProcessor(props); - // logProcessor = new LogFileProcessor(); - - // Retrieve logs - logProcessor.fetchLogs("pullAllLogRecords|fullLog"); - - } catch (Exception e) { - logErr("Error: got exception: ", e); - } - - } - - public void cleanup() throws Exception { // - } - - /** - * @testName: IsUserInRole - * - * @assertion_ids: JACC:SPEC:65; JACC:SPEC:32; JACC:SPEC:75 - * - * @test_Strategy: 1. Register TS provider with the AppServer. - * - * (Note: TSProvider is the delegating policy provider - * supplied with compatibility test suite. See User guide for - * Registering TS Provider with your AppServer ). - * - * 2. Deploy a jsp secured.jsp which is accessible by a role - * Administrator. - * - * 3. Assign javajoe to role Administrator and access the jsp - * - * 4. verify the rolename by calling isUserInRole() inside - * secured.jsp - * - */ - public void IsUserInRole() throws Exception { - - TSURL ctsurl = new TSURL(); - - String url = ctsurl.getURLString("http", hostname, portnum, - pageBase + securedPage); - try { - URL newURL = new URL(url); - - // Encode authData - String authData = authusername + ":" + authpassword; - TestUtil.logMsg("authData : " + authData); - - BASE64Encoder encoder = new BASE64Encoder(); - - String encodedAuthData = encoder.encode(authData.getBytes()); - TestUtil.logMsg("encoded authData : " + encodedAuthData); - - // open URLConnection - URLConnection urlConn = newURL.openConnection(); - - TestUtil.logMsg("HttpURLconnection established to :" + newURL.toString()); - - // set request property - urlConn.setRequestProperty("Authorization", - "Basic " + encodedAuthData.trim()); - - InputStream content = (InputStream) urlConn.getInputStream(); - BufferedReader in = new BufferedReader(new InputStreamReader(content)); - - String output = ""; - String line; - while ((line = in.readLine()) != null) { - output = output + line; - TestUtil.logMsg(line); - } - - TestUtil.logMsg("Data received" + output); - - // check for the occurance of the authusername - // in the output this ensures that the authorized user is - // able to access the resource secured.jsp - String stringToSearch = authusername; - if (output.indexOf(stringToSearch) == -1) { - throw new Exception("PermissionToRole: getRemoteUser(): " - + "- did not find \"" + stringToSearch + "\" in log."); - } else { - TestUtil.logMsg("User javajoe accessed secured.jsp"); - } - } catch (Exception e) { - TestUtil.logErr(e.getMessage(), e); - TestUtil.printStackTrace(e); - throw new Exception("IsUserInRole : FAILED", e); - } - } - - /** - * @testName: WebUserDataPermission - * - * @assertion_ids: JACC:SPEC:71; JACC:SPEC:117; JACC:SPEC:104; JACC:SPEC:113 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy a jsp called (sslprotected.jsp) with a security - * constraint that has a user-data-constraint - * CONFIDENTIAL - * - * 3. Send https request to sslprotected.jsp, access the - * content of sslprotected.jsp - * - * JSPName URL --------------------------------- - * sslprotecd.jsp /sslprotected.jsp - * - */ - public void WebUserDataPermission() throws Exception { - - boolean verified = false; - - TSURL ctsurl = new TSURL(); - - String url = ctsurl.getURLString("https", hostname, securedPortNum, - pageBase + sslProtectedPage); - try { - URL newURL = new URL(url); - - // Encode authData - String authData = authusername + ":" + authpassword; - TestUtil.logMsg("authData : " + authData); - - BASE64Encoder encoder = new BASE64Encoder(); - - String encodedAuthData = encoder.encode(authData.getBytes()); - TestUtil.logMsg("encoded authData : " + encodedAuthData); - - // open HttpsURLConnection - TSHttpsURLConnection httpsURLConn = new TSHttpsURLConnection(); - - if (httpsURLConn != null) { - TestUtil.logMsg("WebUserDataPermission(): hostname = " + hostname); - TestUtil.logMsg( - "WebUserDataPermission(): securedPortNum = " + securedPortNum); - TestUtil.logMsg("WebUserDataPermission(): pageBase = " + pageBase); - TestUtil.logMsg( - "WebUserDataPermission(): sslProtectedPage = " + sslProtectedPage); - TestUtil.logMsg( - "WebUserDataPermission(): url.toString() = " + url.toString()); - TestUtil.logMsg("WebUserDataPermission(): newURL.toString() = " - + newURL.toString()); - - TestUtil - .logMsg("Opening https url connection to: " + newURL.toString()); - httpsURLConn.init(newURL); - httpsURLConn.setDoInput(true); - httpsURLConn.setDoOutput(true); - httpsURLConn.setUseCaches(false); - - } else { - throw new Exception("Error opening httsURLConnection"); // set request - // property - } - httpsURLConn.setRequestProperty("Authorization", - "Basic " + encodedAuthData.trim()); - - InputStream content = (InputStream) httpsURLConn.getInputStream(); - - BufferedReader in = new BufferedReader(new InputStreamReader(content)); - - String output = ""; - String line; - while ((line = in.readLine()) != null) { - output = output + line; - TestUtil.logMsg(line); - } - - // check for the occurance of the authusername - // in the output this ensures that the authorized user is - // able to access the resource secured.jsp - String stringToSearch = authusername; - if (output.indexOf(stringToSearch) == -1) { - throw new Exception("PermissionToRole: getRemoteUser(): " - + "- did not find \"" + stringToSearch + "\" in log."); - } else { - TestUtil.logMsg("User javajoe accessed sslprotected.jsp"); - } - } catch (Exception e) { - throw new Exception("WebUserDataPermission : FAILED", e); - } - } - - /** - * @testName: WebResourcePermission - * - * @assertion_ids: JACC:SPEC:73; JACC:SPEC:117; JACC:SPEC:76 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy a jsp called (secured.jsp) configure it to be - * accessible only by Role Administrator - * - * 3. Access secured.jsp with a user(j2ee) who is not in role - * Administrator - * - * 4. expect proper Http error message. - * - * JSPName URL --------------------------------- secured.jsp - * /secured.jsp - * - */ - public void WebResourcePermission() throws Exception { - - TSURL ctsurl = new TSURL(); - - String url = ctsurl.getURLString("http", hostname, portnum, - pageBase + securedPage); - try { - URL newURL = new URL(url); - - // Encode authData - String authData = username + ":" + password; - TestUtil.logMsg("authData : " + authData); - - BASE64Encoder encoder = new BASE64Encoder(); - - String encodedAuthData = encoder.encode(authData.getBytes()); - TestUtil.logMsg("encoded authData : " + encodedAuthData); - - // open URLConnection - URLConnection urlConn = newURL.openConnection(); - - // set request property with user j2ee - // who is not in the Role Administrator - urlConn.setRequestProperty("Authorization", - "Basic " + encodedAuthData.trim()); - - InputStream content = (InputStream) urlConn.getInputStream(); - - BufferedReader in = new BufferedReader(new InputStreamReader(content)); - - String output = ""; - String line; - while ((line = in.readLine()) != null) { - output = output + line; - TestUtil.logMsg(line); - } - - // Control shouldn't reach this point - throw new Exception("WebResourcePermission test failed :" - + "User j2ee allowed to access secured.jsp"); - - } catch (IOException e) { - TestUtil.printStackTrace(e); - - TestUtil.logMsg("Got expected IOException : " - + "user j2ee not allowed to access secured.jsp "); - TestUtil.logMsg("WebResourcePermission test passed"); - } - - } -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/build.xml deleted file mode 100644 index 7445538cb5..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/build.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/jacc_web_containerContracts_web.war.sun-web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/jacc_web_containerContracts_web.war.sun-web.xml deleted file mode 100644 index e37851191d..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/jacc_web_containerContracts_web.war.sun-web.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - jacc_web_containerContracts_web - - Administrator - javajoe - - - Employee - j2ee - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/jacc_web_containerContracts_web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/jacc_web_containerContracts_web.xml deleted file mode 100644 index a639171604..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/containerContracts/jacc_web_containerContracts_web.xml +++ /dev/null @@ -1,88 +0,0 @@ - - - - - jacc_web_containerContracts - - sslprotected - sslprotected - /sslprotected.jsp - 0 - - ADM - Administrator - - - - secured - secured - /secured.jsp - 0 - - ADM - Administrator - - - - sslprotected - /sslprotected.jsp - - - secured - /secured.jsp - - - 54 - - - - MySecureBit3 - /secured.jsp - POST - GET - - - Administrator - - - NONE - - - - - MySecureBit6 - /sslprotected.jsp - POST - GET - - - Administrator - - - CONFIDENTIAL - - - - BASIC - default - - - Administrator - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/Client.java b/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/Client.java deleted file mode 100644 index 490cdf2bb0..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/Client.java +++ /dev/null @@ -1,231 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.web.principal2role; - -import java.io.BufferedReader; -import java.io.InputStream; -import java.io.InputStreamReader; -import java.net.URL; -import java.net.URLConnection; -import java.util.Properties; - -import com.sun.javatest.Status; -import com.sun.ts.lib.harness.ServiceEETest; -import com.sun.ts.lib.porting.TSURL; -import com.sun.ts.lib.util.BASE64Encoder; -import com.sun.ts.lib.util.TSNamingContext; -import com.sun.ts.lib.util.TestUtil; - -//import sun.misc.BASE64Encoder; -public class Client extends ServiceEETest { - // Shared test variables: - private Properties props = null; - - private String pageSec = null; - - private String pageSec1 = null; - - private String ctxroot = "/jacc_web_principal2role_first_module_web"; - - private String ctxroot1 = "/jacc_web_principal2role_second_module_web"; - - // two different web resources - private String pageJspSec = ctxroot + "/first_resource.jsp"; - - private String pageJspSec1 = ctxroot1 + "/second_resource.jsp"; - - private String hostname = null; - - private int portnum = 0; - - private String unauthusername = null; - - private String unauthpassword = null; - - private String username = null; - - private String password = null; - - private TSNamingContext nctx = null; - - public static void main(String[] args) { - - Client theTests = new Client(); - Status s = theTests.run(args, System.out, System.err); - s.exit(); - } - - /* - * @class.setup_props: webServerHost; webServerPort; user; password; authuser; - * authpassword; - * - */ - public void setup(String[] args, Properties p) throws Exception { - - try { - hostname = p.getProperty("webServerHost"); - portnum = Integer.parseInt(p.getProperty("webServerPort")); - - // j2ee is an authorized user - username = p.getProperty("user"); - password = p.getProperty("password"); - - // javajoe is an unauthorized user - unauthusername = p.getProperty("authuser"); - unauthpassword = p.getProperty("authpassword"); - - pageSec = pageJspSec; - pageSec1 = pageJspSec1; - - nctx = new TSNamingContext(); - - } catch (Exception e) { - logErr("Error in setup: ", e); - } - } - - /* - * @testName: PrincipalToRoleMapping - * - * @assertion_ids: JACC:SPEC:29; JACC:SPEC:124 - * - * @test_Strategy: 1) Create a application ear file with two web modules - * containing one webresource each. 2) In web module one - * (jacc_principal2role_first_module_web.war) allow role-name Administrator to - * access the resource(first_resource.jsp) 3) In web module two - * (jacc_principal2role_second_module_web.war) allow role-name Administrator - * to access the resource(second_resource.jsp) 4) Set the following - * principal-to-role mapping for the application - * Administrator j2ee - * - * Manager javajoe - * 5) Verify the same principal-to-role mapping is - * applied to both web modules by performing step6 and 7 6) Verify this by - * accessing webresource one(first_resource.jsp) from module one using - * authorized user(j2ee), make sure user j2ee is allowed access. Try accessing - * webresource one (first_resource.jsp) using unauthorized user(javajoe), make - * sure user javajoe is not allowed access this resource. 7) Repeat the step 6 - * for webresource two(second_resource.jsp) - * - */ - public void PrincipalToRoleMapping() throws Exception { - - TSURL ctsurl = new TSURL(); - - String firstURLstr = ctsurl.getURLString("http", hostname, portnum, - pageSec); - String secondURLstr = ctsurl.getURLString("http", hostname, portnum, - pageSec1); - - try { - URL firstURL = new URL(firstURLstr); - URL secondURL = new URL(secondURLstr); - - // Checking accessibility for a valid user to firstURL - TestUtil.logMsg("Verifying access rights"); - TestUtil.logMsg("***********************"); - TestUtil.logMsg("Authorized user " + username + " invoking " + firstURL); - if (isAccessible(firstURL, username, password)) { - TestUtil.logMsg("Access allowed"); - } else { - throw new Exception("Authorized user acesss denied"); - } - - // Checking accessibility for an unauthorized user to firstURL - TestUtil.logMsg( - "Unauthorized user " + unauthusername + " invoking " + firstURL); - if (!isAccessible(firstURL, unauthusername, unauthpassword)) { - TestUtil.logMsg("Access denied"); - } else { - throw new Exception("Unauthorized user access allowed"); - } - - // Checking accessibility for a valid user to SecondURL - TestUtil.logMsg("Authorized user " + username + " invoking " + secondURL); - if (isAccessible(secondURL, username, password)) { - TestUtil.logMsg("Access allowed"); - } else { - throw new Exception("Authorized user acesss denied"); - } - - // Checking accessibility for an unauthorized user to secondURL - TestUtil.logMsg( - "Unauthorized user " + unauthusername + " invoking " + secondURL); - if (!isAccessible(secondURL, unauthusername, unauthpassword)) { - TestUtil.logMsg("Access denied"); - } else { - throw new Exception("Unauthorized user access allowed"); - } - - TestUtil.logMsg( - "Same PrincipalToRoleMapping applied for both " + "web modules"); - - } catch (Exception e) { - TestUtil.logMsg("Test PrincipalToRoleMapping failed"); - e.printStackTrace(); - throw new Exception("Test PrincipalToRoleMapping failed"); - } - } - - public void cleanup() throws Exception { - // - } - - public boolean isAccessible(URL url, String user, String pwd) { - - try { - // Encode authData - String authData = user + ":" + pwd; - // TestUtil.logMsg("authData : "+authData); - - BASE64Encoder encoder = new BASE64Encoder(); - String encodedAuthData = encoder.encode(authData.getBytes()); - // TestUtil.logMsg("encoded authData : "+ encodedAuthData); - - // open URLConnection - URLConnection urlConn = url.openConnection(); - - // set request property - urlConn.setRequestProperty("Authorization", - "Basic " + encodedAuthData.trim()); - - InputStream content = (InputStream) urlConn.getInputStream(); - - BufferedReader in = new BufferedReader(new InputStreamReader(content)); - - String output = ""; - String line; - // TestUtil.logMsg("Output from "+url); - while ((line = in.readLine()) != null) { - output = output + line; - // TestUtil.logMsg(line); - } - - // check for the occurance of the user - // in the output this ensures that the authorized user is - // able to access the given url - String stringToSearch = user; - if (output.indexOf(stringToSearch) == -1) { - return false; - } - return true; - } catch (Exception e) { - // e.printStackTrace(); - return false; - } - } -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/build.xml deleted file mode 100644 index 2ad9ecad46..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/build.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/first_resource.jsp b/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/first_resource.jsp deleted file mode 100644 index e6cde809fc..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/first_resource.jsp +++ /dev/null @@ -1,42 +0,0 @@ -<%-- - - Copyright (c) 2008, 2018 Oracle and/or its affiliates. All rights reserved. - - This program and the accompanying materials are made available under the - terms of the Eclipse Public License v. 2.0, which is available at - http://www.eclipse.org/legal/epl-2.0. - - This Source Code may also be made available under the following Secondary - Licenses when the conditions for such availability set forth in the - Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - version 2 with the GNU Classpath Exception, which is available at - https://www.gnu.org/software/classpath/license.html. - - SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - ---%> - -<%@ page language="java" %> - - - JSP with Security Constraint - -

    JSP with Security Constraint

    - <% - - out.println("The user principal is: " + request.getUserPrincipal().getName() + "
    "); - out.println("getRemoteUser(): " + request.getRemoteUser() + "
    " ); - - // Surround these with !'s so they are easier to search for. - // (i.e. we can search for !true! or !false!) - out.println("isUserInRole(\"ADM\"): !" + request.isUserInRole("ADM") + "!
    "); - out.println("isUserInRole(\"MGR\"): !" + request.isUserInRole("MGR") + "!
    "); - out.println("isUserInRole(\"VP\"): !" + request.isUserInRole("VP") + "!
    "); - out.println("isUserInRole(\"EMP\"): !" + request.isUserInRole("EMP") + "!
    "); - out.println("isUserInRole(\"Administrator\"): !" + request.isUserInRole("Administrator") + "!
    "); - - %> - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_first_module_web.war.sun-web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_first_module_web.war.sun-web.xml deleted file mode 100644 index 302ec4f89b..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_first_module_web.war.sun-web.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - jacc_web_principal2role_first_module_web - - Administrator - j2ee - - - Manager - javajoe - - - Employee - javajoe - j2ee - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_first_module_web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_first_module_web.xml deleted file mode 100644 index 3a7df55b50..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_first_module_web.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - jacc_principal2role_first_module - - first_resource - /first_resource.jsp - 0 - - - first_resource - /first_resource.jsp - - - 5 - - - - MySecureBit0 - /first_resource.jsp - GET - POST - - - Administrator - - - NONE - - - - BASIC - default - - - the administrator role - Administrator - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_second_module_web.war.sun-web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_second_module_web.war.sun-web.xml deleted file mode 100644 index 7e70b94d91..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_second_module_web.war.sun-web.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - jacc_web_principal2role_second_module_web - - Administrator - j2ee - - - Manager - javajoe - - - Employee - javajoe - j2ee - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_second_module_web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_second_module_web.xml deleted file mode 100644 index 78d50ffdce..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/jacc_web_principal2role_second_module_web.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - jacc_web_principal2role_second_module - - second_resource - /second_resource.jsp - 0 - - - second_resource - /second_resource.jsp - - - 5 - - - - MySecureBit0 - /second_resource.jsp - GET - POST - - - Administrator - - - NONE - - - - BASIC - default - - - the administrator role - Administrator - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/second_resource.jsp b/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/second_resource.jsp deleted file mode 100644 index e6cde809fc..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/principal2role/second_resource.jsp +++ /dev/null @@ -1,42 +0,0 @@ -<%-- - - Copyright (c) 2008, 2018 Oracle and/or its affiliates. All rights reserved. - - This program and the accompanying materials are made available under the - terms of the Eclipse Public License v. 2.0, which is available at - http://www.eclipse.org/legal/epl-2.0. - - This Source Code may also be made available under the following Secondary - Licenses when the conditions for such availability set forth in the - Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - version 2 with the GNU Classpath Exception, which is available at - https://www.gnu.org/software/classpath/license.html. - - SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - ---%> - -<%@ page language="java" %> - - - JSP with Security Constraint - -

    JSP with Security Constraint

    - <% - - out.println("The user principal is: " + request.getUserPrincipal().getName() + "
    "); - out.println("getRemoteUser(): " + request.getRemoteUser() + "
    " ); - - // Surround these with !'s so they are easier to search for. - // (i.e. we can search for !true! or !false!) - out.println("isUserInRole(\"ADM\"): !" + request.isUserInRole("ADM") + "!
    "); - out.println("isUserInRole(\"MGR\"): !" + request.isUserInRole("MGR") + "!
    "); - out.println("isUserInRole(\"VP\"): !" + request.isUserInRole("VP") + "!
    "); - out.println("isUserInRole(\"EMP\"): !" + request.isUserInRole("EMP") + "!
    "); - out.println("isUserInRole(\"Administrator\"): !" + request.isUserInRole("Administrator") + "!
    "); - - %> - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/Client.java b/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/Client.java deleted file mode 100644 index bd3ba516c5..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/Client.java +++ /dev/null @@ -1,501 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.web.providerContracts; - -import java.io.BufferedReader; -import java.io.InputStream; -import java.io.InputStreamReader; -import java.net.HttpURLConnection; -import java.net.URL; -import java.net.URLConnection; -import java.util.Collection; -import java.util.Iterator; -import java.util.Properties; - -import com.sun.javatest.Status; -import com.sun.ts.lib.harness.ServiceEETest; -import com.sun.ts.lib.porting.TSURL; -import com.sun.ts.lib.util.BASE64Encoder; -import com.sun.ts.lib.util.TSNamingContext; -import com.sun.ts.lib.util.TestUtil; -import com.sun.ts.tests.jacc.util.LogFileProcessor; -import com.sun.ts.tests.jacc.util.LogRecordEntry; - -//import sun.misc.*; -public class Client extends ServiceEETest { - - private Properties props = null; - - private String contextId = "jacc_ctx"; - - private String hostname = null; - - private int portnum = 0; - - private String pageBase = "/jacc_web_providerContracts_web"; - - private String securedPage = "/secured.jsp"; - - private String accessToAllPage = "/AccessToAll.jsp"; - - private String anyAuthUserPage = "/anyauthuser.jsp"; - - private String authusername = ""; - - private String authpassword = ""; - - private TSNamingContext nctx = null; - - LogFileProcessor logProcessor = null; - - public static void main(String args[]) { - Client theTests = new Client(); - Status s = theTests.run(args, System.out, System.err); - s.exit(); - } - - /** - * @class.setup_props: log.file.location; webServerHost; webServerPort; - * authuser; authpassword; - * - */ - public void setup(String[] args, Properties p) throws Exception { - props = p; - boolean pass = true; - - try { - hostname = p.getProperty("webServerHost"); - portnum = Integer.parseInt(p.getProperty("webServerPort")); - authusername = p.getProperty("authuser"); - authpassword = p.getProperty("authpassword"); - - nctx = new TSNamingContext(); - - // create LogProcessor - logProcessor = new LogFileProcessor(props); - - // Retrieve logs that matches with contextId - logProcessor.fetchLogs(contextId); - - } catch (Exception e) { - logErr("Error: got exception: ", e); - } - - } - - public void cleanup() throws Exception { - // - } - - /** - * @testName: WildCardAuthConstraint - * - * @assertion_ids: JACC:SPEC:35; JACC:SPEC:10; JACC:JAVADOC:19; - * JACC:JAVADOC:25; JACC:JAVADOC:26; JACC:JAVADOC:27; - * JACC:JAVADOC:30; JACC:JAVADOC:31; JACC:SPEC:129; - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy a jsp AccessToAll.jsp which contains a wildcard - * auth constraint (i.e "*" as shown below) in its security - * constraint. * - * - * - * 3. Access the jsp /AccessToAll.jsp from the client. - * - * 4. Make sure the login user javajoe is able to access the - * jsp /AccessToAll.jsp - * - * 4. Make sure the login user is mapped to all roles defined - * in the application (i.e. ADM, EMP and MGR) i.e a) - * isUserInRole("ADM") should return true and b) - * isUserInRole("MGR") should return true and c) - * isUserInRole("EMP") should return true - * - * 5. Make sure the login user is not in the role that is not - * defined in the application. i.e isUserInRole("VP") should - * return false - */ - public void WildCardAuthConstraint() throws Exception { - - TSURL ctsurl = new TSURL(); - - String url = ctsurl.getURLString("http", hostname, portnum, - pageBase + accessToAllPage); - try { - URL newURL = new URL(url); - - // Encode authData - String authData = authusername + ":" + authpassword; - TestUtil.logMsg("authData : " + authData); - - BASE64Encoder encoder = new BASE64Encoder(); - - String encodedAuthData = encoder.encode(authData.getBytes()); - TestUtil.logMsg("encoded authData : " + encodedAuthData); - - // open URLConnection - URLConnection urlConn = newURL.openConnection(); - - // set request property - urlConn.setRequestProperty("Authorization", - "Basic " + encodedAuthData.trim()); - - InputStream content = (InputStream) urlConn.getInputStream(); - - String cookies = null; - - for (int i = 0;; i++) { - String header = urlConn.getHeaderField(i); - // TestUtil.logMsg("Header "+i+"= "+header); - - if (header == null) { - break; - } - if ((header.indexOf("JSESSIONIDSSO") != -1) - || (header.indexOf("JSESSIONID") != -1)) { - cookies = addCookies(header, cookies); - } - } - - TestUtil.logMsg("cookies received = " + cookies); - - BufferedReader in = new BufferedReader(new InputStreamReader(content)); - - String output = ""; - String line; - while ((line = in.readLine()) != null) { - output = output + line; - TestUtil.logMsg(line); - } - - // check for the occurance of the authusername - // in the output this ensures that the authorized user is - // able to access the resource AccessToAll.jsp - String stringToSearch = authusername; - if (output.indexOf(stringToSearch) == -1) { - throw new Exception("AccessToAll.jsp: getRemoteUser(): " - + "- did not find \"" + stringToSearch + "\" in log."); - } else { - TestUtil.logMsg("User javajoe accessed AccessToAll.jsp"); // look for - // String - // "USR_IN_ROLE_ADM" - } - stringToSearch = "USR_IN_ROLE_ADM"; - if (output.indexOf(stringToSearch) == -1) { - throw new Exception( - "AccessToAll.jsp: getRemoteUser(): " + "- not mapped to role ADM"); - } else { - TestUtil.logMsg("User in Role ADM"); // look for String - // "USR_IN_ROLE_MGR" - } - stringToSearch = "USR_IN_ROLE_MGR"; - if (output.indexOf(stringToSearch) == -1) { - throw new Exception( - "AccessToAll.jsp: getRemoteUser(): " + "- not mapped to role MGR"); - } else { - TestUtil.logMsg("User in Role MGR"); // look for String - // "USR_IN_ROLE_EMP" - } - stringToSearch = "USR_IN_ROLE_EMP"; - if (output.indexOf(stringToSearch) == -1) { - throw new Exception( - "AccessToAll.jsp: getRemoteUser(): " + "- not mapped to role EMP"); - } else { - TestUtil.logMsg("User in Role EMP"); // look for String - // "USR_NOT_IN_ROLE_VP" - } - stringToSearch = "USR_NOT_IN_ROLE_VP"; - if (output.indexOf(stringToSearch) == -1) { - throw new Exception( - "AccessToAll.jsp: getRemoteUser(): " + "- mapped to role VP"); - } else { - TestUtil.logMsg("User not in Role VP"); - } - - // to test assertion JACC:SPEC:129 - stringToSearch = "USR_IN_ROLE_STARSTAR"; - if (output.indexOf(stringToSearch) == -1) { - // should get here since we did not create any role-ref or role named - // "**". - TestUtil.logMsg("User is correctly not in any Role named '**'"); - } else { - throw new Exception( - "anyauthuser.jsp: getRemoteUser() - incorrectly mapped to role named '**'"); - } - - } catch (Exception e) { - throw new Exception("Test WildCardAuthConstraint : FAILED", e); - } - - } - - /** - * @testName: PermissionsToRole - * - * @assertion_ids: JACC:SPEC:65; JACC:SPEC:10; JACC:JAVADOC:19; - * JACC:JAVADOC:25; JACC:JAVADOC:26; JACC:JAVADOC:27; - * JACC:JAVADOC:30; JACC:JAVADOC:31 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy a jsp secured.jsp which is accessible by a role - * Administrator. - * - * 3. Assign javajoe to role Administrator and access the jsp - * - * 4. If javajoe can access secured.jsp this implies all users - * mapped to Administrator can access secured.jsp - * - * Note: Invoking PermissionsToRole assumes that the - * TSProvider was alreaded loaded and this triggers indirectly - * invoking other JAVADOC APIs - */ - public void PermissionsToRole() throws Exception { - - TSURL ctsurl = new TSURL(); - - String url = ctsurl.getURLString("http", hostname, portnum, - pageBase + securedPage); - try { - URL newURL = new URL(url); - - // Encode authData - String authData = authusername + ":" + authpassword; - TestUtil.logMsg("authData : " + authData); - - BASE64Encoder encoder = new BASE64Encoder(); - - String encodedAuthData = encoder.encode(authData.getBytes()); - TestUtil.logMsg("encoded authData : " + encodedAuthData); - - // open URLConnection - URLConnection urlConn = newURL.openConnection(); - - // set request property - urlConn.setRequestProperty("Authorization", - "Basic " + encodedAuthData.trim()); - - InputStream content = (InputStream) urlConn.getInputStream(); - - String cookies = null; - - for (int i = 0;; i++) { - String header = urlConn.getHeaderField(i); - // TestUtil.logMsg("Header "+i+"= "+header); - - if (header == null) { - break; - } - if ((header.indexOf("JSESSIONIDSSO") != -1) - || (header.indexOf("JSESSIONID") != -1)) { - cookies = addCookies(header, cookies); - } - } - - TestUtil.logMsg("cookies received = " + cookies); - - BufferedReader in = new BufferedReader(new InputStreamReader(content)); - - String output = ""; - String line; - while ((line = in.readLine()) != null) { - output = output + line; - // TestUtil.logMsg (line); - } - - // check for the occurance of the authusername - // in the output this ensures that the authorized user is - // able to access the resource secured.jsp - String stringToSearch = authusername; - if (output.indexOf(stringToSearch) == -1) { - throw new Exception("PermissionToRole: getRemoteUser(): " - + "- did not find \"" + stringToSearch + "\" in log."); - } else { - TestUtil.logMsg("User javajoe accessed secured.jsp"); - } - } catch (Exception e) { - throw new Exception("Test PermissionToRole : FAILED", e); - } - - } - - /** - * @testName: anyAuthUserWebResPermAddedToRole - * - * @assertion_ids: JACC:SPEC:128; - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. deploy contents of this test dir (this test is most - * concnerned with deployment of anyauthuser.jsp which - * specifies role "**" in the auth-constraint element. This - * should cause a WebResourcePermission to be added to the - * "**" role.) - * - * 3. attempt to access the deployed anyauthuser.jsp - * - * 4. At this point, there should be an entry in the - * JACCLog.txt file that begins with "MSG_TAG" and it shold - * contain a message about the WebResourcePermission being - * added for role "**" with page anyauthuser being referenced. - * We will parse the entries of the JACCLog.txt and search for - * our string info that indicates proper message info was - * dumped for the servlet that had an auth-constraint = "**". - * - */ - public void anyAuthUserWebResPermAddedToRole() throws Exception { - - boolean bSuccess = false; - - try { - - // lets invoke our doc to make sure deploymenbt did occur and that - // translation of the DD security elements did occur. If they did - // not properly occur, we should not be able to invoke the servlet - // and that means the rest of our tests is going to fail. - String servletPath = pageBase + anyAuthUserPage; - invokeServlet(servletPath, "POST"); - - // - // ok, now validate the log file had content we expected to see - // this is done in the following steps: - // - - // 1. get all log messages needed to test assertion 128 (they all - // shoudl start with "MSG_TAG". the ones containing info about - // WebResourcePermission are specific to assertion JACC:SPEC:128 - String searchStr = "MSG_TAG :: WebResourcePermission :: **"; - Collection col = logProcessor.getMsgTagRecordCollection(); - TestUtil.logMsg("col.size() = " + col.size()); - - // 2. find one of these log messages that matches our "anyauthuser" - // servlet - // and was that resulted from this appContext/pageBase - Iterator iterator = col.iterator(); - - while (iterator.hasNext()) { - LogRecordEntry recordEntry = (LogRecordEntry) iterator.next(); - String msg = recordEntry.getMessage(); - if ((msg != null) && msg.startsWith(searchStr) - && (msg.indexOf("anyauthuser") > 0)) { - // SUCCESS: we found a matching record entry which means - // a WebResourcePermission was added to Role "**" for our - // "anyauthuser" servlet that specifies "**" in its auth-constraint - bSuccess = true; - } - } - } catch (Exception ex) { - ex.printStackTrace(); - throw new Exception("Test anyAuthUserWebResPermAddedToRole : FAILED", ex); - } - - if (bSuccess) { - TestUtil.logMsg("Test anyAuthUserWebResPermAddedToRole Passed."); - } else { - throw new Exception("Test anyAuthUserWebResPermAddedToRole : FAILED"); - } - } - - /* - * Convenience method that will establish a url connections and perform a - * get/post request. A username and password will be passed in the request - * header and they will be encoded using the BASE64Encoder class. - */ - private int invokeServlet(String sContext, String requestMethod) { - int code = 200; - - TSURL ctsurl = new TSURL(); - if (!sContext.startsWith("/")) { - sContext = "/" + sContext; - } - - String url = ctsurl.getURLString("http", hostname, portnum, sContext); - try { - URL newURL = new URL(url); - - // Encode authData - // hint: make sure username and password are valid for your - // (J2EE) security realm otherwise you recieve http 401 error. - String authData = authusername + ":" + authpassword; - TestUtil.logMsg("authData : " + authData); - - BASE64Encoder encoder = new BASE64Encoder(); - - String encodedAuthData = encoder.encode(authData.getBytes()); - TestUtil.logMsg("encoded authData : " + encodedAuthData); - - // open URLConnection - HttpURLConnection conn = (HttpURLConnection) newURL.openConnection(); - - // set request property - conn.setDoOutput(true); - conn.setDoInput(true); - conn.setRequestProperty("Authorization", - "Basic " + encodedAuthData.trim()); - conn.setRequestMethod(requestMethod); // POST or GET etc - conn.connect(); - - TestUtil.logMsg("called HttpURLConnection.connect() for url: " + url); - code = conn.getResponseCode(); - TestUtil.logMsg("Got response code of: " + code); - String str = conn.getResponseMessage(); - TestUtil.logMsg("Got response string of: " + str); - - /* - * // DEBUG AID InputStream content = (InputStream)conn.getInputStream(); - * BufferedReader in = new BufferedReader(new InputStreamReader(content)); - * try { String line; while ((line = in.readLine()) != null) { - * TestUtil.logMsg(line); } } finally { in.close(); } - */ - } catch (Exception e) { - TestUtil.logMsg( - "Abnormal return status encountered while invoking " + sContext); - TestUtil.logMsg("Exception Message was: " + e.getMessage()); - e.printStackTrace(); - } - - return code; - } // invokeServlet() - - public String addCookies(String cookieHeader, String cookies) { - - String cookie; - - if (cookieHeader == null) { - return null; - } - - int j = cookieHeader.indexOf(";"); - - if (j != -1) { - String cValue = cookieHeader.substring(0, j); - cookie = cValue.trim(); - } else { - cookie = cookieHeader.trim(); // append cookie with existing cookies - } - if (cookies == null) { - cookies = cookie; - } else { - cookies += ";" + cookie; - } - return cookies; - } -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/build.xml deleted file mode 100644 index a3b1c764f2..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/build.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/jacc_web_providerContracts_web.war.sun-web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/jacc_web_providerContracts_web.war.sun-web.xml deleted file mode 100644 index 65a3610eac..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/jacc_web_providerContracts_web.war.sun-web.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - - jacc_web_providerContracts_web - - Administrator - javajoe - j2ee - - - Manager - javajoe - - - Employee - javajoe - j2ee - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/jacc_web_providerContracts_web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/jacc_web_providerContracts_web.xml deleted file mode 100644 index eb34ec2989..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/providerContracts/jacc_web_providerContracts_web.xml +++ /dev/null @@ -1,127 +0,0 @@ - - - - - jacc_web_providerContracts - - AccessToAll - AccessToAll - /AccessToAll.jsp - 0 - - ADM - Administrator - - - EMP - Employee - - - MGR - Manager - - - - secured - secured - /secured.jsp - 0 - - ADM - Administrator - - - - anyauthuser - anyauthuser - /anyauthuser.jsp - 0 - - - AccessToAll - /AccessToAll.jsp - - - secured - /secured.jsp - - - anyauthuser - /anyauthuser.jsp - - - 54 - - - - MySecureBit3 - /secured.jsp - POST - GET - - - Administrator - - - NONE - - - - - MySecureBit4 - /AccessToAll.jsp - POST - GET - - - * - - - NONE - - - - - MySecureBit7 - /anyauthuser.jsp - POST - GET - - - ** - - - NONE - - - - BASIC - default - - - Administrator - - - Employee - - - Manager - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/Client.java b/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/Client.java deleted file mode 100644 index cbf4b5a31b..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/Client.java +++ /dev/null @@ -1,961 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -package com.sun.ts.tests.jacc.web.toolsContracts; - -import java.security.Permissions; -import java.util.Properties; - -import com.sun.javatest.Status; -import com.sun.ts.lib.harness.ServiceEETest; -import com.sun.ts.lib.util.TestUtil; -import com.sun.ts.tests.jacc.util.LogFileProcessor; - -import jakarta.security.jacc.WebResourcePermission; -import jakarta.security.jacc.WebRoleRefPermission; -import jakarta.security.jacc.WebUserDataPermission; - -// CAUTION: *** The expected permissions constructed for various permissions -// such as WebResourcePermission, WebRoleRefPermission, -// WebUserDataPermission are based on the application -// jacc_toolsContracts. If the application is modified for -// any reason then the expected permissions should also be -// modified accordingly. *** -// -public class Client extends ServiceEETest { - - private Properties props = null; - - private String contextId = "jacc_ctx"; - - LogFileProcessor logProcessor = null; - - private String applicationContext; - - private boolean initialized = false; - - private Permissions unCheckedPermissions = new Permissions(); - - private Permissions excludedPermissions = new Permissions(); - - private Permissions addToRolePermissions = new Permissions(); - - public static void main(String args[]) { - Client theTests = new Client(); - Status s = theTests.run(args, System.out, System.err); - s.exit(); - } - - /** - * @class.setup_props: log.file.location; webServerHost; webServerPort; - * - * - */ - public void setup(String[] args, Properties p) throws Exception { - props = p; - if (!initialized) { - // create LogFileProcessor - logProcessor = new LogFileProcessor(props); - - // retrieve logs based on application Name - logProcessor.fetchLogs("getAppSpecificRecordCollection|appId", - "toolsContracts"); - - // retrieve unchecked permissions as a permission collection - unCheckedPermissions = logProcessor.getAppSpecificUnCheckedPermissions(); - - // retrieve excluded permissions as a permission collection - excludedPermissions = logProcessor.getAppSpecificExcludedPermissions(); - - // retrieve addToRole permissions as a permission collection - addToRolePermissions = logProcessor.getAppSpecificAddToRolePermissions(); - - initialized = true; - } - } - - public void cleanup() throws Exception { - - } - - /** - * @testName: WebResourcePermission - * - * @assertion_ids: JACC:SPEC:36; JACC:SPEC:72; JACC:SPEC:27; JACC:SPEC:28; - * JACC:SPEC:52; JACC:SPEC:128; - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy the application. - * - * 3. During deployment, appserver generates permissions for - * the J2EE components based on the given deployment - * descriptor - * - * 4. Retrieve server side logs and verify the generated - * permissions matches the expected permission collection - * - */ - public void WebResourcePermission() throws Exception { - boolean verified = false; - Permissions expectedUnCheckedPermissions = new Permissions(); - Permissions expectedExcludedPermissions = new Permissions(); - Permissions expectedAddToRolePermissions = new Permissions(); - - // ----------UNCHECKED----------// - // 1) retrieve server generated unchecked policy statements - // 2) construct expected unchecked policy statements - // 3) verify expected policy statements with generated policy statements - - // Get "unchecked" WebResourcePermissions - Permissions uncheckedWebResourcePermissions = logProcessor - .getSpecificPermissions(unCheckedPermissions, "WebResourcePermission"); - - TestUtil.logMsg("Server generated unchecked WebResourcePermissions"); - logProcessor.printPermissionCollection(uncheckedWebResourcePermissions); - - // Construct the expected unchecked WebResourcePermission - expectedUnCheckedPermissions - .add(new WebResourcePermission("/unchecked.jsp", (String) null)); - expectedUnCheckedPermissions - .add(new WebResourcePermission("/sslprotected.jsp", "!GET,POST")); - expectedUnCheckedPermissions.add(new WebResourcePermission( - "/:/secured.jsp:/unchecked.jsp:/excluded.jsp:/sslprotected.jsp:/anyauthuser.jsp", - (String) null)); - expectedUnCheckedPermissions - .add(new WebResourcePermission("/excluded.jsp", "!GET,POST")); - expectedUnCheckedPermissions - .add(new WebResourcePermission("/secured.jsp", "!GET,POST")); - expectedUnCheckedPermissions - .add(new WebResourcePermission("/anyauthuser.jsp", "!GET,POST")); - - TestUtil.logMsg("verifying unchecked policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedUnCheckedPermissions, - uncheckedWebResourcePermissions); - - if (!verified) { - throw new Exception("WebResourcePermission failed: " - + "unchecked policy statements verification failed"); - } else { - TestUtil.logMsg("unchecked policy statements verification successful"); - } - - // ---------EXCLUDED----------// - // 1) retrieve server generated excluded policy statements - // 2) construct expected excluded policy statements - // 3) verify expected policy statements with generated policy statements - - // Get "excluded" WebResourcePermissions - Permissions excludedWebResourcePermissions = logProcessor - .getSpecificPermissions(excludedPermissions, "WebResourcePermission"); - - TestUtil.logMsg("Server generated excluded WebResourcePermissions"); - logProcessor.printPermissionCollection(excludedWebResourcePermissions); - - // Construct the expected excluded WebResourcePermission - expectedExcludedPermissions - .add(new WebResourcePermission("/excluded.jsp", "GET,POST")); - - TestUtil.logMsg("verifying excluded policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedExcludedPermissions, - excludedWebResourcePermissions); - - if (!verified) { - throw new Exception("WebResourcePermission failed: " - + "excluded policy statements verification failed"); - } else { - TestUtil.logMsg("excluded policy statements verification successful"); - } - - // ---------ADDTOROLE----------// - // 1) retrieve server generated addToRole policy statements - // 2) construct expected addToRole policy statements - // 3) verify expected policy statements with generated policy statements - - // Get "addToRole" WebResourcePermissions - Permissions addToRoleWebResourcePermissions = logProcessor - .getSpecificPermissions(addToRolePermissions, "WebResourcePermission"); - - TestUtil.logMsg("Server generated addToRole WebResourcePermissions"); - logProcessor.printPermissionCollection(addToRoleWebResourcePermissions); - - // Construct the expected excluded WebResourcePermission - expectedAddToRolePermissions - .add(new WebResourcePermission("/secured.jsp", "GET,POST")); - expectedAddToRolePermissions - .add(new WebResourcePermission("/sslprotected.jsp", "GET,POST")); - expectedAddToRolePermissions - .add(new WebResourcePermission("/anyauthuser.jsp", "GET,POST")); - - TestUtil.logMsg("verifying addToRole policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedAddToRolePermissions, - addToRoleWebResourcePermissions); - - if (!verified) { - throw new Exception("WebResourcePermission failed: " - + "addToRole policy statements verification failed"); - } else { - TestUtil.logMsg("addToRole policy statements verification successful"); - } - } - - /** - * @testName: WebRoleRefPermission - * - * @assertion_ids: JACC:SPEC:36; JACC:SPEC:112; JACC:SPEC:38; JACC:SPEC:43; - * JACC:SPEC:44; JACC:JAVADOC:50; JACC:SPEC:27; JACC:SPEC:28; - * JACC:SPEC:45; JACC:SPEC:52; JACC:SPEC:75; JACC:SPEC:128; - * JACC:SPEC:131 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). 2. - * Deploy the application. - * - * 3. During deployment, appserver generates permissions for - * the J2EE components based on the given deployment - * descriptor - * - * 4. Retrieve server side logs and verify the generated - * permissions matches the expected permission collection - */ - public void WebRoleRefPermission() throws Exception { - boolean verified = false; - Permissions expectedAddToRolePermissions = new Permissions(); - - // ---------ADDTOROLE----------// - // 1) retrieve server generated addToRole policy statements - // 2) construct expected addToRole policy statements - // 3) verify expected policy statements with generated policy statements - - // Get "addToRole" WebRoleRefPermissions - Permissions addToRoleWebRoleRefPermissions = logProcessor - .getSpecificPermissions(addToRolePermissions, "WebRoleRefPermission"); - - TestUtil.logMsg("Server generated addToRole WebRoleRefPermissions"); - logProcessor.printPermissionCollection(addToRoleWebRoleRefPermissions); - - // Construct the expected excluded WebRoleRefPermission - expectedAddToRolePermissions - .add(new WebRoleRefPermission("secured", "ADM")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("secured", "Administrator")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("secured", "Manager")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("secured", "Employee")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("sslprotected", "MGR")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("sslprotected", "ADM")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("sslprotected", "Administrator")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("sslprotected", "Manager")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("sslprotected", "Employee")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("unchecked", "Manager")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("unchecked", "Administrator")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("unchecked", "Employee")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("excluded", "Manager")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("excluded", "Administrator")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("excluded", "Employee")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("anyauthuser", "Employee")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("anyauthuser", "Manager")); - expectedAddToRolePermissions - .add(new WebRoleRefPermission("anyauthuser", "Administrator")); - - // JSR115 Maintenance Review changes - expectedAddToRolePermissions - .add(new WebRoleRefPermission("", "Administrator")); - expectedAddToRolePermissions.add(new WebRoleRefPermission("", "Manager")); - expectedAddToRolePermissions.add(new WebRoleRefPermission("", "Employee")); - - TestUtil.logMsg("verifying addToRole policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedAddToRolePermissions, - addToRoleWebRoleRefPermissions); - - if (!verified) { - throw new Exception("WebRoleRefPermission failed: " - + "addToRole policy statements verification failed"); - } else { - TestUtil.logMsg("addToRole policy statements verification successful"); - } - } - - /** - * @testName: AnyAuthUserWebRoleRef - * - * @assertion_ids: JACC:SPEC:130; JACC:SPEC:131; - * - * @test_Strategy: This is testing that: If the any authenticated user - * role-name, **, does not appear in a security-role-ref - * within the servlet, a WebRoleRefPermission must also be - * added for it. The name of each such WebRoleRefPermission - * must be the servlet-name of the corresponding servlet - * element. steps: 1. We have any-authenticated-user - * referenced in a security-constraint in our DD (for - * anyauthuser.jsp) We have a total of 5 servlets defined in - * our DD also. - * - * 2. Deploy the application. - * - * 3. During deployment, appserver generates permissions for - * the J2EE components based on the given deployment - * descriptor - * - * 4. Retrieve server side logs and verify the generated - * permissions matches the expected permission collection - */ - public void AnyAuthUserWebRoleRef() throws Exception { - boolean verified = false; - Permissions expectedAddToRolePerms = new Permissions(); - - // retrieve server generated addToRole policy statements - Permissions addToRoleWebRoleRefPermissions = logProcessor - .getSpecificPermissions(addToRolePermissions, "WebRoleRefPermission"); - - // for debug aid, print out server generated addToRole policy statements - TestUtil.logMsg("Server generated addToRole WebRoleRefPermissions"); - logProcessor.printPermissionCollection(addToRoleWebRoleRefPermissions); - - // according to jacc 1.5 spec (chapter 3, section 3.1.3.3), it states that - // "a WebRoleRefPermission must also be added for it" (meaning **) and that - // "The name of each such WebRoleRefPermission must be the servlet-name - // of the corresponding servlet element." - // This means for each servlet definition in our web.xml, there will need to - // exist a WebRoleRefPermission with that servlet name for the ** role. - // - expectedAddToRolePerms.add(new WebRoleRefPermission("excluded", "**")); - expectedAddToRolePerms.add(new WebRoleRefPermission("unchecked", "**")); - expectedAddToRolePerms.add(new WebRoleRefPermission("sslprotected", "**")); - expectedAddToRolePerms.add(new WebRoleRefPermission("secured", "**")); - expectedAddToRolePerms.add(new WebRoleRefPermission("anyauthuser", "**")); - - TestUtil.logMsg("verifying addToRole policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedAddToRolePerms, - addToRoleWebRoleRefPermissions); - - if (!verified) { - throw new Exception("AnyAuthUserWebRoleRef failed: " - + "addToRole policy statements for any-authenticated-user (**) failed"); - } else { - TestUtil.logMsg("addToRole policy statements verification successful"); - } - - } - - /** - * @testName: WebResourcePermissionExcludedPolicy - * - * @assertion_ids: JACC:SPEC:37; JACC:SPEC:114; JACC:SPEC:111; JACC:SPEC:27; - * JACC:SPEC:28; JACC:SPEC:34; JACC:SPEC:52 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy the application. - * - * 3. During deployment, appserver generates permissions for - * the J2EE components based on the given deployment - * descriptor - * - * 4. Retrieve server side logs and verify the generated - * permissions matches the expected permission collection - * - */ - public void WebResourcePermissionExcludedPolicy() throws Exception { - boolean verified = false; - Permissions expectedExcludedPermissions = new Permissions(); - - // ---------EXCLUDED----------// - // 1) retrieve server generated excluded policy statements - // 2) construct expected excluded policy statements - // 3) verify expected policy statements with generated policy statements - - // Get "excluded" WebResourcePermissions - Permissions excludedWebResourcePermissions = logProcessor - .getSpecificPermissions(excludedPermissions, "WebResourcePermission"); - - TestUtil.logMsg("Server generated excluded WebResourcePermissions"); - logProcessor.printPermissionCollection(excludedWebResourcePermissions); - - // Construct the expected excluded WebResourcePermission - expectedExcludedPermissions - .add(new WebResourcePermission("/excluded.jsp", "GET,POST")); - - TestUtil.logMsg("verifying excluded policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedExcludedPermissions, - excludedWebResourcePermissions); - - if (!verified) { - throw new Exception("WebResourcePermissionExcludedPolicy failed: " - + "excluded policy statements verification failed"); - } else { - TestUtil.logMsg("excluded policy statements verification successful"); - } - } - - /** - * @testName: WebResourcePermissionUnCheckedPolicy - * - * @assertion_ids: JACC:SPEC:36; JACC:SPEC:39; JACC:SPEC:27; JACC:SPEC:28; - * JACC:SPEC:52; JACC:JAVADOC:17 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy the application. - * - * 3. During deployment, appserver generates permissions for - * the J2EE components based on the given deployment - * descriptor - * - * 4. Retrieve server side logs and verify the generated - * unchecked permissions matches the expected permission - * collection - */ - public void WebResourcePermissionUnCheckedPolicy() throws Exception { - Permissions expectedPermissions = new Permissions(); - boolean verified = false; - - // Get "unchecked" WebResourcePermissions - Permissions uncheckedWebResourcePermissions = logProcessor - .getSpecificPermissions(unCheckedPermissions, "WebResourcePermission"); - - TestUtil.logMsg("Server generated unchecked WebResourcePermissions"); - logProcessor.printPermissionCollection(uncheckedWebResourcePermissions); - - // Construct the expected unchecked WebResourcePermission - expectedPermissions - .add(new WebResourcePermission("/unchecked.jsp", (String) null)); - expectedPermissions - .add(new WebResourcePermission("/sslprotected.jsp", "!GET,POST")); - expectedPermissions.add(new WebResourcePermission( - "/:/secured.jsp:/unchecked.jsp:/excluded.jsp:/sslprotected.jsp:/anyauthuser.jsp", - (String) null)); - expectedPermissions - .add(new WebResourcePermission("/excluded.jsp", "!GET,POST")); - expectedPermissions - .add(new WebResourcePermission("/secured.jsp", "!GET,POST")); - expectedPermissions - .add(new WebResourcePermission("/anyauthuser.jsp", "!GET,POST")); - - verified = logProcessor.verifyLogImplies(expectedPermissions, - uncheckedWebResourcePermissions); - - if (!verified) { - throw new Exception("WebResourcePermissionUnCheckedPolicy failed"); - } else { - TestUtil.logMsg("WebResourcePermission constructed" - + " correctly with unchecked policy statements"); - } - } - - /** - * @testName: WebUserDataPermission - * - * @assertion_ids: JACC:SPEC:41; JACC:SPEC:42; JACC:JAVADOC:54; - * JACC:JAVADOC:56; JACC:JAVADOC:58; JACC:SPEC:27; - * JACC:SPEC:28; JACC:SPEC:34; JACC:SPEC:52 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Deploy the application. - * - * 3. During deployment, appserver generates permissions for - * the J2EE components based on the given deployment - * descriptor - * - * 4. Retrieve server side logs and verify the generated - * unchecked permissions matches the expected permission - * collection - * - * - */ - public void WebUserDataPermission() throws Exception { - boolean verified = false; - Permissions expectedUnCheckedPermissions = new Permissions(); - Permissions expectedExcludedPermissions = new Permissions(); - - // ----------UNCHECKED----------// - // 1) retrieve server generated unchecked policy statements - // 2) construct expected unchecked policy statements - // 3) verify expected policy statements with generated policy statements - - // Get "unchecked" WebUserDataPermissions - Permissions uncheckedWebUserDataPermissions = logProcessor - .getSpecificPermissions(unCheckedPermissions, "WebUserDataPermission"); - - TestUtil.logMsg("Server generated unchecked WebUserDataPermissions"); - logProcessor.printPermissionCollection(uncheckedWebUserDataPermissions); - - // Construct the expected unchecked WebUserDataPermission - expectedUnCheckedPermissions.add(new WebUserDataPermission( - "/sslprotected.jsp", "GET,POST:CONFIDENTIAL")); - expectedUnCheckedPermissions - .add(new WebUserDataPermission("/excluded.jsp", "!GET,POST")); - expectedUnCheckedPermissions - .add(new WebUserDataPermission("/sslprotected.jsp", "!GET,POST")); - expectedUnCheckedPermissions - .add(new WebUserDataPermission("/secured.jsp", (String) null)); - expectedUnCheckedPermissions - .add(new WebUserDataPermission("/anyauthuser.jsp", "!GET,POST")); - expectedUnCheckedPermissions.add(new WebUserDataPermission( - "/:/unchecked.jsp:/secured.jsp:/sslprotected.jsp:/excluded.jsp:/anyauthuser.jsp", - (String) null)); - expectedUnCheckedPermissions - .add(new WebUserDataPermission("/unchecked.jsp", (String) null)); - - TestUtil.logMsg("verifying unchecked policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedUnCheckedPermissions, - uncheckedWebUserDataPermissions); - - if (!verified) { - throw new Exception("WebUserDataPermission failed: " - + "unchecked policy statements verification failed"); - } else { - TestUtil.logMsg("unchecked policy statements verification successful"); - } - - // ---------EXCLUDED----------// - // 1) retrieve server generated excluded policy statements - // 2) construct expected excluded policy statements - // 3) verify expected policy statements with generated policy statements - - // Get "excluded" WebUserDataPermission - Permissions excludedWebUserDataPermissions = logProcessor - .getSpecificPermissions(excludedPermissions, "WebUserDataPermission"); - - TestUtil.logMsg("Server generated excluded WebUserDataPermission"); - logProcessor.printPermissionCollection(excludedWebUserDataPermissions); - - // Construct the expected excluded WebUserDataPermission - expectedExcludedPermissions - .add(new WebUserDataPermission("/excluded.jsp", "GET,POST")); - - TestUtil.logMsg("verifying excluded policy statments:"); - - verified = logProcessor.verifyLogImplies(expectedExcludedPermissions, - excludedWebUserDataPermissions); - - if (!verified) { - throw new Exception("WebUserDataPermission failed: " - + "excluded policy statements verification failed"); - } else { - TestUtil.logMsg("excluded policy statements verification successful"); - } - } - - /** - * @testName: WebResourcePermissionEquals - * - * @assertion_ids: JACC:JAVADOC:40 - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of WebResourcePermission.equals() - * - * - */ - public void WebResourcePermissionEquals() throws Exception { - boolean verified = false; - - String tempArgs[] = { "WebResourcePermission.equals() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("WebResourcePermissionEquals : FAILED"); - } else { - TestUtil.logMsg("WebResourcePermissionEquals : PASSED"); - } - } - - /** - * @testName: WebRoleRefPermissionEquals - * - * @assertion_ids: JACC:JAVADOC:47 - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of WebRoleRefPermission.equals() - * - * - */ - public void WebRoleRefPermissionEquals() throws Exception { - boolean verified = false; - - String tempArgs[] = { "WebRoleRefPermission.equals() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("WebRoleRefPermissionEquals : FAILED"); - } else { - TestUtil.logMsg("WebRoleRefPermissionEquals : PASSED"); - } - } - - /** - * @testName: WebUserDataPermissionEquals - * - * @assertion_ids: JACC:JAVADOC:53 - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of WebUserDataPermission.equals() - * - * - */ - public void WebUserDataPermissionEquals() throws Exception { - boolean verified = false; - - String tempArgs[] = { "WebUserDataPermission.equals() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("WebUserDataPermissionEquals : FAILED"); - } else { - TestUtil.logMsg("WebUserDataPermissionEquals : PASSED"); - } - } - - /** - * @testName: WebResourcePermissionHashCode - * - * @assertion_ids: JACC:JAVADOC:42 - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of WebResourcePermission.hashCode() - * - * - */ - public void WebResourcePermissionHashCode() throws Exception { - boolean verified = false; - - String tempArgs[] = { "WebResourcePermission.hashCode() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("WebResourcePermissionHashCode : FAILED"); - } else { - TestUtil.logMsg("WebResourcePermissionHashCode : PASSED"); - } - } - - /** - * @testName: WebRoleRefPermissionHashCode - * - * @assertion_ids: JACC:JAVADOC:49 - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of WebRoleRefPermission.hashCode() - * - * - */ - public void WebRoleRefPermissionHashCode() throws Exception { - boolean verified = false; - - String tempArgs[] = { "WebRoleRefPermission.hashCode() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("WebRoleRefPermissionHashCode : FAILED"); - } else { - TestUtil.logMsg("WebRoleRefPermissionHashCode : PASSED"); - } - } - - /** - * @testName: WebUserDataPermissionHashCode - * - * @assertion_ids: JACC:JAVADOC:55 - * - * @test_Strategy: 1. When we deploy the applications defined in - * toolsContracts, the equals() and hashcode() method will be - * called on all JACC Permission classes. ( i.e - * EJBMethodPermission, EJBRoleRefPermission, - * WebResourcePermission, WebRoleRefPermission, - * WebUserDataPermission) - * - * 2. Use FetchLog servlet to read the server side log and - * verify the result of WebUserDataPermission.hashCode() - * - * - */ - public void WebUserDataPermissionHashCode() throws Exception { - boolean verified = false; - - String tempArgs[] = { "WebUserDataPermission.hashCode() : PASSED" }; - - // verify the log contains the required string. - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("WebUserDataPermissionHashCode : FAILED"); - } else { - TestUtil.logMsg("WebUserDataPermissionHashCode : PASSED"); - } - } - - /** - * @testName: PolicyConfigurationFactory - * - * @assertion_ids: JACC:SPEC:25; JACC:SPEC:15; JACC:SPEC:63 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Use FetchLog servlet to read the server side log to - * verify PolicyConfigurationFactory is called and - * instantiated in the server. - * - * Description The getPolicyConfigurationFactory method must - * be used in the containers to which the application or - * module are being deployed to find or instantiate - * PolicyConfigurationFactory objects. - * - */ - public void PolicyConfigurationFactory() throws Exception { - boolean verified = false; - String args[] = { "PolicyConfigurationFactory instantiated" }; - - // verify whether the log contains required messages. - verified = logProcessor.verifyLogContains(args); - - if (!verified) { - throw new Exception("PolicyConfigurationFactory failed : " - + "PolicyconfigurationFactory not instantiated"); - } else { - TestUtil.logMsg("PolicyConfigurationFactory() instantiated"); - } - } - - /** - * @testName: GetPolicyConfiguration - * - * @assertion_ids: JACC:SPEC:26; JACC:JAVADOC:28; JACC:JAVADOC:29 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Use FetchLog servlet to read the server side log to - * verify PolicyConfigurationFactory is called and - * instantiated in the server. - * - * Description The getPolicyconfiguration method of the - * factory must be used to find or instantiate - * PolicyConfiguration objects corresponding to the - * application or modules being deployed. - * - */ - public void GetPolicyConfiguration() throws Exception { - boolean verified = false; - String args[] = { - "PolicyConfigurationFactory.getPolicyConfiguration() invoked" }; - - // verify whether the log contains required messages. - verified = logProcessor.verifyLogContains(args); - if (!verified) { - throw new Exception("GetPolicyConfiguration failed : " - + "getPolicyconfiguration() was not invoked"); - } else { - TestUtil.logMsg( - "PolicyConfigurationFactory.getPolicyConfiguration() invoked"); - } - } - - /** - * @testName: validateNoInvalidStates - * - * @assertion_ids: JACC:SPEC:60; - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Use FetchLog servlet to read the server side log to - * verify PolicyConfigurationFactory is called and - * instantiated in the server. - * - * Description This method looks for occurances of error - * message within JACCLog.txt where those error messags would - * only appear in JACCLog.txt if there was a - * policyConfiguration lifecycle state that was in the wrong - * state at the wrong time. This can ONLY test the state for - * being in the 'inService' state or not. So testing is done - * to make sure the PolicyConfigration state is correct wrt - * policyConfiguration.inService() for each of the methods - * defined in the PolicyConfiguration javadoc table. Again, - * this is not a complete validation of all states, but is - * only able to validate if the state is inService or not at - * each of the method calls based on the javadoc table. - * Occurance of an ERROR message below would be a flag for a - * method being in an incorrect state. - */ - public void validateNoInvalidStates() throws Exception { - boolean verified = false; - String args1[] = { - "ERROR - our policy config should not be in the INSERVICE state." }; - String args2[] = { - "ERROR - our policy config should be in the INSERVICE state." }; - - // verify that the log contains no errors related to the inService state - verified = logProcessor.verifyLogContains(args1); - if (verified) { - // if here, then there was an error message where we were errorneously - // caught in the inService state when we should not have been - throw new Exception( - "validateNoInvalidStates failed : detected error message of: " - + args1[0]); - } else { - TestUtil.logMsg("validateNoInvalidStates() passed."); - } - - verified = logProcessor.verifyLogContains(args2); - if (verified) { - // if here, then there was an error message where we were NOT - // in the inService state but we should have been - throw new Exception( - "validateNoInvalidStates failed : detected error message of: " - + args2[0]); - } else { - TestUtil.logMsg("validateNoInvalidStates() passed."); - } - - } - - /** - * @testName: PolicyRefresh - * - * @assertion_ids: JACC:SPEC:54; JACC:SPEC:5; JACC:SPEC:23 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Use FetchLog servlet to read the server side log and - * verify that TSPolicy.refresh() method is called - * - * (Note: This assertion implicitly tests JACC:SPEC:5, - * JACC:SPEC:23 i.e loading provider specified interfaces by - * the containers) - * - */ - public void PolicyRefresh() throws Exception { - boolean verified = false; - String tempArgs[] = { "TSPolicy.refresh() invoked" }; - - // verify the log contains TSPolicy.refresh(). - verified = logProcessor.verifyLogContains(tempArgs); - - if (!verified) { - throw new Exception("PolicyRefresh() failed"); - } else { - TestUtil.logMsg("TSPolicy.refresh() invoked"); - } - } - - /** - * @testName: Policy - * - * @assertion_ids: JACC:SPEC:53; JACC:SPEC:56; JACC:SPEC:67; JACC:SPEC:68; - * JACC:SPEC:105; JACC:SPEC:14; JACC:SPEC:22 - * - * @test_Strategy: 1. Register TS provider with the AppServer. (See User guide - * for Registering TS Provider with your AppServer ). - * - * 2. Use FetchLog servlet, and verify the server side log - * contains the following string "TSPolicy.refresh() invoked" - * - * 3. The occurance of the above string indicates the server - * used the system property - * jakarta.security.jacc.policy.provider to instantiate and - * replace the policy object used by the JRE - */ - public void Policy() throws Exception { - - boolean verified = false; - - String args[] = { "TSPolicy.refresh() invoked" }; - - // verify whether the log contains required string. - verified = logProcessor.verifyLogContains(args); - - if (!verified) { - throw new Exception("TestName: Policy failed : " - + "Policy replacement algorithm not used"); - } else { - TestUtil.logMsg("System Policy loaded based on system properties"); - } - - } -} diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/build.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/build.xml deleted file mode 100644 index 83e2d46e4f..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/build.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - - - - - - - - - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/jacc_web_toolsContracts_web.war.sun-web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/jacc_web_toolsContracts_web.war.sun-web.xml deleted file mode 100644 index 2e8161d5c7..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/jacc_web_toolsContracts_web.war.sun-web.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - jacc_web_toolsContracts_web - - Administrator - j2ee - - - Manager - javajoe - - - Employee - javajoe - j2ee - - diff --git a/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/jacc_web_toolsContracts_web.xml b/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/jacc_web_toolsContracts_web.xml deleted file mode 100644 index 1707a5480e..0000000000 --- a/jacc/src/main/java/com/sun/ts/tests/jacc/web/toolsContracts/jacc_web_toolsContracts_web.xml +++ /dev/null @@ -1,165 +0,0 @@ - - - - - jacc_web_toolsContracts - - excluded - excluded - /excluded.jsp - 0 - - - unchecked - unchecked - /unchecked.jsp - 0 - - - sslprotected - sslprotected - /sslprotected.jsp - 0 - - ADM - Administrator - - - MGR - Manager - - - - secured - secured - /secured.jsp - 0 - - ADM - Administrator - - - - anyauthuser - anyauthuser - /anyauthuser.jsp - 0 - - - excluded - /excluded.jsp - - - unchecked - /unchecked.jsp - - - sslprotected - /sslprotected.jsp - - - secured - /secured.jsp - - - anyauthuser - /anyauthuser.jsp - - - 54 - - - - MySecureBit5 - /excluded.jsp - POST - GET - - - - NONE - - - - - MySecureBit6 - /sslprotected.jsp - POST - GET - - - Administrator - - - CONFIDENTIAL - - - - - MySecureBit3 - /secured.jsp - POST - GET - - - Administrator - - - NONE - - - - - MySecureBit4 - /unchecked.jsp - POST - GET - - - NONE - - - - - MySecureBit5 - /anyauthuser.jsp - GET - POST - - - ** - - - NONE - - - - BASIC - default - - - Administrator - - - Manager - - - Employee - - diff --git a/pom.xml b/pom.xml index 2291cc512b..36c3bb8200 100644 --- a/pom.xml +++ b/pom.xml @@ -47,9 +47,6 @@ ejb32 el integration - - - jacc javaee javamail jaxrs @@ -227,18 +224,6 @@ ${project.version} - - ${project.groupId} - jacc - ${project.version} - - - - ${project.groupId} - jaspic - ${project.version} - - ${project.groupId} javaee @@ -353,12 +338,6 @@ ${project.version} - - ${project.groupId} - securityapi - ${project.version} - - ${project.groupId} servlet diff --git a/release/tools/build.xml b/release/tools/build.xml index 0de7b9a5d7..265c6a0f9a 100644 --- a/release/tools/build.xml +++ b/release/tools/build.xml @@ -85,10 +85,8 @@ - - @@ -443,18 +441,6 @@ - - - - - - - - - - - - @@ -581,18 +567,6 @@ - - - - - - - - - - - - diff --git a/release/tools/jakartaee.xml b/release/tools/jakartaee.xml index 417dfff6b7..15b1064a21 100644 --- a/release/tools/jakartaee.xml +++ b/release/tools/jakartaee.xml @@ -42,8 +42,6 @@ com/sun/ts/lib/deliverable/mgmt/**, com/sun/ts/lib/deliverable/jdbc/**, com/sun/ts/lib/deliverable/jaxws/**, - com/sun/ts/tests/jaspic/spi/soap/**, - com/sun/ts/tests/jaspic/spi/authstatus/**, com/sun/ts/tests/jaxws/build.xml, com/sun/ts/tests/jaxws/api/**, com/sun/ts/tests/jaxws/ee/**, diff --git a/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/JaspicSigTest.java b/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/JaspicSigTest.java deleted file mode 100755 index 729f8e4fd8..0000000000 --- a/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/JaspicSigTest.java +++ /dev/null @@ -1,218 +0,0 @@ -/* - * Copyright (c) 2007, 2020 Oracle and/or its affiliates. All rights reserved. - * - * This program and the accompanying materials are made available under the - * terms of the Eclipse Public License v. 2.0, which is available at - * http://www.eclipse.org/legal/epl-2.0. - * - * This Source Code may also be made available under the following Secondary - * Licenses when the conditions for such availability set forth in the - * Eclipse Public License v. 2.0 are satisfied: GNU General Public License, - * version 2 with the GNU Classpath Exception, which is available at - * https://www.gnu.org/software/classpath/license.html. - * - * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 - */ - -/* - * $Id: JaspicSigTest.java 51070 2006-08-13 14:01:40Z lschwenk $ - */ - -/* - * @(#)SigTestTSUtils.java 1.11 02/05/14 - */ - -package com.sun.ts.tests.signaturetest.jaspic; - -import java.util.LinkedList; -import java.util.List; - -import com.sun.javatest.Status; -import com.sun.ts.tests.signaturetest.SigTestEE; - -/** - * The JaspicSigTest class provides signature tests for the Java EE TCK. This - * class extends SigTestEE which contains the signature test code. This class is - * responsible for providing implementations of the abstract method defined in - * SigTestEE, namely the getPackages method. - */ -public class JaspicSigTest extends SigTestEE { - - public static final String EJB_VEHICLE = "ejb"; - - public static final String SERVLET_VEHICLE = "servlet"; - - public static final String JSP_VEHICLE = "jsp"; - - public static final String APP_CLIENT_VEHICLE = "appclient"; - - public static final String NO_VEHICLE = "standalone"; - - /* - * Defines the packages that are included when running signature tests for any - * container (the default packages). This includes the appclient, ejb, jsp, - * and servlet containers. - */ - private static final String[] DEFAULT_PKGS = { "jakarta.security.auth.message", - "jakarta.security.auth.message.callback", - "jakarta.security.auth.message.config", - "jakarta.security.auth.message.module", }; - - /* - * Defines additional packages that are included when running signature tests - * for the ejb, jsp and servlet containers. - */ - private static final String[] EJB_SERVLET_JSP_PKGS = {}; - - /* - * Defines additional packages that are included when running signature tests - * for the jsp and servlet containers. - */ - private static final String[] SERVLET_JSP_PKGS = {}; - - private static final String[] NO_CONTAINER_PKGS = { - "jakarta.security.auth.message", "jakarta.security.auth.message.callback", - "jakarta.security.auth.message.config", - "jakarta.security.auth.message.module", }; - - /** - * Adds the default packages and the command line flags to the specified list - * for each package defined in the list of default packages to check during - * signature tests. Note: The specified list is modified as a result of this - * method call. - * - * @param sigArgsList - * The arg list being constructed to pass to the utility that records - * and runs signature file tests. - */ - private void addDefaultPkgs(List sigArgsList) { - for (int i = 0; i < DEFAULT_PKGS.length; i++) { - sigArgsList.add(DEFAULT_PKGS[i]); - } - } - - /** - * Adds the ejb, servlet, and jsp packages and the command line flags to the - * specified list for each package defined in the list of ejb, servlet, and - * jsp packages to check during signature tests. Note: The specified list is - * modified as a result of this method call. - * - * @param sigArgsList - * The arg list being constructed to pass to the utility that records - * and runs signature file tests. - */ - private void addEjbServletJspPkgs(List sigArgsList) { - for (int i = 0; i < EJB_SERVLET_JSP_PKGS.length; i++) { - sigArgsList.add(EJB_SERVLET_JSP_PKGS[i]); - } - } - - /** - * Adds the servlet, and jsp packages and the command line flags to the - * specified list for each package defined in the list of servlet, and jsp - * packages to check during signature tests. Note: The specified list is - * modified as a result of this method call. - * - * @param sigArgsList - * The arg list being constructed to pass to the utility that records - * and runs signature file tests. - */ - private void addServletJspPkgs(List sigArgsList) { - for (int i = 0; i < SERVLET_JSP_PKGS.length; i++) { - sigArgsList.add(SERVLET_JSP_PKGS[i]); - } - } - - /** - * Adds the pkgs for tests to be run in NO Container (ie standalone) packages - * to check during signature tests. Note: The specified list is modified as a - * result of this method call. - * - * @param sigArgsList - * The arg list being constructed to pass to the utility that records - * and runs signature file tests. - */ - private void addNoContainerPkgs(List sigArgsList) { - for (int i = 0; i < NO_CONTAINER_PKGS.length; i++) { - sigArgsList.add(NO_CONTAINER_PKGS[i]); - } - } - - /** - * ** Abstract Method Implementations **** Returns a list of strings where - * each string represents a package name. Each package name will have it's - * signature tested by the signature test framework. - * - * @param vehicleName - * The name of the Jaspic container where the signature tests should - * be conducted. - * - * @return String[] The names of the packages whose signatures should be - * verified. - */ - - /** - * Returns a list of strings where each string represents a package name. Each - * package name will have it's signature tested by the signature test - * framework. - * - * @param vehicleName - * The name of the Jaspic container where the signature tests should - * be conducted. - * @return String[] The names of the packages whose signatures should be - * verified. - */ - protected String[] getPackages(String vehicleName) { - List packages = new LinkedList(); - - if (vehicleName.equals(NO_VEHICLE)) { - addNoContainerPkgs(packages); - } else { - addDefaultPkgs(packages); // add default vehicle packages - if (vehicleName.equals(EJB_VEHICLE) || vehicleName.equals(SERVLET_VEHICLE) - || vehicleName.equals(JSP_VEHICLE)) { - addEjbServletJspPkgs(packages); - } - if (vehicleName.equals(SERVLET_VEHICLE) - || vehicleName.equals(JSP_VEHICLE)) { - addServletJspPkgs(packages); - } - } - return packages.toArray(new String[packages.size()]); - } - - /** - * ** Boilerplate Code **** - */ - - /* - * Initial entry point for JavaTest. - */ - public static void main(String[] args) { - JaspicSigTest theTests = new JaspicSigTest(); - Status s = theTests.run(args, System.out, System.err); - s.exit(); - } - - /* - * @class.setup_props: sigTestClasspath, Location of Jaspic jar files; - * ts_home, The base path of this TCK; - */ - - /* - * @testName: signatureTest - * - * @assertion: A Jaspic platform must implement the required classes and and - * APIs specified in the Jaspic Platform Specification. - * - * @test_Strategy: Using reflection, gather the implementation specific - * classes and APIs. Compare these results with the expected (required) - * classes and APIs. - * - */ - - /* - * Call the parent class's cleanup method. - */ - -} // end class CTSSigTest diff --git a/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/build.xml b/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/build.xml deleted file mode 100755 index bd1a18ad6a..0000000000 --- a/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/build.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/manifest.mf b/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/manifest.mf deleted file mode 100755 index 5d0b5a77c0..0000000000 --- a/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/jaspic/manifest.mf +++ /dev/null @@ -1,2 +0,0 @@ -Manifest-Version: 1.0 -Class-Path: sigtest.jar diff --git a/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/websocket/WebSocketSigTest.java b/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/websocket/WebSocketSigTest.java index 1e2a1cb105..f383917712 100644 --- a/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/websocket/WebSocketSigTest.java +++ b/signaturetest/src/main/java/com/sun/ts/tests/signaturetest/websocket/WebSocketSigTest.java @@ -150,7 +150,7 @@ private static void addNoContainerPkgs(List sigArgsList) { * framework. * * @param vehicleName - * The name of the Jaspic container where the signature tests should + * The name of the container where the signature tests should * be conducted. * @return String[] The names of the packages whose signatures should be * verified. diff --git a/user_guides/build_tckugs.sh b/user_guides/build_tckugs.sh index 3dc2115254..3b84027d2e 100644 --- a/user_guides/build_tckugs.sh +++ b/user_guides/build_tckugs.sh @@ -27,7 +27,7 @@ export PATH=$JAVA_HOME/bin:$M2_HOME/bin:$PATH cd ${WORKSPACE} export BASEDIR=`pwd` export USERGUIDEDIR=$BASEDIR/user_guides -alltcks="caj el jacc jaspic jaxws jca jms jpa jsp jstl jta saaj servlet websocket" +alltcks="caj el jaxws jca jms jpa jsp jstl jta saaj servlet websocket" cd $USERGUIDEDIR rm -rf $USERGUIDEDIR/tmp diff --git a/user_guides/jacc/README.md b/user_guides/jacc/README.md deleted file mode 100644 index 05bacb8682..0000000000 --- a/user_guides/jacc/README.md +++ /dev/null @@ -1,77 +0,0 @@ -# A JBake project template - -## About JBake - -JBake is a static site generator, it's inspired from jekyll and written -in java. The basic idea is to have templates for the structure of the -page, and the body generated from asciidoc content. - -## Pre requisites - -- Maven -- JDK11+ - -Deploying to Github will require password less authentication. - -This is done by exporting your SSH public key into your Github account. - -## Build the site locally - -The site is generated under target/staging. - -Open file:///PATH_TO_PROJECT_DIR/target/staging in a browser to view the site. - -``` -mvn generate-resources -``` - -Or you can invoke the JBake plugin directly. - -``` -mvn jbake:build -``` - -### Rebuild the site on changes - -``` -mvn jbake:watch -``` - -If you keep this command running, changes to the sources will be -detected and the site will be rendered incrementally. - -This is convenient when writing content. - -### Serve the site locally - -``` -mvn jbake:serve -``` - -If a webserver is required (e.g. absolute path are used), this command -will start a webserver (jetty) at http://localhost:8820. It will also -watch for changes and rebuild incrementally. - -## Deploy the site to Github Pages - -``` -mvn deploy -``` - -## Produce a zip file for download - -To produce a zip file containing the generated html files, use: - -``` -mvn package -``` - -When making a release on GitHub, this zip file should be added to the release. - -## Links - -- [JBake maven plugin documentation](https://github.com/Blazebit/jbake-maven-plugin) -- [JBake documentation](http://jbake.org/docs/2.5.1) -- [Freemarker documentation](http://freemarker.org/docs) -- [AsciiDoc User Guide](http://asciidoc.org/userguide.html) -- [Asciidoctor quick reference](http://asciidoctor.org/docs/asciidoc-syntax-quick-reference) diff --git a/user_guides/jacc/pom.xml b/user_guides/jacc/pom.xml deleted file mode 100644 index 2915ec2510..0000000000 --- a/user_guides/jacc/pom.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - 4.0.0 - - - jakarta.tck - jakarta.tck.user-guide - 11.0.0-SNAPSHOT - ../parent/pom.xml - - - jakarta.authorization - jakarta.authorization-tck-user-guide - 3.0.0-SNAPSHOT - pom - Eclipse Foundation Technology Compatibility Kit User's Guide for Jakarta Authorization for Jakarta EE, Release 3.0 ${project.version} - - - - scm:git:git@github.com:eclipse-ee4j/jakartaee-tck.git - - - - - - Authorization - - DRAFT - ${project.parent.version} - - - - - - org.apache.maven.plugins - maven-assembly-plugin - - - build-dist - package - - - - - org.glassfish.doc - glassfish-doc-maven-plugin - - - generate-book - generate-sources - - - generate-toc - generate-sources - - - - - org.jbake - jbake-maven-plugin - - - build-site - generate-resources - - - - - org.asciidoctor - asciidoctor-maven-plugin - - - generate-pdf-doc - generate-resources - - - - - - diff --git a/user_guides/jacc/src/main/jbake/assets/README.md b/user_guides/jacc/src/main/jbake/assets/README.md deleted file mode 100644 index f8f962c0ab..0000000000 --- a/user_guides/jacc/src/main/jbake/assets/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# About - -The {{site.title}} project contains the [AsciiDoc](http://asciidoc.org/) -source code for the ... diff --git a/user_guides/jacc/src/main/jbake/assets/_config.yml b/user_guides/jacc/src/main/jbake/assets/_config.yml deleted file mode 100644 index 8c43f8aec1..0000000000 --- a/user_guides/jacc/src/main/jbake/assets/_config.yml +++ /dev/null @@ -1,14 +0,0 @@ -remote_theme: jakartaee/jekyll-theme-jakarta-ee - -title: [tck_jacc_v1_5] -description: [Oracle Technology Compatibility Kit User's Guide for Java Authorization Contract for Containers 2.1 for Technology Licensees, Release 2.1] - -# sidebar links url -links: - source: https://github.com/javaee/tck_jacc_v1_5 - download: https://github.com/javaee/tck_jacc_v1_5/releases - #mailinglist: https://javaee.groups.io/g/tck_jacc_v1_5 - #javadocs: - docs: https://javaee.github.io/tck_jacc_v1_5 - #faq: - diff --git a/user_guides/jacc/src/main/jbake/content/README b/user_guides/jacc/src/main/jbake/content/README deleted file mode 100644 index 05fa2c27fd..0000000000 --- a/user_guides/jacc/src/main/jbake/content/README +++ /dev/null @@ -1,77 +0,0 @@ -The file attributes.conf defines several attributes (variables) that -need to be customized for each technology. - -The *.adoc files should not be modified. - -The following "include" files should be customized as necessary -for the specific technology: - -- rules.inc - - Additional compatibility rules needed by some technologies. - The rules in rules.adoc should NOT be changed. - -- defns.inc - - Additional definitions needed by additional compatibility - rules in rules.inc. - -- config.inc - - Detailed instructions for configuring the TCK, included in - Chapter 4. Unfortunately, these are sections 4.1 - 4.3, - so even if the TCK doesn't require 3 sections you need to - make up something, or else change the sections to "N/A". - -- packages.inc - - A simple list of Jakarta EE package names for the technology. - -- tck-packages.inc - - A list of additional software packages included in the TCK. - -- req-software.inc - - A list of software required in addition to the TCK and CI. - -- install-server.inc - - Steps to install the Jakarta EE CI, if needed. - For standalone technologies, no server may be required, - and this file can be empty. - This is used in install.adoc in section 3.2. - -- install-server-vi.inc - - Steps to install a Vendor's web server, if needed. - For standalone technologies, no web server may be required, - and this file can be empty. - This is used in install.adoc in section 3.2. - -- using-examples.inc - - Command line examples showing how to run the TCK. - -- using.inc - - Optional additional instructions for running the TCK. - -- debug-tips.inc - - Technology-specific troubleshooting tips for Chapter 6. - If this isn't needed, it can be an empty file, but toc.adoc - will need to be fixed. - -- rebuild.inc - - Special instructions for rebuilding the WAR files used by some TCKs. - If needed, customize it appropriately and define the "rebuild" - attribute in attributes.conf. - -- title.inc - Add acronym references as required do distinguish between legacy and - current APIs. - -Note that this template is NOT sufficient for the Jakarta EE platform -or Jakarta EE Web Profile. diff --git a/user_guides/jacc/src/main/jbake/content/attributes.conf b/user_guides/jacc/src/main/jbake/content/attributes.conf deleted file mode 100644 index 40e35e9dd4..0000000000 --- a/user_guides/jacc/src/main/jbake/content/attributes.conf +++ /dev/null @@ -1,37 +0,0 @@ -:TechnologyFullName: Jakarta Authorization -:TechnologyShortName: Authorization -:LegacyAcronym: JACC -:TechnologyVersion: 2.1 -:ReleaseDate: May 2022 -:CopyrightDates: 2017, 2022 -:TechnologyRI: Eclipse GlassFish 7.0 -:TechnologyRIURL: https://projects.eclipse.org/projects/ee4j.glassfish -:SpecificationURL: https://jakarta.ee/specifications/authorization/2.1/ -:TCKInquiryList: mailto:jakartaee-tck-dev@eclipse.org[jakartaee-tck-dev@eclipse.org] -:SpecificationInquiryList: mailto:jacc-dev@eclipse.org[jacc-dev@eclipse.org] -:techID: Authorization -// Define this attribute (uncomment it) if the TCK includes no API tests. (Rare.) -// :no-api-tests: -// Define this attribute (uncomment it) if the TCK includes end-to-end tests. -// :end-to-end-tests: -// Define this attribute (uncomment it) if subsets of the API are allowed. -// (Common Annotations only) -// :subset-allowed: -// -// The environment variable used to specify the home directory -// for the technology. Used in config.inc. -:TechnologyHomeEnv: JACC_HOME -// Java SE version required. -:SEversion: 11 or 17 -:AntVersion: 1.10.0+ -:JakartaEEVersion: 10 -:JavaTestVersion: 5.0 -:jteFileName: /bin/ts.jte -:jtxFileName: /bin/ts.jtx -:TCKPackageName: jakarta-authorization-tck-2.1.0.zip -// Directory names used in examples in using.adoc. -:sigTestDirectoryExample: /src/com/sun/ts/tests/signaturetest/jacc -:singleTestDirectoryExample: /src/com/sun/ts/tests/jacc/ejb -:subsetTestDirectoryExample: /src/com/sun/ts/tests/jacc -// Define this attribute (uncomment it) if the TCK needs the rebuild appendix. -// :rebuild: diff --git a/user_guides/jacc/src/main/jbake/content/config.adoc b/user_guides/jacc/src/main/jbake/content/config.adoc deleted file mode 100644 index ff8b8639ff..0000000000 --- a/user_guides/jacc/src/main/jbake/content/config.adoc +++ /dev/null @@ -1,353 +0,0 @@ -type=page -status=published -title=Setup and Configuration -next=using.html -prev=install.html -~~~~~~ -include::attributes.conf[] -Setup and Configuration -======================= - -[[GBFVV]] - - - -[[setup-and-configuration]] -4 Setup and Configuration -------------------------- - - -[NOTE] -==== -The Jakarta EE Specification process provides for any number of compatible implementations. -As additional implementations become available, refer to project or product documentation from -those vendors for specific TCK setup and operational guidance. - -==== - -This chapter describes how to set up the {TechnologyShortName} TCK and -JavaTest harness software. Before proceeding with the instructions in -this chapter, be sure to install all required software, as described in -link:install.html#GBFTP[Chapter 3, "Installation."] - -After completing the instructions in this chapter, proceed to -link:using.html#GBFWO[Chapter 5, "Executing Tests,"] for instructions on -running the {TechnologyShortName} TCK. - -include::config.inc[] - -[[GHGDH]][[custom-configuration-handlers]] - -4.4 Custom Configuration Handlers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Configuration handlers are used to configure and unconfigure a -{TechnologyShortName} {TechnologyVersion} implementation during the -certification process. These are similar to deployment handlers but -used for configuration. A configuration handler is an Ant build file -that contains at least the required targets listed below: - - * `config.vi` - to configure the vendor implementation - * `clean.vi` - to unconfigure the vendor implementation - -These targets are called from the `/bin/build.xml` file and -call down into the implementation-specific configuration handlers. - -To provide your own configuration handler, create a config.vi.xml file -with the necessary configuration steps for your implementation and place -the file under the `/bin/xml/impl/` directory. - -For more information, you may wish to view `/bin/xml/impl/glassfish/config.vi.xml`, -the configuration file for Jakarta EE {JakartaEEVersion} Compatible Implementation, Eclipse GlassFish. - -[[GBFWG]][[custom-deployment-handlers]] - -4.5 Custom Deployment Handlers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Deployment handlers are used to deploy and undeploy the WAR files that -contain the tests to be run during the certification process. A deployment -handler is an Ant build file that contains at least the required targets -listed in the table below. - -The {TechnologyShortName} TCK provides these deployment handlers: - -* `/bin/xml/impl/none/deploy.xml` -* `/bin/xml/impl/glassfish/deploy.xml` -* `/bin/xml/impl/tomcat/deploy.xml` - -The `deploy.xml` files in each of these directories are used to control -deployment to a specific container (no deployment, deployment to -the Eclipse GlassFish Web container, deployment to the Tomcat Web container) -denoted by the name of the directory in which each `deploy.xml` file -resides. The primary `build.xml` file in the `/bin` directory -has a target to invoke any of the required targets (`-deploy`, `-undeploy`, -`-deploy.all`, `-undeploy.all`). - -[[GBFVA]][[create-custom-deployment-handler]] - -4.5.1 To Create a Custom Deployment Handler -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To deploy tests to another {TechnologyShortName} implementation, you -must create a custom handler. - -1. Create a new directory in the `/bin/xml/impl` directory tree. - For example, create the `/bin/xml/impl/my_deployment_handler` directory. - Replace my_deployment_handler with the value of the impl.vi - property that you set in Step 5 of the configuration procedure - described in Section 4.2, "Configuring Your Environment to Repackage - and Run the TCK Against the Vendor Implementation". - -2. Copy the deploy.xml file from the `/bin/xml/impl/none` - directory to the directory that you created. - -3. Modify the required targets in the `deploy.xml` file. This is what - the `deploy.xml` file for the "none" deployment handler looks like. - -+ -[source,oac_no_warn] ----- - - - - - - - - - - - - - - - ----- -+ -Although this example just echoes messages, it does include the four -required Ant targets (`-deploy`, `-undeploy`, `-deploy.all`, `-undeploy.all`) -that your custom `deploy.xml` file must contain. With this as your -starting point, look at the required targets in the `deploy.xml` files -in the Tomcat and Eclipse Glassfish directories for guidance as you create -the same targets for the Web container in which you will run your -implementation of {TechnologyShortName}. - -The following Ant targets can be called from anywhere under the -`/src` directory: - -* `deploy` -* `undeploy` -* `deploy.all` -* `undeploy.all` - -The `deploy.all` and `undeploy.all` targets can also be called from the -`/bin` directory. - -[NOTE] -======================================================================= -The targets in the `deploy.xml` file are never called directly. -They are called indirectly by the targets listed above. -======================================================================= - -[[GBFUY]][[using-the-javatest-harness-software]] - -4.6 Using the JavaTest Harness Software -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are two general ways to run the {TechnologyShortName} TCK test -suite using the JavaTest harness software: - -* Through the JavaTest GUI; if using this method, please continue on to -link:#GBFWG[Section 4.7, "Using the JavaTest Harness Configuration -GUI."] -* In JavaTest batch mode, from the command line in your shell -environment; if using this method, please proceed directly to -link:using.html#GBFWO[Chapter 5, "Executing Tests."] - -[[GBFWG]][[using-the-javatest-harness-configuration-gui]] - -4.7 Using the JavaTest Harness Configuration GUI -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can use the JavaTest harness GUI to modify general test settings and -to quickly get started with the default {TechnologyShortName} TCK test -environment. This section covers the following topics: - -* link:#GBFVA[Configuration GUI Overview] -* link:#GBFVD[Starting the Configuration GUI] -* link:#GBFVX[To Configure the JavaTest Harness to Run the -{TechnologyShortName} TCK Tests] -* link:#GBFUU[Modifying the Default Test Configuration] - - -[NOTE] -======================================================================= - -It is only necessary to proceed with this section if you want to run the -JavaTest harness in GUI mode. If you plan to run the JavaTest harness in -command-line mode, skip the remainder of this chapter, and continue with -link:using.html#GBFWO[Chapter 5, "Executing Tests."] - -======================================================================= - - -[[GBFVA]][[configuration-gui-overview]] - -4.7.1 Configuration GUI Overview -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In order for the JavaTest harness to execute the test suite, it requires -information about how your computing environment is configured. The -JavaTest harness requires two types of configuration information: - -* Test environment: This is data used by the tests. For example, the -path to the Java runtime, how to start the product being tested, network -resources, and other information required by the tests in order to run. -This information does not change frequently and usually stays constant -from test run to test run. -* Test parameters: This is information used by the JavaTest harness to -run the tests. Test parameters are values used by the JavaTest harness -that determine which tests in the test suite are run, how the tests -should be run, and where the test reports are stored. This information -often changes from test run to test run. - -The first time you run the JavaTest harness software, you are asked to -specify the test suite and work directory that you want to use. (These -parameters can be changed later from within the JavaTest harness GUI.) - -Once the JavaTest harness GUI is displayed, whenever you choose Start, -then Run Tests to begin a test run, the JavaTest harness determines -whether all of the required configuration information has been supplied: - -* If the test environment and parameters have been completely -configured, the test run starts immediately. -* If any required configuration information is missing, the -configuration editor displays a series of questions asking you the -necessary information. This is called the configuration interview. When -you have entered the configuration data, you are asked if you wish to -proceed with running the test. - -[[GBFVD]][[starting-the-configuration-gui]] - -4.7.2 Starting the Configuration GUI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Before you start the JavaTest harness software, you must have a valid -test suite and Java SE {SEversion} installed on your system. - -The {TechnologyShortName} TCK includes an Ant script that is used to execute the -JavaTest harness from the `` directory. Using this Ant script -to start the JavaTest harness is part of the procedure described in -link:#GBFVX[Section 4.7.3, "To Configure the JavaTest Harness to Run the -TCK Tests."] - -When you execute the JavaTest harness software for the first time, the -JavaTest harness displays a Welcome dialog box that guides you through -the initial startup configuration. - -* If it is able to open a test suite, the JavaTest harness displays a -Welcome to JavaTest dialog box that guides you through the process of -either opening an existing work directory or creating a new work -directory as described in the JavaTest online help. -* If the JavaTest harness is unable to open a test suite, it displays a -Welcome to JavaTest dialog box that guides you through the process of -opening both a test suite and a work directory as described in the -JavaTest documentation. - -After you specify a work directory, you can use the Test Manager to -configure and run tests as described in link:#GBFVX[Section 4.7.3, "To -Configure the JavaTest Harness to Run the TCK Tests."] - -[[GBFVX]][[to-configure-the-javatest-harness-to-run-the-tck-tests]] - -4.7.3 To Configure the JavaTest Harness to Run the TCK Tests -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The answers you give to some of the configuration interview questions -are specific to your site. For example, the name of the host on which -the JavaTest harness is running. Other configuration parameters can be -set however you wish. For example, where you want test report files to -be stored. - -Note that you only need to complete all these steps the first time you -start the JavaTest test harness. After you complete these steps, you can -either run all of the tests by completing the steps in -link:using.html#GBFUZ[Section 5.1, "Starting JavaTest,"] or run a subset -of the tests by completing the steps in link:using.html#GBFWM[Section -5.2, "Running a Subset of the Tests."] - -1. Change to the `/bin` directory and start the JavaTest test -harness: + -`cd /bin` + -`ant gui` -2. From the File menu, click *Open Quick Start Wizard*. + -The Welcome screen displays. -3. Select *Start a new test run*, and then click *Next*. + -You are prompted to create a new configuration or use a configuration -template. -4. Select *Create a new configuration*, and then click *Next*. + -You are prompted to select a test suite. -5. Accept the default suite (`/src`), and then click *Next*. + -You are prompted to specify a work directory to use to store your test -results. -6. Type a work directory name or use the *Browse* button to select a work -directory, and then click *Next*. + -You are prompted to start the configuration editor or start a test run. -At this point, the {TechnologyShortName} TCK is configured to run the -default test suite. -7. Deselect the *Start the configuration editor* option, and then click -*Finish*. -8. Click *Run Tests*, then click *Start*. + -The JavaTest harness starts running the tests. -9. To reconfigure the JavaTest test harness, do one of the following: -* Click *Configuration*, then click *New Configuration*. -* Click *Configuration*, then click *Change Configuration*. -10. Click *Report*, and then click *Create Report*. -11. Specify the directory in which the JavaTest test harness will write -the report, and then click *OK*. + -A report is created, and you are asked whether you want to view it. -12. Click *Yes* to view the report. - -[[GBFUU]][[modifying-the-default-test-configuration]] - -4.7.4 Modifying the Default Test Configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The JavaTest GUI enables you to configure numerous test options. These -options are divided into two general dialog box groups: - -* Group 1: Available from the JavaTest *Configure/Change Configuration* -submenus, the following options are displayed in a tabbed dialog box: - -** *Tests to Run* - -** *Exclude List* - -** *Keywords* - -** *Prior Status* - -** *Test Environment* - -** *Concurrency* - -** *Timeout Factor* -* Group 2: Available from the JavaTest *Configure/Change -Configuration/Other Values* submenu, or by pressing `Ctrl+E`, the following -options are displayed in a paged dialog box: - -** *Environment Files* - -** *Test Environment* - -** *Specify Tests to Run* - -** *Specify an Exclude List* - -Note that there is some overlap between the functions in these two -dialog boxes; for those functions use the dialog box that is most -convenient for you. Please refer to the JavaTest Harness documentation -or the online help for complete information about these various options. - - diff --git a/user_guides/jacc/src/main/jbake/content/config.inc b/user_guides/jacc/src/main/jbake/content/config.inc deleted file mode 100644 index 0d468c4b11..0000000000 --- a/user_guides/jacc/src/main/jbake/content/config.inc +++ /dev/null @@ -1,186 +0,0 @@ -/////////////////////////////////////////////////////////////////////// -NOTE TO WRITERS: -The following sections should be customized for the technology. -This text was originally from the JAX-RS TCK. Most references -to JAX-RS have been parameterized to serve as a simple starting -point for customization. There are still many details that will -need to be changed or removed. The major sections 4.1, 4.2, and -4.3 should be preserved. If their titles are changed, the links -at the top of config.adoc will need to be changed as well as well -as toc.adoc. -/////////////////////////////////////////////////////////////////////// - -[[GBFVU]][[configuring-your-environment-to-run-the-tck-against-the-reference-implementation]] - -4.1 Configuring Your Environment to Run the TCK Against the Reference Implementation -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -After configuring your environment as described in this section, -continue with the instructions in link:#GBFUY[Section 4.6, "Using the -JavaTest Harness Software."] - - -[NOTE] -======================================================================= - -In these instructions, variables in angle brackets need to be expanded -for each platform. For example, `` becomes `$TS_HOME` on -Solaris/Linux and `%TS_HOME%` on Windows. In addition, the forward -slashes (`/`) used in all of the examples need to be replaced with -backslashes (`\`) for Windows. Finally, be sure to use the appropriate -separator for your operating system when specifying multiple path -entries (`;` on Windows, `:` on UNIX/Linux). - -On Windows, you must escape any backslashes with an extra backslash in -path separators used in any of the following properties, or use forward -slashes as a path separator instead. - -======================================================================= - - -1. Set the following environment variables in your shell environment: - a. `JAVA_HOME` to the directory in which Java SE {SEversion} is installed - b. `TS_HOME` to the directory in which the {TechnologyShortName} TCK - {TechnologyVersion} software is installed - c. `PATH` to include the following directories: `JAVA_HOME/bin`, - +{TechnologyHomeEnv}/bin+, and `ANT_HOME/bin` -2. Copy /bin/ts.jte.jdk11 as /bin/ts.jte if JAVA_HOME is Java SE 11. -Edit your `/bin/ts.jte` file and set the following -environment variables: - a. Set the `jacc.home` property to the installation directory of Jakarta EE - {JakartaEEVersion} CI. - b. Set the `jacc.host` property to the host name of the system where your - {TechnologyShortName} runtime implementation is installed. - c. Set the `jacc.classes` property to point to the classes or JAR file - that contains the {TechnologyShortName} classes. - d. Set the `sigTestClasspath` property to point to the classes or JAR file - for the runtime implementation of the {TechnologyShortName} {TechnologyVersion} API and any additional required - signature classes. -3. Copy the `tsharness.jar` and `jacctck.jar` files to the server’s extension -directory, change to the `/bin` directory and execute the following -commands: -+ -[source,oac_no_warn] ----- -cd /bin -ant config.vi -ant enable.jacc ----- -+ - -[[GCLHU]][[configuring-your-environment-to-repackage-and-run-the-tck-against-the-vendor-implementation]] - -4.2 Configuring Your Environment to Repackage and Run the TCK Against the Vendor Implementation -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -After configuring your environment as described in this section, -continue with the instructions in link:#GBFUY[Section 4.4, "Using the -JavaTest Harness Software."] - - -[NOTE] -======================================================================= - -In these instructions, variables in angle brackets need to be expanded -for each platform. For example, `` becomes `$TS_HOME` on -Solaris/Linux and `%TS_HOME%` on Windows. In addition, the forward -slashes (`/`) used in all of the examples need to be replaced with -backslashes (`\`) for Windows. Finally, be sure to use the appropriate -separator for your operating system when specifying multiple path -entries (`;` on Windows, `:` on UNIX/Linux). - -On Windows, you must escape any backslashes with an extra backslash in -path separators used in any of the following properties, or use forward -slashes as a path separator instead. - -======================================================================= - -1. Set the following environment variables in your shell environment: - a. `JAVA_HOME` to the directory in which Java SE {SEversion} is installed - b. `TS_HOME` to the directory in which the {TechnologyShortName} TCK - {TechnologyVersion} software is installed - c. `PATH` to include the following directories: `JAVA_HOME/bin`, - +{TechnologyHomeEnv}/bin+, and `ANT_HOME/bin` -2. Copy /bin/ts.jte.jdk11 as /bin/ts.jte if JAVA_HOME is Java SE 11. -Edit your `/bin/ts.jte` file and set the following -environment variables: - a. Set the `jacc.home` property to the installation directory of Jakarta EE - {JakartaEEVersion} CI. - b. Set the `jacc.host` property to the host name of the system where your - {TechnologyShortName} runtime implementation is installed. - c. Set the `jacc.classes` property to point to the classes or JAR file - that contains the {TechnologyShortName} classes. - d. Set the `sigTestClasspath` property to point to the classes or JAR file - for the runtime implementation of the Jakarta Authorization API and any additional required - signature classes. -3. Change to the `/bin` directory and execute the following -commands: -+ -[source,oac_no_warn] ----- -cd /bin -ant config.vi ----- -+ -The `config.vi` Ant task performs several actions, including: -+ -* Sets the following Jakarta Authorization JVM options: + -[source,oac_no_warn] ----- --Djakarta.security.jacc.policy.provider= - com.sun.ts.tests.jacc.provider.TSPolicy --Dvendor.jakarta.security.jacc.policy.provider= - com.sun.enterprise.security.jacc.provider.SimplePolicyProvider --Djakarta.security.jacc.PolicyConfigurationFactory.provider= - com.sun.ts.tests.jacc.provider.TSPolicyConfigurationFactoryImpl --Dvendor.jakarta.security.jacc.PolicyConfigurationFactory.provider= - com.sun.enterprise.security.jacc.provider.SimplePolicyConfigurationFactory --Dlog.file.location=${log.file.location} ----- -Note that the `log.file.location` comes from the property of the same -name in the `ts.jte` file. -+ -* Deploys the {TechnologyShortName} Provider (from `/lib/tsprovider.jar`) to -your server's library directory (for example using {TechnologyRI}, -`glassfish6/glassfish/lib`) where it can be picked up and loaded by the -server -* Enables the Security manager with the `-Djava.security.manager` JVM -option -* Creates users required by the TCK tests on the server under test -* Deploys `tsharness.jar` and `jacctck.jar` files to your {TechnologyShortName} server's -`/lib` directory + -4. Enable the TCK {TechnologyShortName} provider: + -[source,oac_no_warn] ----- -ant enable.jacc ----- -After running the {TechnologyShortName} TCK tests, disable the {TechnologyShortName} provider by running -the disable.jacc Ant task: + -[source,oac_no_warn] ----- -ant disable.jacc ----- -5. Change to the appropriate {TechnologyShortName} TCK test subdirectory -(`/src/com/sun/ts/tests/jacc/web` or -/src/com/sun/ts/tests/jacc/ejb) for the tests that you plan to -run and execute the `ant deploy` command to deploy the desired tests. + -To deploy the {TechnologyShortName} EJB tests: + -[source,oac_no_warn] ----- -cd ${TS_HOME}/src/com/sun/ts/tests/jacc/ejb -ant deploy ----- -Or, to deploy the {TechnologyShortName} Web tests: + -[source,oac_no_warn] ----- -cd ${TS_HOME}/src/com/sun/ts/tests/jacc/web -ant deploy ----- -Repeat this deployment step for each {TechnologyShortName} test directory after you run -the tests in the current directory, as described in -link:using.html#GBFWO[Chapter 5, "Executing Tests."] + -{TechnologyShortName} tests translate security configurations into corresponding {TechnologyShortName} -permissions. If multiple test directories are deployed simultaneously, -the result can be permissions that are stricter than what is expected, -which can lead to test failures. To avoid this potential problem, deploy -and run individual test directories separately, not simultaneously. diff --git a/user_guides/jacc/src/main/jbake/content/debug-tips.inc b/user_guides/jacc/src/main/jbake/content/debug-tips.inc deleted file mode 100644 index 267974261c..0000000000 --- a/user_guides/jacc/src/main/jbake/content/debug-tips.inc +++ /dev/null @@ -1,64 +0,0 @@ -/////////////////////////////////////////////////////////////////////// -NOTE TO WRITERS: -The following sections should be customized for the technology. -This text was originally from the JACC TCK. Some references -to JACC have been parameterized to serve as a simple starting -point for customization. There are still many details that will -need to be changed or removed. -/////////////////////////////////////////////////////////////////////// - -[[GBFHA]][[troubleshooting-tips]] - -6.7 Troubleshooting Tips -~~~~~~~~~~~~~~~~~~~~~~~~ - -This section provides some tips for troubleshooting errors that may be -encountered. - -* Verify that the Ant `config.vi` and `enable.jacc` configuration -targets executed correctly. -* If there are several failures during a test run, check the various -output for hints about what caused the failures. A common problem is the -absence of the {TechnologyShortName} log file. This log file should be created in the -directory defined by the `log.file.location` property in the `ts.jte` -file. There should be a log file called `JACCLog.txt` in this directory. -The `JACCLog.txt` consists of record entries containing permission -infomation that will be used to verify the TCK tests for proper -compliance. This log file typically gets populated with -{TechnologyShortName}-based security information when test archives are -deployed. Then, during test execution, the `JACCLog.txt` file is read -and used for validating that {TechnologyShortName} behavior is -correct. -* Simultaneously deploying all {TechnologyShortName} TCK test archives -may cause false failures. If unexpected failures occur during a TCK run -when all {TechnologyShortName} archives were deployed, these failures -could be caused by interference from tests and archives that are -defined multiple times. If such situational failures do occur, undeploy -all archives, remove the `JACCLog.txt` file, recycle your server (if -necessary), and rerun only the tests in the directory that showed -failures. -* Check that the following JVM variables, which should have been set by -invoking the `enable.jacc` Ant target, have been set in the application -server : - -** `-Dlog.file.location` (this comes from the +{jteFileName}+ property) - -** `-Djakarta.security.jacc.policy.provider=com.sun.ts.tests.jacc.provider.TSPolicy` - -** `-Djakarta.security.jacc.PolicyConfigurationFactory.provider=com.sun.ts.tests.jacc.provider.TSPolicyConfigurationFactoryImpl` - -** `-Dvendor.jakarta.security.jacc.policy.provider=com.sun.enterprise.security.jacc.provider.SimplePolicyProvider` - -** `-Dvendor.jakarta.security.jacc.PolicyConfigurationFactory.provider=com.sun.enterprise.security.jacc.provider.SimplePolicyConfigurationFactory` + - -[NOTE] -======================================================================= - -The values for the `-Dvendor.jakarta.security.jacc.policy.provider` and -`-Dvendor.jakarta.security.jacc.PolicyConfigurationFactory.provider` JVM -variables will need to be set specific to the application server in use. - -======================================================================= - - - diff --git a/user_guides/jacc/src/main/jbake/content/debug.adoc b/user_guides/jacc/src/main/jbake/content/debug.adoc deleted file mode 100644 index 5208c401a6..0000000000 --- a/user_guides/jacc/src/main/jbake/content/debug.adoc +++ /dev/null @@ -1,174 +0,0 @@ -type=page -status=published -title=Debugging Test Problems -next=faq.html -prev=using.html -~~~~~~ -include::attributes.conf[] -Debugging Test Problems -======================= - -[[GBFUV]] - - -[[debugging-test-problems]] -6 Debugging Test Problems -------------------------- - -There are a number of reasons that tests can fail to execute properly. -This chapter provides some approaches for dealing with these failures. -Please note that most of these suggestions are only relevant when -running the test harness in GUI mode. - -This chapter includes the following topics: - -* link:#GBFYP[Overview] -* link:#GBFVF[Test Tree] -* link:#GBFWI[Folder Information] -* link:#GBFVP[Test Information] -* link:#GBFVZ[Report Files] -* link:#GBFYF[Configuration Failures] - -[[GBFYP]][[overview]] - -6.1 Overview -~~~~~~~~~~~~ - -The goal of a test run is for all tests in the test suite that are not -filtered out to have passing results. If the root test suite folder -contains tests with errors or failing results, you must troubleshoot and -correct the cause to satisfactorily complete the test run. - -* Errors: Tests with errors could not be executed by the JavaTest -harness. These errors usually occur because the test environment is not -properly configured. -* Failures: Tests that fail were executed but had failing results. - -The Test Manager GUI provides you with a number of tools for effectively -troubleshooting a test run. See the JavaTest User's Guide and JavaTest -online help for detailed descriptions of the tools described in this -chapter. Ant test execution tasks provide command-line users with -immediate test execution feedback to the display. Available JTR report -files and log files can also help command-line users troubleshoot test -run problems. - -For every test run, the JavaTest harness creates a set of report files -in the reports directory, which you specified by setting the -`report.dir` property in the +{jteFileName}+ file. The report files contain -information about the test description, environment, messages, -properties used by the test, status of the test, and test result. After -a test run is completed, the JavaTest harness writes HTML reports for -the test run. You can view these files in the JavaTest ReportBrowser -when running in GUI mode, or in the Web browser of your choice outside -the JavaTest interface. To see all of the HTML report files, enter the -URL of the `report.html` file. This file is the root file that links to -all of the other HTML reports. - -The JavaTest harness also creates a `summary.txt` file in the report -directory that you can open in any text editor. The `summary.txt` file -contains a list of all tests that were run, their test results, and -their status messages. - -The work directory, which you specified by setting the `work.dir` -property in the +{jteFileName}+ file, contains several files that were -deposited there during test execution: `harness.trace`, `log.txt`, -`lastRun.txt`, and `testsuite`. Most of these files provide information -about the harness and environment in which the tests were executed. - -[NOTE] -======================================================================= - -You can set `harness.log.traceflag=true` in +{jteFileName}+ to -get more debugging information. - -======================================================================= - -If a large number of tests failed, you should read -link:#GBFYF[Configuration Failures] to see if a -configuration issue is the cause of the failures. - - -[[GBFVF]][[test-tree]] - -6.2 Test Tree -~~~~~~~~~~~~~ - -Use the test tree in the JavaTest GUI to identify specific folders and -tests that had errors or failing results. Color codes are used to -indicate status as follows: - -* Green: Passed -* Blue: Test Error -* Red: Failed to pass test -* White: Test not run -* Gray: Test filtered out (not run) - -[[GBFWI]][[folder-information]] - -6.3 Folder Information -~~~~~~~~~~~~~~~~~~~~~~ - -Click a folder in the test tree in the JavaTest GUI to display its tabs. - -Choose the Error and the Failed tabs to view the lists of all tests in -and under a folder that were not successfully run. You can double-click -a test in the lists to view its test information. - -[[GBFVP]][[test-information]] - -6.4 Test Information -~~~~~~~~~~~~~~~~~~~~ - -To display information about a test in the JavaTest GUI, click its icon -in the test tree or double-click its name in a folder status tab. The -tab contains detailed information about the test run and, at the bottom -of the window, a brief status message identifying the type of failure or -error. This message may be sufficient for you to identify the cause of -the error or failure. - -If you need more information to identify the cause of the error or -failure, use the following tabs listed in order of importance: - -* Test Run Messages contains a Message list and a Message section that -display the messages produced during the test run. -* Test Run Details contains a two-column table of name/value pairs -recorded when the test was run. -* Configuration contains a two-column table of the test environment -name/value pairs derived from the configuration data actually used to -run the test. - - -[NOTE] -======================================================================= - -You can set `harness.log.traceflag=true` in +{jteFileName}+ to -get more debugging information. - -======================================================================= - - -[[GBFVZ]][[report-files]] - -6.5 Report Files -~~~~~~~~~~~~~~~~ - -Report files are another good source of troubleshooting information. You -may view the individual test results of a batch run in the JavaTest -Summary window, but there are also a wide range of HTML report files -that you can view in the JavaTest ReportBrowser or in the external -browser or your choice following a test run. See -link:using.html#GBFVK[Section 5.5, "Test Reports,"] for more information. - -[[GBFYF]][[configuration-failures]] - -6.6 Configuration Failures -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Configuration failures are easily recognized because many tests fail the -same way. When all your tests begin to fail, you may want to stop the -run immediately and start viewing individual test output. However, in -the case of full-scale launching problems where no tests are actually -processed, report files are usually not created (though sometimes a -small `harness.trace` file in the report directory is written). - -include::debug-tips.inc[] diff --git a/user_guides/jacc/src/main/jbake/content/defns.inc b/user_guides/jacc/src/main/jbake/content/defns.inc deleted file mode 100644 index 038db2dda3..0000000000 --- a/user_guides/jacc/src/main/jbake/content/defns.inc +++ /dev/null @@ -1,46 +0,0 @@ -// NOTE TO WRITERS: -// Most technologies will only need the compatibility rules in rules.adoc. -// Some technologies will need additional definitions to go with additional -// rules. If they're needed, remove the comment characters below -// and update the definitions as appropriate. -// -// The first block below is additional definitions needed by -// Jakarta XML Web Services. -// -// The second block below is additional defintions needed by -// Jakarta Server Pages. -// -// NOTE: This set of examples is NOT complete, but should be. -// -// -// Jakarta XML Web Services -// -// |Development Kit |A software product that implements or incorporates a -// Compiler, a Schema Compiler, a Schema Generator, a Java-to-WSDL Tool, a -// WSDL-to-Java Tool, and/or an RMI Compiler. -// -// |Java-to-WSDL Output |Output of a Java-to-WSDL Tool that is required for -// Web service deployment and invocation. -// -// |Java-to-WSDL Tool |A software development tool that implements or -// incorporates a function that generates web service endpoint descriptions -// in WSDL and XML schema format from Source Code as specified by the -// Jakarta XML Web Services Specification. -// -// |WSDL-to-Java Output |Output of a WSDL-to-Java tool that is required for -// Web service deployment and invocation. -// -// |WSDL-to-Java Tool |A software development tool that implements or -// incorporates a function that generates web service interfaces for -// clients and endpoints from a WSDL description as specified by the -// Jakarta XML Web Services Specification. -// -// -// Jakarta Server Pages -// -// |Jakarta Server Page |A text-based document that uses Jakarta Server -// Pages technology. -// -// |Jakarta Server Page Implementation Class |A program constructed by -// transforming the Jakarta Server Page text into a Java language program -// using the transformation rules described in the Specifications. diff --git a/user_guides/jacc/src/main/jbake/content/faq.adoc b/user_guides/jacc/src/main/jbake/content/faq.adoc deleted file mode 100644 index 97ca394c55..0000000000 --- a/user_guides/jacc/src/main/jbake/content/faq.adoc +++ /dev/null @@ -1,62 +0,0 @@ -type=page -status=published -title=Appendix A: Frequently Asked Questions -next=rebuild.html -prev=debug.html -~~~~~~ -include::attributes.conf[] -Appendix A: Frequently Asked Questions -====================================== - -[[GBFYD]] - - -[[a-frequently-asked-questions]] -A Frequently Asked Questions ----------------------------- - -This appendix contains the following questions. - -* link:#GBFYQ[Where do I start to debug a test failure?] -* link:#GBFYR[How do I restart a crashed test run?] -* link:#GBFWU[What would cause tests be added to the exclude list?] - -[[GBFYQ]][[a.1-where-do-i-start-to-debug-a-test-failure]] - -A.1 Where do I start to debug a test failure? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -From the JavaTest GUI, you can view recently run tests using the Test -Results Summary, by selecting the red Failed tab or the blue Error tab. -See link:debug.html#GBFUV[Chapter 6, "Debugging Test Problems,"] for more -information. - -[[GBFYR]][[a.2-how-do-i-restart-a-crashed-test-run]] - -A.2 How do I restart a crashed test run? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you need to restart a test run, you can figure out which test crashed -the test suite by looking at the `harness.trace` file. The -`harness.trace` file is in the report directory that you supplied to the -JavaTest GUI or parameter file. Examine this trace file, then change the -JavaTest GUI initial files to that location or to a directory location -below that file, and restart. This will overwrite only `.jtr` files that -you rerun. As long as you do not change the value of the GUI work -directory, you can continue testing and then later compile a complete -report to include results from all such partial runs. - -[[GBFWU]][[a.3-what-would-cause-tests-be-added-to-the-exclude-list]] - -A.3 What would cause tests be added to the exclude list? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The JavaTest exclude file (+{jtxFileName}+) contains all tests that are not -required to be run. The following is a list of reasons for a test to be -included in the Exclude List: - -* An error in a Compatible Implementation that does not allow the test to -execute properly has been discovered. -* An error in the specification that was used as the basis of the test -has been discovered. -* An error in the test has been discovered. diff --git a/user_guides/jacc/src/main/jbake/content/install-server-vi.inc b/user_guides/jacc/src/main/jbake/content/install-server-vi.inc deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/user_guides/jacc/src/main/jbake/content/install-server.inc b/user_guides/jacc/src/main/jbake/content/install-server.inc deleted file mode 100644 index bf568116e8..0000000000 --- a/user_guides/jacc/src/main/jbake/content/install-server.inc +++ /dev/null @@ -1,3 +0,0 @@ -. Install Jakarta EE {JakartaEEVersion} CI software if it is not already installed. + -One CI is {TechnologyRI}. -You may obtain a copy of this CI by downloading it from {TechnologyRIURL}. diff --git a/user_guides/jacc/src/main/jbake/content/install.adoc b/user_guides/jacc/src/main/jbake/content/install.adoc deleted file mode 100644 index a3b93e73ac..0000000000 --- a/user_guides/jacc/src/main/jbake/content/install.adoc +++ /dev/null @@ -1,86 +0,0 @@ -type=page -status=published -title=Installation -next=config.html -prev=rules.html -~~~~~~ -include::attributes.conf[] -Installation -============ - -[[GBFTP]] - - -[[installation]] -3 Installation --------------- - -This chapter explains how to install the {TechnologyFullName} TCK software. - -After installing the software according to the instructions in this -chapter, proceed to link:config.html#GBFVV[Chapter 4, "Setup and -Configuration,"] for instructions on configuring your test environment. - -[[GBFUD]][[obtaining-the-reference-implementation]] - -3.1 Obtaining a Compatible Implementation -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Each compatible implementation (CI) will provide instructions for obtaining -their implementation. -{TechnologyRI} is a compatible implementation which may be obtained -from {TechnologyRIURL} - -[[GBFTS]][[installing-the-software]] - -3.2 Installing the Software -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Before you can run the {TechnologyShortName} TCK tests, you must -install and set up the following software components: - -include::req-software.inc[] -* Java SE {SEversion} -* Apache Ant {AntVersion} -* A CI for {TechnologyShortName} {TechnologyVersion}, one example is {TechnologyRI} -* {TechnologyShortName} TCK version {TechnologyVersion}, which includes: -include::tck-packages.inc[] -* The {TechnologyShortName} {TechnologyVersion} Vendor Implementation (VI) - -Follow these steps: - -. Install the Java SE {SEversion} software, if it is not already installed. + -Download and install the Java SE {SEversion} software from -http://www.oracle.com/technetwork/java/javase/downloads/index.html. -Refer to the installation instructions that accompany the software for -additional information. -. Install the Apache Ant {AntVersion} software, if it is not already installed. + -Download and install Apache Ant {AntVersion} software from Apache Ant -Project. For complete information about Ant, refer to the extensive documentation -on the Apache Ant Project site. The Apache Ant Manual is available at -`http://ant.apache.org/manual/index.html`. -Apache Ant is protected under the Apache Software, License 2.0, which is -is available on the Apache Ant Project license page at -`http://ant.apache.org/license.html`. -. Install the {TechnologyShortName} TCK {TechnologyVersion} software. - a. Copy or download the {TechnologyShortName} TCK software to your - local system. + - You can obtain the {TechnologyShortName} TCK software from the - Jakarta EE site {SpecificationURL}. - b. Use the `unzip` command to extract the bundle in the directory of - your choice: + - +unzip {TCKPackageName}+ + - This creates the TCK directory. The TCK is the test suite home, - ``. -include::install-server.inc[] -. Install a {TechnologyShortName} {TechnologyVersion} Compatible -Implementation. + -A Compatible Implementation is used to validate your initial -configuration and setup of the {TechnologyShortName} TCK -{TechnologyVersion} tests, which are explained further in -link:config.html#GBFVV[Chapter 4, "Setup and Configuration."] + -The Compatible Implementations for {TechnologyShortName} are listed on -the Jakarta EE Specifications web site: {SpecificationURL}. -include::install-server-vi.inc[] -. Install the {TechnologyShortName} VI to be tested. + -Follow the installation instructions for the particular VI under test. diff --git a/user_guides/jacc/src/main/jbake/content/intro.adoc b/user_guides/jacc/src/main/jbake/content/intro.adoc deleted file mode 100644 index 774adfd371..0000000000 --- a/user_guides/jacc/src/main/jbake/content/intro.adoc +++ /dev/null @@ -1,349 +0,0 @@ -type=page -status=published -title=Introduction -next=rules.html -prev=preface.html -~~~~~~ -include::attributes.conf[] -Introduction -============ - -[[GBFOW]] - - -[[introduction]] -1 Introduction --------------- - -This chapter provides an overview of the principles that apply -generally to all Technology Compatibility Kits (TCKs) and describes the -{TechnologyFullName} TCK ({TechnologyShortName} {TechnologyVersion} TCK). -It also includes a high level listing -of what is needed to get up and running with the {TechnologyShortName} -TCK. - -This chapter includes the following topics: - -* link:#GBFTK[Compatibility Testing] -* link:#GBFQR[About the TCK] -* link:#GBFQW[Getting Started With the TCK] - -[[GBFTK]][[compatibility-testing]] - -1.1 Compatibility Testing -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Compatibility testing differs from traditional product testing in a -number of ways. The focus of compatibility testing is to test those -features and areas of an implementation that are likely to differ across -other implementations, such as those features that: - -* Rely on hardware or operating system-specific behavior -* Are difficult to port -* Mask or abstract hardware or operating system behavior - -Compatibility test development for a given feature relies on a complete -specification and compatible implementation (CI) for that feature. -Compatibility testing is not primarily concerned with robustness, -performance, nor ease of use. - -[[GBFQN]][[why-compatibility-testing-is-important]] - -1.1.1 Why Compatibility Testing is Important -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Jakarta platform compatibility is important to different groups involved -with Jakarta technologies for different reasons: - -* Compatibility testing ensures that the Jakarta platform does not become -fragmented as it is ported to different operating systems and hardware -environments. -* Compatibility testing benefits developers working in the Jakarta -programming language, allowing them to write applications once and then -to deploy them across heterogeneous computing environments without -porting. -* Compatibility testing allows application users to obtain applications -from disparate sources and deploy them with confidence. -* Conformance testing benefits Jakarta platform implementors by ensuring a -level playing field for all Jakarta platform ports. - -[[GBFPR]][[tck-compatibility-rules]] - -1.1.2 TCK Compatibility Rules -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Compatibility criteria for all technology implementations are embodied -in the TCK Compatibility Rules that apply to a specified technology. -Each TCK tests for adherence to these Rules as described in -link:rules.html#GBFSN[Chapter 2, "Procedure for Certification."] - -[[GBFPW]][[tck-overview]] - -1.1.3 TCK Overview -^^^^^^^^^^^^^^^^^^ - -A TCK is a set of tools and tests used to verify that a vendor's compatible -implementation of a Jakarta EE technology conforms to the applicable -specification. All tests in the TCK are based on the written -specifications for the Jakarta EE platform. A TCK tests compatibility of a -vendor's compatible implementation of the technology to the applicable -specification of the technology. Compatibility testing is a means of -ensuring correctness, completeness, and consistency across all -implementations developed by technology licensees. - -The set of tests included with each TCK is called the test suite. Most -tests in a TCK's test suite are self-checking, but some tests may -require tester interaction. Most tests return either a Pass or Fail -status. For a given platform to be certified, all of the required tests -must pass. The definition of required tests may change from platform to -platform. - -The definition of required tests will change over time. Before your -final certification test pass, be sure to download the latest version -of this TCK. - -[[GBFPB]][[java-community-process-jcp-program-and-compatibility-testing]] - -1.1.4 Jakarta EE Specification Process (JESP) Program and Compatibility Testing -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Jakarta EE Specification Process (JESP) program is the formalization of the -open process that has been used since 2019 to develop and revise Jakarta EE -technology specifications in cooperation with the international Jakarta EE -community. The JESP program specifies that the following three major -components must be included as deliverables in a final Jakarta EE technology -release under the direction of the responsible Expert Group: - -* Technology Specification -* Compatible Implementation (CI) -* Technology Compatibility Kit (TCK) - -For further information about the JESP program, go to Jakarta EE Specification -Process community page https://jakarta.ee/specifications. - -[[GBFQR]][[about-the-tck]] - -1.2 About the TCK -~~~~~~~~~~~~~~~~~ - -The {TechnologyShortName} TCK {TechnologyVersion} is designed as a -portable, configurable, automated test suite for verifying the -compatibility of a vendor's implementation of the -{TechnologyShortName} {TechnologyVersion} Specification. - -[[GBFQV]][[tck-specifications-and-requirements]] - -1.2.1 TCK Specifications and Requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This section lists the applicable requirements and specifications. - -* Specification Requirements: Software requirements for a -{TechnologyShortName} implementation are described in detail in the -{TechnologyShortName} {TechnologyVersion} Specification. Links to the -{TechnologyShortName} specification and other product information can -be found at {SpecificationURL}. -* {TechnologyShortName} Version: The {TechnologyShortName} {TechnologyVersion} TCK -is based on the {TechnologyShortName} -Specification, Version {TechnologyVersion}. -* Compatible Implementation: One {TechnologyShortName} -{TechnologyVersion} Compatible Implementation, {TechnologyRI} is -available from the Eclipse EE4J project -(https://projects.eclipse.org/projects/ee4j). See the CI documentation page at -{TechnologyRIURL} for more information. - -See the {TechnologyShortName} TCK Release Notes for more specific -information about Java SE version requirements, supported platforms, -restrictions, and so on. - -[[GBFSQ]][[tck-components]] - -1.2.2 TCK Components -^^^^^^^^^^^^^^^^^^^^ - -The {TechnologyShortName} TCK {TechnologyVersion} includes the -following components: - -* JavaTest harness version {JavaTestVersion} and related documentation. See -link:https://wiki.openjdk.java.net/display/CodeTools/JT+Harness[JT Harness web site] -for additional information. -* {TechnologyShortName} TCK signature tests; check that all public APIs -are supported and/or defined as specified in the {TechnologyShortName} -Version {TechnologyVersion} implementation under test. -* If applicable, an exclude list, which provides a list of tests that your -implementation is not required to pass. -ifndef::no-api-tests[] -* API tests for all of the {TechnologyShortName} API in all related packages: -include::packages.inc[] -endif::no-api-tests[] -ifdef::end-to-end-tests[] -* End-to-end tests that demonstrate compliance with the {TechnologyFullName} -Specification. -endif::end-to-end-tests[] - -The {TechnologyShortName} TCK tests run on the following platforms: - -include::platforms.inc[] - -[[GBFSA]][[javatest-harness]] - -1.2.3 JavaTest Harness -^^^^^^^^^^^^^^^^^^^^^^ - -The JavaTest harness version {JavaTestVersion} is a set of tools -designed to run and manage test suites on different Java platforms. -To JavaTest, Jakarta EE can be considered another platform. -The JavaTest harness can be described as both a Java application and a set -of compatibility testing tools. It can run tests on different kinds of -Java platforms and it allows the results to be browsed online within -the JavaTest GUI, or offline in the HTML reports that the JavaTest -harness generates. - -The JavaTest harness includes the applications and tools that are used -for test execution and test suite management. It supports the following -features: - -* Sequencing of tests, allowing them to be loaded and executed automatically -* Graphic user interface (GUI) for ease of use -* Automated reporting capability to minimize manual errors -* Failure analysis -* Test result auditing and auditable test specification framework -* Distributed testing environment support - -To run tests using the JavaTest harness, you specify which tests in the -test suite to run, how to run them, and where to put the results as -described in link:config.html#GBFVV[Chapter 4, "Setup and -Configuration."] - -[[GBFRA]][[tck-compatibility-test-suite]] - -1.2.4 TCK Compatibility Test Suite -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The test suite is the collection of tests used by the JavaTest harness -to test a particular technology implementation. In this case, it is the -collection of tests used by the {TechnologyShortName} TCK -{TechnologyVersion} to test a {TechnologyShortName} {TechnologyVersion} -implementation. The tests are designed to verify that a vendor's -runtime implementation of the technology complies with the appropriate -specification. The individual tests correspond to assertions of the -specification. - -The tests that make up the TCK compatibility test suite are precompiled -and indexed within the TCK test directory structure. When a test run is -started, the JavaTest harness scans through the set of tests that are -located under the directories that have been selected. While scanning, -the JavaTest harness selects the appropriate tests according to any -matches with the filters you are using and queues them up for execution. - -[[GBFSH]][[exclude-lists]] - -1.2.5 Exclude Lists -^^^^^^^^^^^^^^^^^^^ - -Each version of a TCK includes an Exclude List contained in a `.jtx` -file. -This is a list of test file URLs that identify tests which do not -have to be run for the specific version of the TCK being used. -Whenever tests are run, the JavaTest harness automatically excludes -any test on the Exclude List from being executed. - -A vendor's compatible implementation is not required to pass or run any test on the Exclude List. -The Exclude List file, +{jtxFileName}+, is included in the -{TechnologyShortName} TCK. - - -[NOTE] -======================================================================= - -From time to time, updates to the Exclude List are made available. -The exclude list is included in the Jakarta TCK ZIP archive. -Each time an update is approved and released, the version number -will be incremented. -You should always make sure you are using an up-to-date copy of the -Exclude List before running the {TechnologyShortName} TCK to verify your -implementation. - -======================================================================= - - -A test might be in the Exclude List for reasons such as: - -* An error in an underlying implementation API has been discovered which -does not allow the test to execute properly. -* An error in the specification that was used as the basis of the test -has been discovered. -* An error in the test itself has been discovered. -* The test fails due to a bug in the tools (such as the JavaTest -harness, for example). - -In addition, all tests are run against the compatible implementations. -Any tests that fail when run on a compatible Jakarta platform are put on the -Exclude List. Any test that is not specification-based, or for which the -specification is vague, may be excluded. Any test that is found to be -implementation dependent (based on a particular thread scheduling model, -based on a particular file system behavior, and so on) may be excluded. - - -[NOTE] -======================================================================= - -Vendors are not permitted to alter or modify Exclude Lists. Changes to -an Exclude List can only be made by using the procedure described in -link:rules.html#CJAJEAEI[Section 2.3.1, "TCK Test Appeals Steps."] - -======================================================================= - - -[[GBFRR]][[tck-configuration]] - -1.2.6 TCK Configuration -^^^^^^^^^^^^^^^^^^^^^^^ - -You need to set several variables in your test environment, modify -properties in the +{jteFileName}+ file, and then use the JavaTest -harness to configure and run the {TechnologyShortName} tests, as described in -link:config.html#GBFVV[Chapter 4, "Setup and Configuration."] - -include::intro.inc[] - -[[GBFQW]][[getting-started-with-the-tck]] - -[NOTE] -==== -The Jakarta EE Specification Process support multiple compatible implementations. -These instructions explain how to get started with the {TechnologyRI} CI. -If you are using another compatible implementation, refer to material provided -by that implementation for specific instructions and procedures. - -==== - -1.3 Getting Started With the TCK -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This section provides an general overview of what needs to be done to -install, set up, test, and use the {TechnologyShortName} TCK. These -steps are explained in more detail in subsequent chapters of this -guide. - -1. Make sure that the following software has been correctly installed -on the system hosting the JavaTest harness: -include::req-software.inc[] -* Java SE {SEversion} -* Apache Ant {AntVersion} -* A CI for {TechnologyShortName} {TechnologyVersion}. One example is {TechnologyRI}. -* {TechnologyShortName} TCK version {TechnologyVersion}, which includes: -include::tck-packages.inc[] -* The {TechnologyShortName} {TechnologyVersion} Vendor Implementation (VI) + -See the documentation for each of these software applications for -installation instructions. See link:install.html#GBFTP[Chapter 3, -"Installation,"] for instructions on installing the {TechnologyShortName} TCK. -2. Set up the {TechnologyShortName} TCK software. + -See link:config.html#GBFVV[Chapter 4, "Setup and Configuration,"] for -details about the following steps. - a. Set up your shell environment. - b. Modify the required properties in the +{jteFileName}+ file. - c. Configure the JavaTest harness. -3. Test the {TechnologyShortName} {TechnologyVersion} implementation. + -Test the {TechnologyShortName} implementation installation by running -the test suite. See link:using.html#GBFWO[Chapter 5, "Executing Tests."] diff --git a/user_guides/jacc/src/main/jbake/content/intro.inc b/user_guides/jacc/src/main/jbake/content/intro.inc deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/user_guides/jacc/src/main/jbake/content/packages.inc b/user_guides/jacc/src/main/jbake/content/packages.inc deleted file mode 100644 index 2554a55412..0000000000 --- a/user_guides/jacc/src/main/jbake/content/packages.inc +++ /dev/null @@ -1,2 +0,0 @@ - -** `jakarta.security.jacc` diff --git a/user_guides/jacc/src/main/jbake/content/platforms.inc b/user_guides/jacc/src/main/jbake/content/platforms.inc deleted file mode 100644 index 337657c7ad..0000000000 --- a/user_guides/jacc/src/main/jbake/content/platforms.inc +++ /dev/null @@ -1,3 +0,0 @@ - -* CentOS Linux 7 -* Alpine Linux v3.12 \ No newline at end of file diff --git a/user_guides/jacc/src/main/jbake/content/preface.adoc b/user_guides/jacc/src/main/jbake/content/preface.adoc deleted file mode 100644 index ea10c28728..0000000000 --- a/user_guides/jacc/src/main/jbake/content/preface.adoc +++ /dev/null @@ -1,147 +0,0 @@ -type=page -status=published -title=Preface -next=intro.html -prev=title.html -~~~~~~ -include::attributes.conf[] -Preface -======= - -[[TCJRS00001]][[GBFTI]] - - -[[preface]] -Preface -------- - -This guide describes how to install, configure, and run the Technology -Compatibility Kit (TCK) that is used to test the {TechnologyFullName} -({TechnologyShortName} {TechnologyVersion}) technology. - -The {TechnologyShortName} TCK is a portable, configurable automated -test suite for verifying the compatibility of a vendor's -implementation of the {TechnologyShortName} {TechnologyVersion} -Specification (hereafter referred to as the vendor implementation or VI). -The {TechnologyShortName} TCK uses the JavaTest harness version -{JavaTestVersion} to run the test suite - - -[NOTE] -======================================================================= - -Note All references to specific Web URLs are given for the sake of your -convenience in locating the resources quickly. These references are -always subject to changes that are in many cases beyond the control of -the authors of this guide. - -======================================================================= - -Jakarta EE is a community sponsored and community run program. -Organizations contribute, along side individual contributors who use, evolve -and assist others. -Commercial support is not available through the Eclipse Foundation resources. -Please refer to the Eclipse EE4J project site -(https://projects.eclipse.org/projects/ee4j). -There, you will find additional details as well as a list of all the associated sub-projects -(Implementations and APIs), that make up Jakarta EE and define these specifications. -If you have questions about this Specification you may -send inquiries to {SpecificationInquiryList}. -If you have questions about this TCK, you may send inquiries to -{TCKInquiryList}. - -[[TCJRS00034]][[GBFUS]] - - -[[who-should-use-this-book]] -Who Should Use This Book -~~~~~~~~~~~~~~~~~~~~~~~~ - -This guide is for vendors that implement the {TechnologyShortName} -{TechnologyVersion} technology to assist them in running the test suite -that verifies compatibility of their implementation of the -{TechnologyShortName} {TechnologyVersion} Specification. - - -[[TCJRS00035]][[GBFPO]] - - -[[before-you-read-this-book]] -Before You Read This Book -~~~~~~~~~~~~~~~~~~~~~~~~~ - -You should be familiar with the {TechnologyShortName} -{TechnologyVersion}, version {TechnologyVersion} Specification, -which can be found at {SpecificationURL}. - -Before running the tests in the {TechnologyShortName} TCK, you should -familiarize yourself with the JavaTest documentation which can be -accessed at the -link:https://wiki.openjdk.java.net/display/CodeTools/JT+Harness[JT Harness web site]. - -[[TCJRS00036]][[GBFWF]] - - -[[typographic-conventions]] -Typographic Conventions -~~~~~~~~~~~~~~~~~~~~~~~ - -The following table describes the typographic conventions that are used -in this book. - -[width="100%",cols="15%,40%,45%",options="header",] -|======================================================================= -|Convention |Meaning |Example -|*Boldface* |Boldface type indicates graphical user interface elements -associated with an action, terms defined in text, or what you type, -contrasted with onscreen computer output. a| -From the *File* menu, select *Open Project*. - -A *cache* is a copy that is stored locally. - -`machine_name% *su*` + -`Password:` - -|`Monospace` |Monospace type indicates the names of files and -directories, commands within a paragraph, URLs, code in examples, text -that appears on the screen, or text that you enter. a| -Edit your `.login` file. - -Use `ls` `-a` to list all files. - -`machine_name% you have mail.` - -|_Italic_ |Italic type indicates book titles, emphasis, or placeholder -variables for which you supply particular values. a| -Read Chapter 6 in the _User's Guide_. - -Do _not_ save the file. - -The command to remove a file is `rm` _filename_. - -|======================================================================= - - -[[TCJRS00037]][[FWBSD]] - - -[[shell-prompts-in-command-examples]] -Shell Prompts in Command Examples -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The following table shows the default UNIX system prompt and superuser -prompt for the C shell, Bourne shell, and Korn shell. - -[width="100%",cols="50%,50%",options="header",] -|===================================================== -|Shell |Prompt -|C shell |`machine_name%` -|C shell for superuser |`machine_name#` -|Bourne shell and Korn shell |`$` + -|Bourne shell and Korn shell for superuser |`#` + -|Bash shell |`shell_name-shell_version$` -|Bash shell for superuser |`shell_name-shell_version#` -|===================================================== - - - diff --git a/user_guides/jacc/src/main/jbake/content/rebuild.adoc b/user_guides/jacc/src/main/jbake/content/rebuild.adoc deleted file mode 100644 index e4021cfa19..0000000000 --- a/user_guides/jacc/src/main/jbake/content/rebuild.adoc +++ /dev/null @@ -1,20 +0,0 @@ -type=page -status=published -title=Appendix B: Rebuild Rules -prev=faq.html -~~~~~~ -include::attributes.conf[] - -Appendix B: Rebuild Rules -========================= - - -ifdef::rebuild[] -include::rebuild.inc[] -endif::rebuild[] -ifndef::rebuild[] - -<<< -Appendix B is not used for the {TechnologyShortName} TCK. - -endif::rebuild[] diff --git a/user_guides/jacc/src/main/jbake/content/rebuild.inc b/user_guides/jacc/src/main/jbake/content/rebuild.inc deleted file mode 100644 index 91ff703746..0000000000 --- a/user_guides/jacc/src/main/jbake/content/rebuild.inc +++ /dev/null @@ -1,7 +0,0 @@ -/////////////////////////////////////////////////////////////////////// -NOTE TO WRITERS: -The following sections should be customized for the technology. -See a JAXRS user guide for an example of this include file. -/////////////////////////////////////////////////////////////////////// - -[[GCLIZ]] diff --git a/user_guides/jacc/src/main/jbake/content/req-software.inc b/user_guides/jacc/src/main/jbake/content/req-software.inc deleted file mode 100644 index bb9f6b3a46..0000000000 --- a/user_guides/jacc/src/main/jbake/content/req-software.inc +++ /dev/null @@ -1,11 +0,0 @@ -/////////////////////////////////////////////////////////////////////// -NOTE TO WRITERS: -This is a list of software required in addition to the TCK and the RI. -For many Java EE APIs, the Java EE RI will be required, as described below. -For standalone technologies, no other software may be required, and the -below line can be removed. - -This is used in intro.adoc in section 1.3 and install.adoc in section 3.2. -/////////////////////////////////////////////////////////////////////// - -* A CI of Jakarta EE {JakartaEEVersion} platform. {TechnologyRI}, is one CI for {TechnologyShortName} diff --git a/user_guides/jacc/src/main/jbake/content/rules.adoc b/user_guides/jacc/src/main/jbake/content/rules.adoc deleted file mode 100644 index f6b08cebb9..0000000000 --- a/user_guides/jacc/src/main/jbake/content/rules.adoc +++ /dev/null @@ -1,403 +0,0 @@ -type=page -status=published -title=Procedure for Certification -next=install.html -prev=intro.html -~~~~~~ -include::attributes.conf[] -Procedure for Certification -=========================== - -[[GBFSN]] - - -[[procedure-for-certification]] -2 Procedure for Certification ------------------------------ - -This chapter describes the compatibility testing procedure and -compatibility requirements for {TechnologyFullName}. -This chapter contains the following sections: - -* link:#CJAFFDGI[Certification Overview] -* link:#CJAFGIGG[Compatibility Requirements] -* link:#CJAIIBDJ[Test Appeals Process] -* link:#CJAJECIE[Specifications for {TechnologyFullName}] -* link:#CJABAHGI[Libraries for {TechnologyFullName}] - -[[CJAFFDGI]][[certification-overview]] - -2.1 Certification Overview -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The certification process for {technologyShortName} {TechnologyVersion} -consists of the following activities: - -* Install the appropriate version of the Technology Compatibility Kit -(TCK) and execute it in accordance with the instructions in this User's -Guide. -* Ensure that you meet the requirements outlined in -link:#CJAFGIGG[Compatibility Requirements] below. -* Certify to the Eclipse Foundation that you have finished -testing and that you meet all of the compatibility requirements, -as required by the Eclipse Foundation TCK License. - -[[CJAFGIGG]][[compatibility-requirements]] - -2.2 Compatibility Requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The compatibility requirements for {TechnologyShortName} -{TechnologyVersion} consist of meeting the requirements set forth by -the rules and associated definitions contained in this section. - -[[sthref4]][[definitions]] - -2.2.1 Definitions -^^^^^^^^^^^^^^^^^ - -These definitions are for use only with these compatibility requirements -and are not intended for any other purpose. - -[[sthref5]][[sthref6]] - -Table 2-1 Definitions  - -[width="100%",cols="25%,75%",options="header",] -|======================================================================= -|Term |Definition -|API Definition Product |A Product for which the only Java class files -contained in the product are those corresponding to the application -programming interfaces defined by the Specifications, and which is -intended only as a means for formally specifying the application -programming interfaces defined by the Specifications. - -|Computational Resource a| -A piece of hardware or software that may vary in quantity, existence, or -version, which may be required to exist in a minimum quantity and/or at -a specific or minimum revision level so as to satisfy the requirements -of the Test Suite. - -Examples of computational resources that may vary in quantity are RAM -and file descriptors. - -Examples of computational resources that may vary in existence (that is, -may or may not exist) are graphics cards and device drivers. - -Examples of computational resources that may vary in version are -operating systems and device drivers. - -|Configuration Descriptor |Any file whose format is well defined by a -specification and which contains configuration information for a set of -Java classes, archive, or other feature defined in the specification. - -|Conformance Tests |All tests in the Test Suite for an indicated -Technology Under Test, as released and distributed by the -Eclipse Foundation, excluding those tests on the -published Exclude List for the Technology Under Test. - -|Container |An implementation of the associated Libraries, as specified -in the Specifications, and a version of a Java Platform, Standard -Edition Runtime Product, as specified in the Specifications, or a later -version of a Java Platform, Standard Edition Runtime Product that also -meets these compatibility requirements. - -|Documented |Made technically accessible and made known to users, -typically by means such as marketing materials, product documentation, -usage messages, or developer support programs. - -|Exclude List |The most current list of tests, released and distributed by the -Eclipse Foundation, that are not required to be passed to certify -conformance. The Jakarta EE Specification Committee may add to the Exclude List for that -Test Suite as needed at any time, in which case the updated TCK version -supplants any previous Exclude Lists for that Test Suite. - -|Libraries a| -The class libraries, as specified through the Jakarta EE Specification Process -(JESP), for the Technology Under Test. - -The Libraries for {TechnologyFullName} are listed at the end of this chapter. - -|Location Resource a| -A location of classes or native libraries that are components of the -test tools or tests, such that these classes or libraries may be -required to exist in a certain location in order to satisfy the -requirements of the test suite. - -For example, classes may be required to exist in directories named in a -CLASSPATH variable, or native libraries may be required to exist in -directories named in a PATH variable. - -|Maintenance Lead |The corresponding Jakarta EE Specification Project -is responsible for maintaining the Specification, and the TCK for the -Technology. The Specification Project Team will propose revisions and -updates to the Jakarta EE Specification Committee which will approve -and release new versions of the specification and TCK. - -|Operating Mode a| -Any Documented option of a Product that can be changed by a user in -order to modify the behavior of the Product. - -For example, an Operating Mode can be binary (enable/disable -optimization), an enumeration (select from a list of protocols), or a -range (set the maximum number of active threads). - -Note that an Operating Mode may be selected by a command line switch, an -environment variable, a GUI user interface element, a configuration or -control file, etc. - -|Product |A vendor's product in which the Technology Under Test is -implemented or incorporated, and that is subject to compatibility -testing. - -|Product Configuration a| -A specific setting or instantiation of an Operating Mode. - -For example, a Product supporting an Operating Mode that permits user -selection of an external encryption package may have a Product -Configuration that links the Product to that encryption package. - -|Rebuildable Tests |Tests that must be built using an -implementation-specific mechanism. This mechanism must produce -specification-defined artifacts. Rebuilding and running these tests -against a known compatible implementation verifies that the mechanism generates -compatible artifacts. - -|Resource |A Computational Resource, a Location Resource, or a Security -Resource. - -|Rules |These definitions and rules in this Compatibility Requirements -section of this User's Guide. - -|Runtime |The Containers specified in the Specifications. - -|Security Resource a| -A security privilege or policy necessary for the proper execution of the -Test Suite. - -For example, the user executing the Test Suite will need the privilege -to access the files and network resources necessary for use of the -Product. - -|Specifications a| -The documents produced through the Jakarta EE Specification Process (JESP) -that define a particular Version of a Technology. - -The Specifications for the Technology Under Test are referenced later in -this chapter. - -|Technology |Specifications and one or more compatible implementations produced -through the Jakarta EE Specification Process (JESP). - -|Technology Under Test |Specifications and a compatible implementation -for {TechnologyFullName} Version {TechnologyVersion}. - -|Test Suite |The requirements, tests, and testing tools distributed by -the Maintenance Lead as applicable to a given Version of the Technology. - -|Version |A release of the Technology, as produced through the -Jakarta EE Specification Process (JESP). - -include::defns.inc[] -|======================================================================= - - -[[sthref7]][[rules-for-products]] - -2.2.2 Rules for {TechnologyFullName} Products -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following rules apply for each version of an operating system, -software component, and hardware platform Documented as supporting the -Product: - -*{techID}1* The Product must be able to satisfy all applicable compatibility -requirements, including passing all Conformance Tests, in every Product -Configuration and in every combination of Product Configurations, except -only as specifically exempted by these Rules. - -For example, if a Product provides distinct Operating Modes to optimize -performance, then that Product must satisfy all applicable compatibility -requirements for a Product in each Product Configuration, and -combination of Product Configurations, of those Operating Modes. - -*{techID}1.1* If an Operating Mode controls a Resource necessary for the -basic execution of the Test Suite, testing may always use a Product -Configuration of that Operating Mode providing that Resource, even if -other Product Configurations do not provide that Resource. -Notwithstanding such exceptions, each Product must have at least one set -of Product Configurations of such Operating Modes that is able to pass -all the Conformance Tests. - -For example, a Product with an Operating Mode that controls a security -policy (i.e., Security Resource) which has one or more Product -Configurations that cause Conformance Tests to fail may be tested using -a Product Configuration that allows all Conformance Tests to pass. - -*{techID}1.2* A Product Configuration of an Operating Mode that causes the -Product to report only version, usage, or diagnostic information is -exempted from these compatibility rules. - -*{techID}1.3* An API Definition Product is exempt from all functional -testing requirements defined here, except the signature tests. - -*{techID}2* Some Conformance Tests may have properties that may be changed. -Properties that can be changed are identified in the configuration -interview. Properties that can be changed are identified in the JavaTest -Environment (.jte) files in the Test Suite -installation. Apart from changing such properties and other allowed -modifications described in this User's Guide (if any), no source or -binary code for a Conformance Test may be altered in any way without -prior written permission. Any such allowed alterations to the -Conformance Tests will be provided via the Jakarta EE Specification Project -website and apply to all vendor compatible implementations. - -*{techID}3* The testing tools supplied as part of the Test Suite or as -updated by the Maintenance Lead must be used to certify compliance. - -*{techID}4* The Exclude List associated with the Test Suite cannot be -modified. - -*{techID}5* The Maintenance Lead can define exceptions to these Rules. Such -exceptions would be made available as above, and will apply to all vendor implementations. - -*{techID}6* All hardware and software component additions, deletions, and -modifications to a Documented supporting hardware/software platform, -that are not part of the Product but required for the Product to satisfy -the compatibility requirements, must be Documented and available to -users of the Product. - -For example, if a patch to a particular version of a supporting -operating system is required for the Product to pass the Conformance -Tests, that patch must be Documented and available to users of the -Product. - -*{techID}7* The Product must contain the full set of public and protected -classes and interfaces for all the Libraries. Those classes and -interfaces must contain exactly the set of public and protected methods, -constructors, and fields defined by the Specifications for those -Libraries. No subsetting, supersetting, or modifications of the public -and protected API of the Libraries are allowed except only as -specifically exempted by these Rules. - -*{techID}7.1* If a Product includes Technologies in addition to the -Technology Under Test, then it must contain the full set of combined -public and protected classes and interfaces. The API of the Product -must contain the union of the included Technologies. No further -modifications to the APIs of the included Technologies are allowed. - -ifdef::subset-allowed[] -*{techID}7.2* The Product may contain a subset of the classes and -interfaces for the Libraries. -endif::subset-allowed[] - -*{techID}8* Except for tests specifically required by this TCK to be rebuilt -(if any), the binary Conformance Tests supplied as part of the Test -Suite or as updated by the Maintenance Lead must be used to certify -compliance. - -*{techID}9* The functional programmatic behavior of any binary class or -interface must be that defined by the Specifications. - -include::rules.inc[] - -[[CJAIIBDJ]][[test-appeals-process]] - -2.3 Test Appeals Process -~~~~~~~~~~~~~~~~~~~~~~~~ - -Jakarta has a well established process for managing challenges to its -TCKs. Any implementor may submit a challenge to one or more tests in the -{TechnologyShortName} TCK as it relates to their implementation. Implementor -means the entity as a whole in charge of producing the final certified release. -*Challenges filed should represent the consensus of that entity*. - -2.3.1 Valid Challenges -^^^^^^^^^^^^^^^^^^^^^^ -Any test case (e.g., test class, @Test method), test case configuration (e.g., deployment descriptor), test beans, annotations, and other resources considered part of the TCK may be challenged. - -The following scenarios are considered in scope for test challenges: - -* Claims that a test assertion conflicts with the specification. -* Claims that a test asserts requirements over and above that of the specification. -* Claims that an assertion of the specification is not sufficiently implementable. -* Claims that a test is not portable or depends on a particular implementation. - -2.3.2 Invalid Challenges -^^^^^^^^^^^^^^^^^^^^^^^^ -The following scenarios are considered out of scope for test challenges and will be immediately closed if filed: - -* Challenging an implementation’s claim of passing a test. Certification is an honor system and these issues must be raised directly with the implementation. -* Challenging the usefulness of a specification requirement. The challenge process cannot be used to bypass the specification process and raise in question the need or relevance of a specification requirement. -* Claims the TCK is inadequate or missing assertions required by the specification. See the Improvement section, which is outside the scope of test challenges. -* Challenges that do not represent a consensus of the implementing community will be closed until such time that the community does agree or agreement cannot be made. The test challenge process is not the place for implementations to initiate their own internal discussions. -* Challenges to tests that are already excluded for any reason. -* Challenges that an excluded test should not have been excluded and should be re-added should be opened as a new enhancement request - -Test challenges must be made in writing via the {TechnologyShortName} specification project issue tracker -as described in link:#CJAJEAEI[Section 2.3.3, "TCK Test Appeals Steps."] - -All tests found to be invalid will be placed on the Exclude List -for that version of the {TechnologyShortName} TCK. - - -[[CJAJEAEI]][[tck-test-appeals-steps]] - -2.3.3 TCK Test Appeals Steps -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Challenges should be filed via the {TechnologyFullName} specification project’s issue tracker using the label `challenge` and include the following information: -* The relevant specification version and section number(s) -* The coordinates of the challenged test(s) -* The exact TCK and exclude list versions -* The implementation being tested, including name and company -* The full test name -* A full description of why the test is invalid and what the correct behavior is believed to be -* Any supporting material; debug logs, test output, test logs, run scripts, etc. - - - -2. Specification project evaluates the challenge. + -Challenges can be resolved by a specification project lead, or a project challenge triage team, after a consensus of the specification project committers is reached or attempts to gain consensus fails. -Specification projects may exercise lazy consensus, voting or any practice that follows the principles of Eclipse Foundation Development Process. -The expected timeframe for a response is two weeks or less. -If consensus cannot be reached by the specification project for a prolonged period of time, the default recommendation is to exclude the tests and address the dispute in a future revision of the specification. - -3. Accepted Challenges. + -A consensus that a test produces invalid results will result in the exclusion of that test from certification requirements, and an immediate update and release of an official distribution of the TCK including the new exclude list. The associated `challenge` issue must be closed with an `accepted` label to indicate it has been resolved. - -4. Rejected Challenges and Remedy. + -When a`challenge` issue is rejected, it must be closed with a label of `invalid` to indicate it has been rejected. -There appeal process for challenges rejected on technical terms is outlined in Escalation Appeal. -If, however, an implementer feels the TCK challenge process was not followed, an appeal issue should be filed with specification project’s TCK issue tracker using the label `challenge-appeal`. -A project lead should escalate the issue with the Jakarta EE Specification Committee via email (jakarta.ee-spec@eclipse.org). -The committee will evaluate the matter purely in terms of due process. -If the appeal is accepted, the original TCK challenge issue will be reopened and a label of `appealed-challenge` added, along with a discussion of the appeal decision, and the `challenge-appeal` issue with be closed. -If the appeal is rejected, the `challenge-appeal` issue should closed with a label of `invalid`. - -5. Escalation Appeal. + -If there is a concern that a TCK process issue has not been resolved satisfactorily, the -https://www.eclipse.org/projects/dev_process/#6_5_Grievance_Handling[Eclipse Development Process Grievance Handling] procedure should be followed to escalate the resolution. Note that this is not a mechanism to attempt to handle implementation specific issues. - - -[[CJAJECIE]][[specifications-for-technology]] - -2.4 Specifications for {TechnologyFullName} -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The {TechnologyFullName} specification is available from the specification -project web-site: {SpecificationURL}. - -[[CJABAHGI]][[libraries-for-technology]] - -2.5 Libraries for {TechnologyFullName} -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The following is a list of the packages comprising the required class -libraries for {TechnologyShortName} {TechnologyVersion}: - -include::packages.inc[] - -For the latest list of packages, also see: - -{SpecificationURL} diff --git a/user_guides/jacc/src/main/jbake/content/rules.inc b/user_guides/jacc/src/main/jbake/content/rules.inc deleted file mode 100644 index b5a250f697..0000000000 --- a/user_guides/jacc/src/main/jbake/content/rules.inc +++ /dev/null @@ -1,78 +0,0 @@ -/////////////////////////////////////////////////////////////////////// -NOTE TO WRITERS: -Most technologies will only need the compatibility rules in rules.adoc. -Some technologies will need additional rules. If they're needed, -remove the comment block delimiters below and update the rules as -appropriate. You may need to adjust the rule numbers to avoid gaps. - -The first comment block below is additional rules needed by JPA. - -The second comment block below is additional rules needed by -JSP and Servlet. (And EJB, if it had a standalone TCK.) - -The third comment block below is additional rules that apply -to any technology that defines deployment descriptors. - -The fourth comment block is special rules that apply only to JSP. - -NOTE: This set of examples is NOT complete, but should be. -/////////////////////////////////////////////////////////////////////// - -/////////////////////////////////////////////////////////////////////// -*{techID}10* The Runtime must report an error when processing a -Configuration Descriptor that does not conform to the Specifications. - -*{techID}11* An error must be reported when processing a configuration -descriptor that includes a Java Persistence QL expression that does not -conform to the Specifications. - -*{techID}12* The presence of an XML comment in a Configuration -Descriptor, when processed by the Runtime, must not cause the -functional programmatic behavior of the Runtime to vary from the -functional programmatic behavior of the Runtime in the absence of that -comment. -/////////////////////////////////////////////////////////////////////// - -/////////////////////////////////////////////////////////////////////// -*{techID}10* Each Container must make technically accessible all Java SE -Runtime interfaces and functionality, as defined by the Specifications, -to programs running in the Container, except only as specifically -exempted by these Rules. - -*{techID}10.1* Containers may impose security constraints, as defined by -the Specifications. -/////////////////////////////////////////////////////////////////////// - -/////////////////////////////////////////////////////////////////////// -*{techID}11* A Deployment Tool must report an error when processing a -Configuration Descriptor that does not conform to the Specifications. - -*{techID}12* The presence of an XML comment in a Configuration -Descriptor, when processed by a Deployment Tool, must not cause the -functional programmatic behavior of the Deployment Tool to vary from -the functional programmatic behavior of the Deployment Tool in the -absence of that comment. -/////////////////////////////////////////////////////////////////////// - -/////////////////////////////////////////////////////////////////////// -*{techID}11* A web Container must report an error, as defined by the -Specifications, when processing a JSP Page that does not conform to the -Specifications. - -*{techID}12* The presence of a Java language comment or Java language -directive in a JSP Page that specifies ”java” as the scripting -language, when processed by a web Container, must not cause the -functional programmatic behavior of that JSP Page to vary from the -functional programmatic behavior of that JSP Page in the absence of -that Java language comment or Java language directive. - -*{techID}13* The contents of any fixed template data (defined by the -Specifications) in a JSP Page, when processed by a web Container, must -not affect the functional programmatic behavior of that JSP Page, -except as defined by the Specifications. - -*{techID}14* The functional programmatic behavior of a JSP Page that -specifies ”java” as the scripting language must be equivalent to the -functional programmatic behavior of the JSP Page Implementation Class -constructed from that JSP Page. -/////////////////////////////////////////////////////////////////////// diff --git a/user_guides/jacc/src/main/jbake/content/tck-packages.inc b/user_guides/jacc/src/main/jbake/content/tck-packages.inc deleted file mode 100644 index 5ca50031cc..0000000000 --- a/user_guides/jacc/src/main/jbake/content/tck-packages.inc +++ /dev/null @@ -1,7 +0,0 @@ -** JDOM 1.1.3 - -** Apache Commons HTTP Client 3.1 - -** Apache Commons Logging 1.1.3 - -** Apache Commons Codec 1.9 diff --git a/user_guides/jacc/src/main/jbake/content/title.adoc b/user_guides/jacc/src/main/jbake/content/title.adoc deleted file mode 100644 index 7c9b7d9d11..0000000000 --- a/user_guides/jacc/src/main/jbake/content/title.adoc +++ /dev/null @@ -1,42 +0,0 @@ -type=page -status=published -title=TCK User's Guide for Technology Implementors -next=preface.html -prev=toc.html -~~~~~~ -include::attributes.conf[] - -TCK User's Guide for {TechnologyFullName}, Release {TechnologyVersion} for Jakarta EE -===================================================================================== - -[[eclipse-foundation]] -Eclipse Foundation ------------------- - -Technology Compatibility Kit User's Guide for {TechnologyFullName} - -Release {TechnologyVersion} for Jakarta EE - -September 2022 - -[[sthref1]] - -''''' - -Technology Compatibility Kit User's Guide for {TechnologyFullName}, -Release {TechnologyVersion} for Jakarta EE - -Copyright © 2017, 2022 Oracle and/or its affiliates. All rights reserved. - -This program and the accompanying materials are made available under -the terms of the Eclipse Public License v. 2.0, which is available at -http://www.eclipse.org/legal/epl-2.0. - -SPDX-License-Identifier: EPL-2.0 - -Oracle and Java are registered trademarks of Oracle and/or its -affiliates. Other names may be trademarks of their respective owners. - -include::title.inc[] - - diff --git a/user_guides/jacc/src/main/jbake/content/title.inc b/user_guides/jacc/src/main/jbake/content/title.inc deleted file mode 100644 index d4f3ece431..0000000000 --- a/user_guides/jacc/src/main/jbake/content/title.inc +++ /dev/null @@ -1,13 +0,0 @@ -/////////////////////////////////////////////////////////////////////// -NOTE TO WRITERS: -This is included at the tail end of the Title page. -The following section should be customized for the technology. -This is provided to allow each technology to customize legacy acronym names -that are used in this TCK. -Be sure to customize LegacyAcronym in attributes.conf -Add additional lines as needed for acronyms found in your TCK user guide. -/////////////////////////////////////////////////////////////////////// - -References in this document to {LegacyAcronym} refer to the {TechnologyFullName} unless otherwise noted. - -References in this document to EJB refer to Jakarta Enterprise Beans, unless otherwise noted. diff --git a/user_guides/jacc/src/main/jbake/content/using-examples.inc b/user_guides/jacc/src/main/jbake/content/using-examples.inc deleted file mode 100644 index b47962f035..0000000000 --- a/user_guides/jacc/src/main/jbake/content/using-examples.inc +++ /dev/null @@ -1,53 +0,0 @@ -/////////////////////////////////////////////////////////////////////// -NOTE TO WRITERS: -These CLI examples can be customized as necessary. -/////////////////////////////////////////////////////////////////////// - -1. Change to any subdirectory under `/src/com/sun/ts/tests`. -2. Start JavaTest using the following command: -+ --- -[source,oac_no_warn] ----- -ant runclient ----- --- - -[[GCMCU]] - -Example 5-1 {TechnologyShortName} TCK Signature Tests - -To run the {TechnologyShortName} TCK signature tests, enter the -following commands: - -[source,subs="attributes"] ----- -cd {sigTestDirectoryExample} -ant runclient ----- - -[[GCMBV]] - - -Example 5-2 Single Test Directory - -To run a single test directory, enter the following commands: - -[source,subs="attributes"] ----- -cd {singleTestDirectoryExample} -ant runclient ----- - -[[GCMCA]] - - -Example 5-3 Subset of Test Directories - -To run a subset of test directories, enter the following commands: - -[source,subs="attributes"] ----- -cd {subsetTestDirectoryExample} -ant runclient ----- diff --git a/user_guides/jacc/src/main/jbake/content/using.adoc b/user_guides/jacc/src/main/jbake/content/using.adoc deleted file mode 100644 index b0a41c51e1..0000000000 --- a/user_guides/jacc/src/main/jbake/content/using.adoc +++ /dev/null @@ -1,323 +0,0 @@ -type=page -status=published -title=Executing Tests -next=debug.html -prev=config.html -~~~~~~ -include::attributes.conf[] -Executing Tests -=============== - -[[GBFWO]] - - -[[executing-tests]] -5 Executing Tests ------------------ - -The {TechnologyShortName} TCK uses the JavaTest harness to execute the -tests in the test suite. For detailed instructions that explain how to -run and use JavaTest, see the JavaTest User's Guide and Reference in -the documentation bundle. - -This chapter includes the following topics: - -* link:#GBFUZ[Starting JavaTest] -* link:#GBFWM[Running a Subset of the Tests] -* link:#GCLRR[Running the TCK Against your selected CI] -* link:#GCLRZ[Running the TCK Against a Vendor's Implementation] -* link:#GBFVK[Test Reports] - - -[NOTE] -======================================================================= - -The instructions in this chapter assume that you have installed and -configured your test environment as described in -link:install.html#GBFTP[Chapter 3, "Installation,"] and -link:config.html#GBFVV[Chapter 4, "Setup and Configuration,"], -respectively. - -======================================================================= - -ifdef::rebuild[] -As explained in link:rebuild.html#GCLIZ[Appendix B, "Packaging the -Test Applications in Servlet-Compliant WAR -Files With VI-Specific Information,"] the {TechnologyShortName} TCK -introduces the concept of repackaging the TCK tests. -endif::rebuild[] - - -[[GBFUZ]][[starting-javatest]] - -5.1 Starting JavaTest -~~~~~~~~~~~~~~~~~~~~~ - -There are two general ways to run the {TechnologyShortName} TCK using -the JavaTest harness software: - -* Through the JavaTest GUI -* From the command line in your shell environment - - -[NOTE] -======================================================================= - -The `ant` command referenced in the following -two procedures and elsewhere in this guide is the Apache Ant -build tool, which will need to be downloaded separately. -The `build.xml` file in `/bin` contains the various Ant -targets for the {TechnologyShortName} TCK test suite. - -======================================================================= - - -[[GBFWH]][[to-start-javatest-in-gui-mode]] - -5.1.1 To Start JavaTest in GUI Mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Execute the following commands: - -[source,oac_no_warn] ----- -cd /bin -ant gui ----- - -[[GBFVW]][[to-start-javatest-in-command-line-mode]] - -5.1.2 To Start JavaTest in Command-Line Mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -include::using-examples.inc[] - -[[GBFWM]][[running-a-subset-of-the-tests]] - -5.2 Running a Subset of the Tests -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Use the following modes to run a subset of the tests: - -* link:#GBFVT[Section 5.2.1, "To Run a Subset of Tests in GUI Mode"] -* link:#GBFWK[Section 5.2.2, "To Run a Subset of Tests in Command-Line Mode"] -* link:#GBFVL[Section 5.2.3, "To Run a Subset of Tests in Batch Mode -Based on Prior Result Status"] - -[[GBFVT]][[to-run-a-subset-of-tests-in-gui-mode]] - -5.2.1 To Run a Subset of Tests in GUI Mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. From the JavaTest main menu, click *Configure*, then click *Change -Configuration*, and then click *Tests to Run*. + -The tabbed Configuration Editor dialog box is displayed. -2. Click *Specify* from the option list on the left. -3. Select the tests you want to run from the displayed test tree, and -then click *Done*. + -You can select entire branches of the test tree, or use `Ctrl+Click` or -`Shift+Click` to select multiple tests or ranges of tests, respectively, -or select just a single test. -4. Click *Save File*. -5. Click *Run Tests*, and then click *Start* to run the tests you selected. + -Alternatively, you can `right-click` the test you want from the test tree -in the left section of the JavaTest main window, and choose *Execute -These Tests* from the menu. -6. Click *Report*, and then click *Create Report*. -7. Specify the directory in which the JavaTest test harness will write -the report, and then click *OK* + -A report is created, and you are asked whether you want to view it. -8. Click *Yes* to view the report. - -[[GBFWK]][[to-run-a-subset-of-tests-in-command-line-mode]] - -5.2.2 To Run a Subset of Tests in Command-Line Mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Change to the directory containing the tests you want to run. -2. Start the test run by executing the following command: + -+ -[source] ----- -ant runclient ----- -+ -The tests in the directory and its subdirectories are run. - -[[GBFVL]][[to-run-a-subset-of-tests-in-batch-mode-based-on-prior-result-status]] - -5.2.3 To Run a Subset of Tests in Batch Mode Based on Prior Result Status -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can run certain tests in batch mode based on the test's prior run -status by specifying the `priorStatus` system property when invoking -`ant` - -Invoke `ant` with the `priorStatus` property. - -The accepted values for the `priorStatus` property are any combination -of the following: - -* `fail` -* `pass` -* `error` -* `notRun` - -For example, you could run all the {TechnologyShortName} tests with a -status of failed and error by invoking the following commands: - -[source,oac_no_warn] ----- -ant -DpriorStatus="fail,error" runclient ----- - -Note that multiple `priorStatus` values must be separated by commas. - -[[GCLRR]][[running-the-tck-against-the-ri]] - -5.3 Running the TCK Against another CI -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Some test scenarios are designed to ensure that the configuration and deployment of -all the prebuilt {TechnologyShortName} TCK tests against one Compatible -Implementation are successful operating with other compatible implementations, and that the TCK is ready for -compatibility testing against the Vendor and Compatible Implementations. - -1. Verify that you have followed the configuration instructions in -link:config.html#GBFVU[Section 4.1, "Configuring Your Environment to Run -the TCK Against the Compatible Implementation."] -2. If required, verify that you have completed the steps in -link:config.html#GCLIW[Section 4.3.2, "Deploying the Prebuilt Archives."] -3. Run the tests, as described in link:#GBFUZ[Section 5.1, "Starting -JavaTest,"] and, if desired, link:#GBFWM[Section 5.2, "Running a Subset -of the Tests."] - -[[GCLRZ]][[running-the-tck-against-a-vendors-implementation]] - -5.4 Running the TCK Against a Vendor's Implementation -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This test scenario is one of the compatibility test phases that all -Vendors must pass. - -1. Verify that you have followed the configuration instructions in -link:config.html#GCLHU[Section 4.2, "Configuring Your Environment to -Repackage and Run the TCK Against the Vendor Implementation."] -2. If required, verify that you have completed the steps in -link:config.html#GCLIL[Section 4.3.3, "Deploying the -Test Applications Against the Vendor Implementation."] -3. Run the tests, as described in link:#GBFUZ[Section 5.1, "Starting -JavaTest,"] and, if desired, link:#GBFWM[Section 5.2, "Running a Subset -of the Tests."] - -[[GBFVK]][[test-reports]] - -5.5 Test Reports -~~~~~~~~~~~~~~~~ - -A set of report files is created for every test run. These report files -can be found in the report directory you specify. After a test run is -completed, the JavaTest harness writes HTML reports for the test run. -You can view these files in the JavaTest ReportBrowser when running in -GUI mode, or in the web browser of your choice outside the JavaTest -interface. - -To see all of the HTML report files, enter the URL of the `report.html` -file. This file is the root file that links to all of the other HTML -reports. - -The JavaTest harness also creates a `summary.txt` file in the report -directory that you can open in any text editor. The `summary.txt` file -contains a list of all tests that were run, their test results, and -their status messages. - -[[GBFWD]][[creating-test-reports]] - -5.5.1 Creating Test Reports -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the following modes to create test reports: - -* link:#GBFVH[Section 5.5.1.1, "To Create a Test Report in GUI Mode"] -* link:#GBFVC[Section 5.5.1.2, "To Create a Test Report in Command-Line Mode"] - -[[GBFVH]][[to-create-a-test-report-in-gui-mode]] - -5.5.1.1 To Create a Test Report in GUI Mode -+++++++++++++++++++++++++++++++++++++++++++ - -1. From the JavaTest main menu, click *Report*, then click *Create Report*. + -You are prompted to specify a directory to use for your test reports. -2. Specify the directory you want to use for your reports, and then -click *OK*. + -Use the Filter list to specify whether you want to generate reports for -the current configuration, all tests, or a custom set of tests. + -You are asked whether you want to view report now. -3. Click *Yes* to display the new report in the JavaTest ReportBrowser. - -[[GBFVC]][[to-create-a-test-report-in-command-line-mode]] - -5.5.1.2 To Create a Test Report in Command-Line Mode -++++++++++++++++++++++++++++++++++++++++++++++++++++ - -1. Specify where you want to create the test report. -a. To specify the report directory from the command line at runtime, -use: -+ -[source] ----- -ant -Dreport.dir="report_dir" ----- -+ -Reports are written for the last test run to the directory you specify. -2. To specify the default report directory, set the `report.dir` -property in +{jteFileName}+. + -For example: -+ -[source] ----- -report.dir="/home/josephine/reports" ----- -+ -3. To disable reporting, set the `report.dir` property to `"none"`, -either on the command line or in +{jteFileName}+. + -For example: -+ -[source] ----- -ant -Dreport.dir="none" ----- -+ - -[[GBFVB]][[viewing-an-existing-test-report]] - -5.5.2 Viewing an Existing Test Report -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the following modes to view an existing test report: - -* link:#GBFVO[Section 5.5.2.1, "To View an Existing Report in GUI Mode"] -* link:#GBFWB[Section 5.5.2.2, "To View an Existing Report in -Command-Line Mode"] - -[[GBFVO]][[to-view-an-existing-report-in-gui-mode]] - -5.5.2.1 To View an Existing Report in GUI Mode -++++++++++++++++++++++++++++++++++++++++++++++ - -1. From the JavaTest main menu, click *Report*, then click *Open Report*. + -You are prompted to specify the directory containing the report you want -to open. -2. Select the report directory you want to open, and then click *Open*. + -The selected report set is opened in the JavaTest ReportBrowser. - -[[GBFWB]][[to-view-an-existing-report-in-command-line-mode]] - -5.5.2.2 To View an Existing Report in Command-Line Mode -+++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Use the Web browser of your choice to view the `report.html` file in the -report directory you specified from the command line or in +{jteFileName}+. - -include::using.inc[] - diff --git a/user_guides/jacc/src/main/jbake/content/using.inc b/user_guides/jacc/src/main/jbake/content/using.inc deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/user_guides/platform/src/main/jbake/content/commonappdeploy.adoc b/user_guides/platform/src/main/jbake/content/commonappdeploy.adoc index dce6d0437b..35f78b7f64 100644 --- a/user_guides/platform/src/main/jbake/content/commonappdeploy.adoc +++ b/user_guides/platform/src/main/jbake/content/commonappdeploy.adoc @@ -1,7 +1,7 @@ type=page status=published title=Common Applications Deployment -next=jaspic-files.html +next=database-config.html prev=portingpackage.html ~~~~~~ Common Applications Deployment diff --git a/user_guides/platform/src/main/jbake/content/config.adoc b/user_guides/platform/src/main/jbake/content/config.adoc index 8da2a2b255..0bf429e0c6 100644 --- a/user_guides/platform/src/main/jbake/content/config.adoc +++ b/user_guides/platform/src/main/jbake/content/config.adoc @@ -2117,199 +2117,6 @@ in the `ts.jte` file. ======================================================================= - -[[GKWVB]][[jakarta-authentication-service-test-setup]] - -5.4.16 Jakarta Authentication Service Test Setup -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Jakarta Authentication Service for Containers (Authentication) -1.1 tests are security tests. The Jakarta Authentication Servlet (jaspicservlet) profile is the only -required profile for Jakarta EE 11 Platform TCK. There are other optional profile -tests, such as SOAP, but you are not required to run these for -certification. - -The test suite includes the following Ant targets that configure the -test environment for the Jakarta Authentication tests - -* `config_vi` target in `/bin/build.xml` -* `enable.jaspic`, also in `/bin/build.xml` - -Both targets call `/bin/xml/impl/glassfish/javaee_vi.xml`, -which then makes calls into `/bin/xml/impl/glassfish/s1as.xml`. -You may want to examine these targets to see what is done in greater -detail. - -Complete the following steps before you run the Jakarta Authentication tests: - -. Configure the Jakarta Authentication-required properties in the `ts.jte` file: - -.. Set the `provider.configuration.file` property to the location of -your implementation's instance `lib` directory, where it can be loaded -when your implementation runtime is started. + -This file typically coexists with the `tssv.jar` file and the -`provider-configuration.dtd` file. - -.. Set the `vendor.authconfig.factory` property to specify your -`AuthConfigFactory` class. + -This property setting will be used by the Jakarta Authentication tests to register the -test suite's provider in your `AuthConfigFactory`. - -.. Set the `logical.hostname.servlet` property to the logical host that -will process Servlet requests. + -Servlet requests may be directed to a logical host using various -physical or virtual host names or addresses. A message processing -runtime may be composed of multiple logical hosts. This setting is -required to properly identify the Servlet profile's application context -identifier hostname. If the logical host that will process Servlet -requests does not exist, you can set this to the default hostname of -your implementation's Web server. - -.. Set the `servlet.is.jsr115.compatible` property based on whether or -not you are running the Servlet profile in a Jakarta Authorization 1.5 compatible -container. -. Ensure that the `config.vi` Ant task has been run before running the -`enable.jaspic` Ant task. + -These Ant tasks perform the following Jakarta Authentication-required steps: - -* Set up users and passwords for your implementation. + -See Step link:#BABDADHA[9]link:#BABBHFAI[b] in link:#GEWWA[Configuring -Your Application Server as the VI] for more information. - -* Install the client-side certificate in the `trustStore` in your -implementation. + -See Step link:#BABEGCJH[17] in link:#GEWWA[Configuring Your Application -Server as the VI] for more information. - -* Append the file `/bin/server_policy.append` to the Java -policy file or files on your implementation. + -See Step 17 in link:#GEWWA[Configuring Your Application Server as the -VI]link:#GEWWA[Configuring Your Application Server as the VI] for more -information. - -* Appends the file `/bin/client_policy.append` to the -application client's Java policy file, which is referenced in the -`TestExecuteAppClient` section of the `ts.jte` file. + -See Step 18 in link:#GEWWA[Configuring Your Application Server as the -VI]link:#GEWWA[Configuring Your Application Server as the VI] for more -information. - -* Copies the `/lib/tssv.jar` file to your implementation -instance library directory. + -The `tssv.jar` file includes the class files necessary to load -`TSAuthConfigFactory` and related classes. - -* Copies the TSSV configuration files (`ProviderConfiguration.xml`, -`configuration.dtd`) to your implementation instance library directory. + -The `provider-configuration.dtd` file is a DTD file that resides in the -same directory as the `ProviderConfiguration.xml` file and describes the -`ProviderConfiguration.xml` file. This file should not be edited. - -* Copies `/bin/ts.java.security` to -`/domains/domain1/config/ts.java.security`, where -`` is the location of your Jakarta EE 11 CI installation. - -* Sets the following JVM options: - -** `-Djava.security.properties=/domains/domain1/config/ts.java.security` - -** `-Dlog.file.location=${log.file.location}` - -** `-Dprovider.configuration.file=${provider.configuration.file}` -. Deploy the Jakarta Authentication log file processor, -`/dist/com/sun/ts/tests/jaspic/util/jaspic_util_web.war`, to -the implementation under test. -+ -[NOTE] -======================================================================= - -It may be necessary to restart your implementation after completing this -step. - -======================================================================= -+ -. Run the tests for the profiles with which you are trying to certify. -. After running the Jakarta Authentication tests, change back to the `/bin` -directory and execute the following command: -+ -[source,oac_no_warn] ----- -cd /bin -ant disable.jaspic ----- -+ -This Ant task undoes the changes that were made to your implementation -by the `enable.jaspic` target. If these changes are not reversed, your -implementation may be left in an uncertain state. - -[[GEYBI]][[jakarta-authorization-test-setup]] - -5.4.17 Jakarta Authorization Test Setup -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To comply with Jakarta EE 11 requirements, Jakarta Authorization must be supported in both -the Web and Jakarta Enterprise Beans environments. -The tests for each environment are divided into two directories: - -* `src/com/sun/ts/tests/jacc/web` -* `src/com/sun/ts/tests/jacc/ejb` - -When deploying the archives that contain Jakarta Authorization tests, don't deploy all -the Jakarta Authorization test archives at the same time. While this may work, there have -been times when it has caused problems. The recommended course of action -is to deploy the test archive for the directory under test. Once done, -remove that archive and move onto another directory. - -The Jakarta Authorization-TCK provider acts as a delegating security provider sitting -between the appserver and vendor provider. The Jakarta Platform, Enterprise -Edition appserver comes with a default security provider that is defined -by two system properties; for the purposes of this discussion, these are -referred to as `A=DefaultProviderFactory` and `B=DefaultPolicyModule`. - -TCK moves the values from A and B to two new variables: -`C=DefaultProviderFactory` and `D=DefaultPolicyModule`, replacing the -TCK provider classes to the variables `A` and `B` (`A=TSProviderFactory` -and `B=TSPolicyModule`). This modification allows the server to call the -TCK provider for all its functions, and the TCK provider in turn uses -these new variables to invoke the real provider. - -The property names `A`, `B`, `C`, and `D` are used for convenience here. -The real property names are as follows: - -* `A=jakarta.security.jacc.PolicyConfigurationFactory.provider` -* `B=jakarta.security.jacc.policy.provider` -* `C=vendor.jakarta.security.jacc.PolicyConfigurationFactory.provider` -* `D=vendor.jakarta.security.jacc.policy.provider` - -To configure the Jakarta Authorization provider for the Jakarta Platform, Enterprise Edition -CI, execute the Jakarta Authorization Ant target from: - -[source,oac_no_warn] ----- -/bin ----- - -This command does the following: - -* Switches the system properties. -* Adds `tsprovider.jar` to Jakarta Platform, Enterprise Edition application -server's classpath. -* Adds `log.file.location` system property to the Jakarta Platform, -Enterprise Edition application server's system properties. This is used -for generating log files, which is used for verifying Jakarta Authorization 1.5 contracts. - - -[NOTE] -======================================================================= - -When running Jakarta Authorization tests against the Jakarta EE 11 CI, if you need to restart -the CI, be sure to first remove all Jakarta Authorization log files (`jacc_log.*`) from -the `JAVAEE_HOME/domains/domain1/logs` directory before running the Jakarta Authorization -tests again. - -======================================================================= - - [[GEYAM]][[wsdl-webservice-test-and-runtime-notes]] 5.4.18 WSDL: Webservice Test and Runtime Notes diff --git a/user_guides/platform/src/main/jbake/content/database-config.adoc b/user_guides/platform/src/main/jbake/content/database-config.adoc index 9799aebe81..e234592738 100644 --- a/user_guides/platform/src/main/jbake/content/database-config.adoc +++ b/user_guides/platform/src/main/jbake/content/database-config.adoc @@ -2,7 +2,7 @@ type=page status=published title=Configuring Your Backend Database next=ejbql-schema.html -prev=jaspic-files.html +prev=commonappdeploy.html ~~~~~~ Configuring Your Backend Database ================================= diff --git a/user_guides/platform/src/main/jbake/content/jaspic-files.adoc b/user_guides/platform/src/main/jbake/content/jaspic-files.adoc deleted file mode 100644 index 2c5597f323..0000000000 --- a/user_guides/platform/src/main/jbake/content/jaspic-files.adoc +++ /dev/null @@ -1,171 +0,0 @@ -type=page -status=published -title=Jakarta Authentication Technology Notes and Files -next=database-config.html -prev=commonappdeploy.html -~~~~~~ -Jakarta Authentication Technology Notes and Files -================================================== - -[[GLAEQ]][[b-jakarta-authentication-technology-notes-and-files]] - -B Jakarta Authentication Technology Notes and Files ---------------------------------------------------- - -The Jakarta Authentication (formerly jaspic) technology tests are used to verify the compatibility of an -implementer's implementation of the Jakarta Authentication 2.0 specification. - -This appendix provides information about the following topics: - -* link:#GLAFO[Jakarta Authentication 2.0 Technology Overview] -* link:#GLAFE[Jakarta Authentication TSSV Files] - -You run the `ant enable.jaspic` command to configure the Jakarta EE 11 CI to -run the Jakarta Authentication tests. After running the Jakarta Authentication tests, you run the -`ant disable.jaspic` command to restore the Jakarta EE 11 CI to the state it -was in before you configured it for running the Jakarta Authentication tests. This is -required because Jakarta Authentication replaces some of the Jakarta EE 11 CI's default -system security components with TCK security components. If this change -is not reverted after the tests have been run, the CI's system security -could be left in a partially working state. The TCK security -`AuthConfigFactory` and `AuthConfigProvider`(s) are designed for -compatibility testing, not the functional completeness that one expects -from the Jakarta EE 11 CI. - -[[GLAFO]][[b.1-jakarta-authentication-2.0-technology-overview]] - -B.1 Jakarta Authentication 2.0 Technology Overview -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Jakarta Authentication 2.0 specification defines a service provider -interface (SPI) by which authentication providers implementing message -authentication mechanisms can be integrated in client and server message -processing runtimes (or containers). - -Jakarta EE 11 Platform TCK uses a Test Suite SPI Verifier (TSSV) to verify whether -the vendor's message processing runtimes invoke the right SPI in the -right order. - -The TSSV includes test suite implementations of: - -* `AuthConfigFactory` -* `AuthConfigProvider` -* `AuthConfig(Client & Server)` -* `AuthContext(client & Server)` -* `AuthenticationModules(Client & Server)` - -The TSSV gets loaded into vendor's message processing runtime using one of -the following two ways as defined by the Jakarta Authentication 2.0 specification: - -* By defining a property in `JAVA_HOME/jre/lib/security/java.security` -as follows: -`authconfigprovider.factory=com.sun.ts.tests.jaspic.tssv.config.TSAuthConfigFactory` - -* By calling `registerConfigProvider()` method in vendor's -`AuthConfigFactory` with the following values: - -** Test Suite Provider ClassName - -** Map of properties - -** Message Layer (such as `SOAP` or `HttpServlet`) - -** Application Context Identifier - -** A description of the provider - - -[NOTE] -======================================================================= - -For the Jakarta EE 11 Platform TCK, we register more than one provider in vendor's -message processing runtime. - -======================================================================= - - -In a typical test scenario (for each profile of Servlet or SOAP), an -application is deployed into a vendor's runtime, and a client invokes -the service. The message policies required for the secure invocations -are built into the TSSV implementations, and the runtime is analyzed to see -whether it invokes the right SPIs at the right time. - -The TSSV uses Java logging APIs to log the client and server invocation into -a log file (`TSSVLog.txt`), this log file is used by the TCK tests to -validate actual logged runtime information against expected results to -ensure that the runtime is compliant. The `jaspic_util_web.war` file -contains the Jakarta Authentication log file processor, which writes output to the -`TSSVLog.txt` file. The `TSSVLog.txt` file is put into the location -defined by the `log.file.location` property in the `ts.jte` file. - -[[GLAFE]][[b.2-jakarta-authentication-tssv-files]] - -B.2 Jakarta Authentication TSSV Files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The following sections describe the `tssv.jar`, -`ProviderConfiguration.xml`, and `provider-configuration.dtd` files that -are used by the Jakarta Authentication TCK tests. - -[[GLAGR]][[b.2.1-tssv.jar-file]] - -B.2.1 tssv.jar file -^^^^^^^^^^^^^^^^^^^ - -The `tssv.jar` file contains classes necessary for populating your -implementation with a TCK AuthConfigFactory (ACF) as well as information -used to register TCK providers. The tssv.jar file contains the class -files for the Test Suite SPI Verifier. The `tssv.jar` file classes need -to be loaded by your implementation's runtime during startup. - -[[GLADE]][[b.2.2-providerconfiguration.xml-file]] - -B.2.2 ProviderConfiguration.xml file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The format of the `ProviderConfiguration.xml` file is a test -suite-specific format.  The file was designed to contain test provider -information the test suite uses to populate the ACF with a list of -providers for testing. The file needs to be copied to the location -specified in the ts.jte file by the `provider.configuration.file` -property. An edit to the `ProviderConfiguration.xml` file may be -required for your implementation. The current application context Ids -are generic and should work as is, but there could be some scenarios in -which the application Context Ids may need to be altered. - -The value of the `` element in the -`ProviderConfiguration.xml` file should reflect what your implementation -will use for its internal representation of the application context -identifier for a registered provider. Said differently, the test suite -registers its providers with information from the -`ProviderConfiguration.xml` file but every implementation is not -guaranteed to use the application context identifier that is used in the -call to register the configuration provider. This value of the -`` element corresponds to the `appContext` argument in -the `AuthConfigFactory.registerConfigProvider()` API. The API -documentation for this method indicates that the `appContext` argument -may be used but is not guaranteed to be used. - -The default `ProviderConfiguration.xml` file should work without -modification but you may need to alter the value of the -`` element as previously described to accommodate the -implementation under test. You need to find the correct application -context identifier for your implementation. - -You should enable two levels of logging output to get finer levels of -debugging and tracing information than is turned on by default. This is -done by setting the `traceflag` property in the `ts.jte` file and the -`HARNESS_DEBUG` environment variable to `true`.  If both of these are set, -application context identifier information should appear in the debug -output. - -[[GLAFZ]][[b.2.3-provider-configuration.dtd-file]] - -B.2.3 provider-configuration.dtd file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The `provider-configuration.dtd` file is a DTD file that resides in the -same directory as the `ProviderConfiguration.xml` file and describes the -`ProviderConfiguration.xml` file. This file should not be edited. - - diff --git a/user_guides/platform/src/main/jbake/content/toc_1.adoc b/user_guides/platform/src/main/jbake/content/toc_1.adoc index 9f579004a6..1aff10e466 100644 --- a/user_guides/platform/src/main/jbake/content/toc_1.adoc +++ b/user_guides/platform/src/main/jbake/content/toc_1.adoc @@ -186,12 +186,6 @@ link:portingpackage.html#GFATG[11 Implementing the Porting Package] *** link:portingpackage.html#GFATO[11.2.5 TSURLInterface] *** link:portingpackage.html#GFASJ[11.2.6 TSHttpsURLConnectionInterface] * link:commonappdeploy.html#GFAVR[A Common Applications Deployment] -* link:jaspic-files.html#GLAEQ[B Jakarta Authentication Technology Notes and Files] -** link:jaspic-files.html#GLAFO[B.1 Jakarta Authentication 2.0 Technology Overview] -** link:jaspic-files.html#GLAFE[B.2 Jakarta Authentication TSSV Files] -*** link:jaspic-files.html#GLAGR[B.2.1 tssv.jar file] -*** link:jaspic-files.html#GLADE[B.2.2 ProviderConfiguration.xml file] -*** link:jaspic-files.html#GLAFZ[B.2.3 provider-configuration.dtd file] * link:database-config.html#GFAVUb[C Configuring Your Backend Database] ** link:database-config.html#GFKNA[C.1 Overview] ** link:database-config.html#GFKNR[C.2 The init. Ant Target] diff --git a/user_guides/platform/src/main/jbake/content/using.adoc b/user_guides/platform/src/main/jbake/content/using.adoc index 4e55cffa09..f763da3dea 100644 --- a/user_guides/platform/src/main/jbake/content/using.adoc +++ b/user_guides/platform/src/main/jbake/content/using.adoc @@ -541,8 +541,6 @@ Subsets |================================== |Technology |Keyword |Jakarta Connectors |`connector_web_profile` -|Jakarta Authorization (formerly JACC) |`jacc_web_profile` -|Jakarta Authentication (formerly JASPIC) |`jaspic_web_profile` |Jakarta Mail (formerly JavaMail) |`javamail_web_profile` |Jakarta Registries (formerly JAXR) |`jaxr_web_profile` |Jakarta Messaging(formerly JMS) |`jms_web_profile` @@ -630,7 +628,6 @@ vehicles in which tests are run: * ejblitesecuredjsp_vehicle * ejbliteservlet_vehicle * ejbliteservlet2_vehicle -* jaspicservlet_vehicle * pmservlet_vehicle * puservlet_vehicle * wsservlet_vehicle diff --git a/user_guides/pom.xml b/user_guides/pom.xml index 8c15f91f92..42b85088e2 100644 --- a/user_guides/pom.xml +++ b/user_guides/pom.xml @@ -33,7 +33,6 @@ connector - jacc jaxws jms jsp diff --git a/websocket/spec-tests/src/main/java/com/sun/ts/tests/websocket/signaturetest/WebSocketSigTestIT.java b/websocket/spec-tests/src/main/java/com/sun/ts/tests/websocket/signaturetest/WebSocketSigTestIT.java index 5cda2fed61..55cff8523d 100644 --- a/websocket/spec-tests/src/main/java/com/sun/ts/tests/websocket/signaturetest/WebSocketSigTestIT.java +++ b/websocket/spec-tests/src/main/java/com/sun/ts/tests/websocket/signaturetest/WebSocketSigTestIT.java @@ -152,7 +152,7 @@ public WebSocketSigTestIT() { * Returns a list of strings where each string represents a package name. Each * package name will have it's signature tested by the signature test framework. * - * @param vehicleName The name of the Jaspic container where the signature tests + * @param vehicleName The name of the container where the signature tests * should be conducted. * @return String[] The names of the packages whose signatures should be * verified.