Mock BIP Claims API

The BIP APIs are not available outside of VA firewall for local development. There is a UAT BIP Claims API server within VA firewall but using it currently requires

• Developing on GFE's which have typically not enough resources for projects of VRO size
• Installing and maintaining of Java requires special permissions
• Other security requirements makes it difficult to test https
• Since the server is not controlled by the VRO team creating and maintaining claims for test cases is difficult

Due to these difficulties, a Mock BIP Claims API has been developed. This mock is now an integral part of the End to End Tests.

HTTPS Server

Mock Claims API is an HTTPS enabled Spring Boot server. It uses self-signed certificates generated by the build-certificates.sh. In particular the PKCS#12 files client_truststore.p12 and server_keystore.p12 are placed in resources directory and pointed directly in application.yml server.ssl property to set up an https port 8097.

Note that if you generate a new set of self-signed certificates using build-certificates.sh and change it in Mock BIP Claims API, the corresponding certificates in Application and Mock BIP Claim Evidence API subprojects must change as well.

Health Check

The standard Spring Boot Health Check is provided in http port 8080 and configured in application.yml management property.

HTTP Server

One primary use of the Mock Claims API is the End to End Tests. Since these are black-box tests that do not have access to https setup within the VRO application, it is involved to have these tests to use the https port. To simplify the End to End Tests, an http port 8099 is made available. The full set of end-points are available through this port.

The implementation of opening the http port 8099 can be found here.

Open API Specification

Open API Specification of the Mock BIP Claims API is available from the Swagger page.

The primary purpose of the Mock BIP Claims API is to mock the end points that are used by the VRO application. Thus all the end-points listed in BIP Claims API API Calls section are implemented. The initial version of the api specification and model classes are generated using the Open API Generator using the Open API Specification of the BIP Claims API

npm install @openapitools/openapi-generator-cli -g 
npx @openapitools/openapi-generator-cli generate -i bipclaim_3.1.1.json -g spring -o code

The Open API Specification bipclaim_3.1.1.json is available from the Swagger page by clicking on the small /v3/api-docs link under the title.

The initial version of the api specification has been changed very little. The model classes has been updated primarily to use Lombok instead of verbose getters and setters.

Future Work

The plan was to merge the model classes with the VRO proper model classes. But since the mock has been developed late, we abandoned the idea to reduce risk.

Security Requirements

This mock implements a JWT based security configuration. At this time not all the claims are checked. However signature is validated in a JWT Request Filter.

A JWT generator is included together with an interface to specify claims. This interface is implemented in this class whose property values is read from application.yml mock-bip-claims-api.jwt setting.

For testing purpose you can update the application-test.yml with development, prod or production JWT claim values and run a test such as Claims Test and JWT will be available in the logs. In principle you can use that JWT in curl or other tools to make API calls if you specify the certificates as well.

Future Work

The JWT generator implementation is mainly used in unit tests. It could be merged with the VRO implementation since it is a bit cleaner and more modular.

Test Cases

This mock uses a simple Map store to hold all the Mock Claims. This Claim Store is initialized as a bean in Application Configuration. It reads all the Mock Claims from a json file. If you need new test cases you can add to this json file. The mock server does not watch the file updates so you will need to recompile and deploy.

Updates

To simplify to get insight into the state of claim objects an Updates Store has been created. This store is again initialized as a bean in Application Configuration and keeps track of calls to update contentions and lifecycle statuses per claim.

The controller for PUT /claims/{claimId}/contentions directly updates the state for contentions per claim and the controller for PUT /claims/{claimId}/lifecycle_status directly updates the state for lifecycle statuses per claim. The states are stored in a simple Set object that holds the updated claim ids.

To make the states accessible to End to End Tests which are black-box tests that run outside of the docker compose, this mock server provides two end-points

• GET /updates/{claimId}/contentions
• GET /updates/{claimId}/lifecycle_status

These end-points return a simple json objects of type ContentionUpdatesResponse and LifecycleUpdatesResponse. Both types provides a boolean property found which can be used to check if updates to contentions or lifecycle statuses per claim has happened. Contentions and Lifecycle status objects are also provided if found is true.

The updates are stored in a simple Set for claim ids. There are two consequences for this

• Same claim ids should not be used for multiple End to End Tests
• During local development if you run an End to End Test without deployment multiple times, you might get false positives

To remedy the first issue, End to End Tests include a self-check test to make sure the same claim id is not used by multiple tests. The second issue is remedied by a DELETE /updates/{claimId} end point which resets the update flags per claim id. This end point is called during the start of each End to End Test.

As with the actual mock end-points, updates end-points are available to End to End Tests and to local development through http port 8099.