Mock BIP Claim Evidence API - department-of-veterans-affairs/abd-vro GitHub Wiki

The BIP APIs are not available outside of VA firewall for local development. There is a UAT BIP Claim Evidence 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 Claim Evidence API has been developed. This mock server was instrumental both testing of mTLS functionality and upload functionality. It is also now an integral part of the End to End Tests.

HTTPS Server

Mock Claim Evidence 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 the application.yml server.ssl property to set up an https port 8094.

Note that if you generate a new set of self-signed certificates using build-certificates.sh and change it in Mock BIP Claim Evidence API, the corresponding certificates in Application and Mock BIP Claims 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 of the primary use of the Mock Claim Evidence API server 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 8096 is made available. The full set of end-points are available through this port.

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

Open API Specification

Mock BIP Claim Evidence API mocks the BIP Claim Evidence API end points that are used by the VRO application. These end-points are listed in BIP Claim Evidence API API Calls section and and also defined in Mock BIP Claim Evidence API specification. In fact the initial version of the api specification is generated using the Open API Generator

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

The Open API Specification claimevidence_1.1.1_openapi.json is available from the BIP Claim Evidence API 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 for the end-points used by the VRO.

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.properties mock-bip-ce-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 Files 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.

Storage

This mock uses a simple Map based store to hold the file content and meta data from request and UUID from response. This Basic Store is initialized as a bean in Application Configuration.

Received Files

To simplify to get access to the generated files from End to End Tests which are black-box tests that run outside of the docker compose, this mock server provides an additional end-point GET /received-files/{fileNumber} to download the generated files.

Note that the storage Map uses Filenumber as a key so if you call the /files twice, the previous file will be overwritten.