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.