Jakarta Authentication Technology Notes and Files

Previous Next Contents

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 1.1 specification.

This appendix provides information about the following topics:

You run the ant enable.jaspic command to configure the Jakarta EE 9 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 9 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 9 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 9 CI.

B.1 Jakarta Authentication 1.1 Technology Overview

The Jakarta Authentication 1.1 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 9 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 1.1 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 9 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.

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.

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.

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 <app-context-id> 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 <app-context-id> 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 <app-context-id> 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.

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.


Previous Next Contents
Eclipse Foundation Logo  Copyright © 2018, 2020 Oracle and/or its affiliates. All rights reserved.