Introduction

## 1 Introduction

This chapter provides an overview of the principles that apply generally to all Technology Compatibility Kits (TCKs) and describes the Jakarta Authentication TCK (Authentication 3.0 TCK). It also includes a high level listing of what is needed to get up and running with the Authentication TCK.

This chapter includes the following topics:

- Compatibility Testing

- About the TCK

- Getting Started With the TCK

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

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

#### 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 Chapter 2, "Procedure for Certification."

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

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

### 1.2 About the TCK

The Authentication TCK 3.0 is designed as a portable, configurable, automated test suite for verifying the compatibility of a vendor’s implementation of the Authentication 3.0 Specification.

#### 1.2.1 TCK Specifications and Requirements

This section lists the applicable requirements and specifications.

- Specification Requirements: Software requirements for a Authentication implementation are described in detail in the Authentication 3.0 Specification. Links to the Authentication specification and other product information can be found at https://jakarta.ee/specifications/authentication/3.0/.

- Authentication Version: The Authentication 3.0 TCK is based on the Authentication Specification, Version 3.0.

- Compatible Implementation: One Authentication 3.0 Compatible Implementation, Eclipse GlassFish 7.0 is available from the Eclipse EE4J project (https://projects.eclipse.org/projects/ee4j). See the CI documentation page at https://projects.eclipse.org/projects/ee4j.glassfish for more information.

See the Authentication TCK Release Notes for more specific information about Java SE version requirements, supported platforms, restrictions, and so on.

#### 1.2.2 TCK Components

The Authentication TCK 3.0 includes the following components:

- If applicable, an exclude list, which provides a list of tests that your implementation is not required to pass.

- API tests for all of the Authentication API in all related packages:

  - `jakarta.security.auth.message`

  - `jakarta.security.auth.message.callback`

  - `jakarta.security.auth.message.config`

  - `jakarta.security.auth.message.module`

The Authentication TCK tests run on the following platforms:

- CentOS Linux 7

- Alpine Linux v3.12

#### 1.2.3 TCK Compatibility Test Suite

The test suite is the collection of JUnit tests used with the Maven Surefire plugin to test a particular technology implementation. In this case, it is the collection of tests used by the Authentication TCK 3.0 to test a Authentication 3.0 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.

#### 1.2.4 TCK Configuration

You need to set several variables in your test environment, modify properties and run the Authentication tests, as described in Chapter 4, "Setup and Configuration."

#### 1.2.7 Authentication Technology Overview

The Authentication 3.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.

The Authentication TCK uses a Test Suite SPI Verifier (TSSV) to verify whether the vendor’s message processing runtimes invoke the correct SPI in the proper order.

TSSV includes test suite implementations of:

- `AuthConfigFactory`

- `AuthConfigProvider`

- `AuthConfigClient`, `AuthConfigServer`

- `AuthContextClient`, `AuthContextServer`

- `AuthenticationModulesClient`, `AuthenticationModules Server`

TSSV gets loaded into vendor’s message processing runtime using one of the following ways, as defined by the 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 the `registerConfigProvider()` method in a 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 Authentication TCK, more than one provider is registered in the 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 TSSV implementations, and the runtime is analyzed to see whether it invokes the correct SPIs at the proper time.

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

#### 1.2.8 Authentication TSSV Files

The following sections describe the `tssv.jar`, `ProviderConfiguration.xml`, and `provider-configuration.xsd` files that are used by the Authentication TCK tests.

##### 1.2.8.1 tssv.jar file

The `tssv.jar` file contains classes necessary for populating a vendor implementation with a CTS AuthConfigFactory (ACF) as well as information used to register CTS 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 the vendor implementation runtime during startup.

##### 1.2.8.2 ProviderConfiguration.xml file

The format 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 the vendor 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 modified.

The value of the `<app-context-id>` element in the `ProviderConfiguration.xml` file should reflect what the vendor 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 a vendor may need to alter the value of the `<app-context-id>` element as previously described to accommodate the implementation under test. Vendors need to find the correct application context identifier for their implementation.

Vendors 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 to "true" and setting the HARNESS_DEBUG environment variable to "true". If both of these are set, the debug output should contain application context identifier information.

##### 1.2.8.3 provider-configuration.xsd file

The `provider-configuration.xsd` file is a schema file that resides in the same directory as the `ProviderConfiguration.xml` file and describes the `ProviderConfiguration.xml` file. This file should not be edited.

#### 1.2.9 Baseline Compatibility Requirements

To obtain Baseline compliance, a vendor must meet the Baseline Compatibility requirements.

#### 1.2.10 Servlet Profile Tests

To obtain Servlet Profile compliance, a vendor must meet the Baseline Compatibility requirements as well as the Servlet Profile requirements.

#### 1.2.11 SOAP Profile Tests

Since various SOAP implementations are possible in a vendor’s message processing runtime, the Authentication TCK considers the following SOAP implementations:

- SOAP implementation in a Jakarta EE environment

- SOAP implementation in standalone container (Java SE only)

- Non-container based SOAP implementation

For SOAP profile tests, the client invocations of webservice have been abstracted into two different types:

- Invocations of Service in a Jakarta EE environment (for example, using JAXWS annotations `@WebServiceRef` for looking up the service and `@WebService` for service definition).

- Invocations of Service in a standalone (i.e. Java SE only) environment (this includes standalone container and non-container based implementation).
  The following are used to get the service reference:

  - WSDL

  - Service `QName` (for example, `QNAME(NAMESPACEURI, SERVICENAME)`)

  - Service Class (such as `HelloService.class`)

  - PORT `QName` (for example, `QName(NAMESPACEURI, PORT_NAME)`)

  - Service Endpoint Interface class (for example, `Hello.class`)

The deployment abstraction for handling various SOAP implementations are handled in the following ways:

- A Jakarta Deployment version 1.2 deployment is used for Jakarta EE based implementations. This is differentiated by using a different deliverable class, `deliverable.class=com.sun.ts.lib.deliverable.jaspic.JaspicJakartaEEDeliverable`, which is configurable in the `ts.jte` file. Vendors need to write their own `Deliverable` class that can be used to deploy in their environment.

- For standalone implementations (this includes container and non-container based implementations), a different deliverable class is used, `deliverable.class=com.sun.ts.lib.deliverable.jaspic.JaspicDeliverable`. Along with this deliverable class an Ant file, `TS_HOME/bin/xml/deploy.xml`, is used to deploy in GlassFish Server. Vendors are expected to implement the `deploy` and `undeploy` targets in `deploy.xml` to suite their environment.

Note | Two deliverable implementations are provided with the GlassFish server. One implementation, for Java SE only servers, turns off auto deployment and leaves the deployment up to the licensee by way of an Ant target.

- Along with the deliverable class, a configurable property in the `ts.jte` file, `platform.mode`, is used to distinguish the different SOAP implementations.

  - `platform.mode=jakartaEE` (for Jakarta EE based implementations)

  - `platform.mode=standalone`

Note | A deployable EAR , WAR, or JAR file is created, based on the value specified by the `platform.mode` property in the `ts.jte` file.

- For non-container based standalone SOAP implementations, vendors are expected to deploy the service and make it available for client invocations. For this purpose, a no-op for `deploy` and `undeploy` targets can be implemented in the `deploy.xml` file.

The Authentication TCK uses Jakarta Web Services Metadata, 3.0 metadata based annotations to define web service applications. Although Jakarta Web Services Metadata, 3.0 support is not required in a vendor’s SOAP implementation, using web services metadata simplifies the definition of web services and the linking between various artifacts of web services (the WSDL, `ServiceEndpoint`, and implementation and their associations). Using other forms of web services implementation will lead to separate binding files, web services description files (`webservices.xml`) which are different for different SOAP implementations, such as a Jakarta EE based SOAP implementation, standalone implementation, and so on.

Since vendors are already expected to generate web service artifacts using `wsgen` and `wsimport` tools, writing an annotation processor to support Jakarta Web Services Metadata, 3.0 based annotations is just a step further towards making a better SOAP implementation. Also having annotated web services helps vendors generate different artifacts that suit their SOAP implementation.

Note | For Jakarta EE based SOAP implementations, Jakarta Web Services Metadata, 3.0 support is required.

Note | The Jakarta EE Specification Process support multiple compatible implementations. These instructions explain how to get started with the Eclipse GlassFish 7.0 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 Authentication 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 Maven Surefire plugin run:

- Java SE 11

- A CI for Authentication 3.0. One example is Eclipse GlassFish 7.0.

- Authentication TCK version 3.0, which includes:

  - JDOM 1.1.3

  - Apache Commons HTTP Client 3.1

  - Apache Commons Logging 1.1.3

  - Apache Commons Codec 1.9

- The Authentication 3.0 Vendor Implementation (VI)
  See the documentation for each of these software applications for installation instructions. See Chapter 3, "Installation," for instructions on installing the Authentication TCK.

  1. Set up the Authentication TCK software.
     See Chapter 4, "Setup and Configuration," for details about the following steps.

     1. Set up your shell environment.

  2. Test the Authentication 3.0 implementation.
     Test the Authentication implementation installation by running the test suite. See Chapter 5, "Executing Tests."

Copyright © 2017, 2021 Oracle and/or its affiliates. All rights reserved.