Test against a running ADS

You can run your system tests against a running Access Decision Service (ADS), from your machine or from a build server such as Jenkins or Azure DevOps. For example, run them against your own ADS before you deploy a new authorization domain, or against a deployed ADS to verify it.

Not all tests run against a running ADS. It evaluates only the main policy of the authorization domain, with its own attribute connectors, so APD skips the tests that need the policy engine embedded in APD:

Test type	./gradlew test (embedded)	./gradlew test_ProdEnvironment (running ADS)
Policy tests with withMainPolicy for a policy other than the main policy (unit and integration tests)	Runs	Skipped
Attribute connector tests	Runs	Skipped
System tests, and policy tests of the main policy	Runs	Runs

For the test types, see Test policies in depth.

Create a test task for a running ADS

To test a running ADS, create a test task in your build.gradle file:

build.gradle

task test_ProdEnvironment(type: Test) {
    group "verification"
    environment "ALFA_TEST_REMOTE_URL", "http://abac.acme.com:8081/authorize"
    environment "ALFA_TEST_REMOTE_USER", "pdp-user"
    environment "ALFA_TEST_REMOTE_PASSWORD", System.getenv("ADS_PASSWORD")
    environment "ALFA_TEST_REMOTE_HEADER_FILE", file("headers.json").absolutePath
}

Read the password from an environment variable, here ADS_PASSWORD, instead of writing it in build.gradle. Set the header file with its absolute path, as above: the tests run in the directory src/extra, where a relative path is not found.

To test your own ADS on your machine, for example one started with runAds, use its local address. The build.gradle of the APD distribution contains this task as a comment:

build.gradle

task test_LocalEnv(type: Test) {
    group "verification"
    environment "ALFA_TEST_REMOTE_URL", "http://127.0.0.1:8080/authorize"
    environment "ALFA_TEST_REMOTE_USER", "pdp-user"
    environment "ALFA_TEST_REMOTE_PASSWORD", System.getenv("ADS_PASSWORD")
}

tip

To test a domain in Authorization Hub or ASM without your own ADS, use the tasks APD creates for each remote: test{environment}-{domainName} starts a local ADS that loads the domain from there and runs the system tests against it, and runAdsWith{environment}-{domainName} only starts that ADS. See ADS and system tests.

The tests compare the policy under test with the main policy of your authorization domain, set in the alfa section of your build.gradle file:

build.gradle

alfa {
    mainpolicy "acme.Main"
}

Remote test execution

[user@machine project]# ./gradlew test_ProdEnvironment

com.myorg.alfa.MyAttributeconnectorTest > shouldGetRoleConsultantForCecilia SKIPPED

com.myorg.alfa.MyAttributeconnectorTest > shouldGetRoleManagerForMartin SKIPPED

com.myorg.alfa.MyConsultantPolicyUnitTest > shouldPermitIfUserAndResourceAreInSameLocation SKIPPED

com.myorg.alfa.MyConsultantPolicyUnitTest > shouldNotPermitIfUserAndResourceAreInDifferentLocation SKIPPED

com.myorg.alfa.MySystemTest > shouldGiveCeciliaAccessToResource1 PASSED

com.myorg.alfa.MySystemTest > shouldGiveMartinAccessToResource1 PASSED

com.myorg.alfa.MySystemTest > shouldNotGiveCeciliaAccessToResource2 PASSED

Environment variables

The following variables are available for controlling remote test execution:

Environment variable	Description	Example
ALFA_TEST_REMOTE_URL	The URL of the ADS endpoint for access requests in the JSON Profile of XACML 3.0 Version 1.1Opens in a new tab.	http://127.0.0.1:8080/authorize
ALFA_TEST_REMOTE_USER	The username for Basic authentication.	pdp-user
ALFA_TEST_REMOTE_PASSWORD	The password for Basic authentication. Read it from an environment variable.	System.getenv("ADS_PASSWORD")
ALFA_TEST_REMOTE_HEADER_FILE	The absolute path of a JSON file with extra HTTP headers.	See Extra headers below.

Extra headers

If the test client needs to include additional headers in requests to ADS (for example, when an API gateway is present), you can define these headers in a separate JSON file. Specify the file's absolute path with the ALFA_TEST_REMOTE_HEADER_FILE environment variable, for example file("headers.json").absolutePath in build.gradle. This file supports Environment variables, allowing you to externalize configuration.

headers.json

{
  "Target-Environment": "PROD",
  "Secret-Header": "${SECRET_VALUE}"
}