|
1 | 1 | # Open Banking Credential Issuer API |
2 | 2 |
|
3 | | -Backend code for the Open Banking CRI |
| 3 | +A serverless AWS Lambda-based API service that provides Open Banking credential verification capabilities. This service enables secure integration with an Open Banking provider to verify user financial data for identity verification purposes. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +This API consists of: |
| 8 | +- **Public API Gateway**: External-facing endpoints for Open Banking interactions |
| 9 | +- **Private API Gateway**: Internal endpoints for system integration |
| 10 | +- **Lambda Functions**: Serverless compute for processing Open Banking requests |
| 11 | +- **CloudWatch Monitoring**: Comprehensive logging and alerting |
| 12 | +- **Canary Deployments**: Safe deployment strategies with automatic rollback |
| 13 | + |
| 14 | +## Prerequisites |
| 15 | + |
| 16 | +- Node.js (version specified in `.nvmrc`) |
| 17 | +- AWS CLI configured with appropriate permissions |
| 18 | +- AWS Vault for credential management |
| 19 | +- SAM CLI for local development and deployment |
| 20 | + |
| 21 | +See the Lime onboarding guide for detailed setup instructions. |
| 22 | + |
| 23 | +## Quick Start |
| 24 | + |
| 25 | +### Installation |
| 26 | + |
| 27 | +#### Use correct Node.js version |
| 28 | +`nvm use` |
| 29 | + |
| 30 | +##### Install dependencies |
| 31 | +`npm install` |
| 32 | + |
| 33 | +### Build |
| 34 | +`npm run build` |
| 35 | + |
| 36 | +### Testing |
| 37 | + |
| 38 | +### Run all tests |
| 39 | +`npm test` |
| 40 | + |
| 41 | +### Run with coverage |
| 42 | +`npm run test:coverage` |
| 43 | + |
| 44 | +Coverage reports are generated in coverage/ directory. |
| 45 | + |
| 46 | +## Code Quality |
| 47 | + |
| 48 | +### Linting |
| 49 | + |
| 50 | +`npm run lint` |
| 51 | +`npm run lint:fix` |
| 52 | + |
| 53 | +### Formatting |
| 54 | +`npm run format` |
| 55 | +`npm run format:fix` |
| 56 | + |
| 57 | +## Local Development |
| 58 | + |
| 59 | +The project uses Vite for building and Vitest for testing. All source code is in TypeScript and follows ESLint configuration with Prettier formatting. |
| 60 | + |
| 61 | +### Deployment into Development environment |
| 62 | + |
| 63 | +`aws-vault exec ob-dev -- ./deploy.sh ipv-cri-ob-api-MyUsernameOrTicketNumber` |
| 64 | + |
| 65 | +## Canaries |
| 66 | + |
| 67 | +When deploying using sam deploy, canary deployment strategy will be used which is set in LambdaDeploymentPreference in template.yaml file. |
| 68 | + |
| 69 | +When deploying using the pipeline, canary deployment strategy set in the pipeline will be used and override the default set in template.yaml. |
| 70 | + |
| 71 | +Canary deployments will cause a rollback if any canary alarms associated with a lambda are triggered. |
| 72 | + |
| 73 | +To skip canaries such as when releasing urgent changes to production, set the last commit message to contain either of these phrases: [skip canary], [canary skip], or [no canary] as specified in the [Canary Escape Hatch guide](https://govukverify.atlassian.net/wiki/spaces/PLAT/pages/3836051600/Rollback+Recovery+Guidance#Escape-Hatch%3A-how-to-skip-canary-deployments-when-needed). |
| 74 | +`git commit -m "some message [skip canary]"` |
| 75 | + |
| 76 | +Note: To update LambdaDeploymentPreference, update the LambdaCanaryDeployment pipeline parameter in the [identity-common-infra repository](https://github.com/govuk-one-login/identity-common-infra/tree/main/terraform/lime/passport). To update the LambdaDeploymentPreference for a stack in dev using sam deploy, parameter override needs to be set in the [deploy script](./deploy.sh). |
| 77 | +`--parameter-overrides LambdaDeploymentPreference=<define-strategy> \` |
| 78 | + |
| 79 | + |
| 80 | +## Parameter prefix |
| 81 | + |
| 82 | +This allows a deploying stack to use parameters of another stack. |
| 83 | +Created to enable pre-merge integration tests to use the parameters of the pipeline stack. |
| 84 | + |
| 85 | +ParameterPrefix if set, this value is used in place of AWS::Stackname for parameter store paths. |
| 86 | +- Default is "none", which will use AWS::StackName as the prefix. |
| 87 | + |
| 88 | +Can also be used with the following limitations in development. |
| 89 | +- Existing stack needs to have all the parameters needed for the stack with the prefix enabled. |
| 90 | +- Existing stack parameters values if changed will trigger behaviour changes in the stack with the prefix enabled. |
| 91 | +- Existing stack if deleted will cause errors in the deployed stack. |
| 92 | + |
| 93 | + |
| 94 | +## Quality Gate Tags |
| 95 | + |
| 96 | +All API tests should be tagged with `@QualityGateIntegrationTest`. If a test runs in our pipelines (ie in Build), and tests live features, we should tag them with `@QualityGateRegressionTest`. |
| 97 | +If the test is for an in-development feature, we should tag it with `@QualityGateNewFeatureTest`. |
| 98 | +Tests that run in build and staging environments to verify essential functionality should be tagged with`@QualityGateSmokeTest`. |
| 99 | +Infrastructure and stack validation tests should be tagged with `@QualityGateStackTest`. |
| 100 | + |
| 101 | +Once a feature goes live, `@QualityGateNewFeatureTest` tags need to be updated to `@QualityGateRegressionTest`. |
| 102 | +To facilitate this update, API tests for in-development work should be placed in their own feature files, if possible, so the tests can be tagged at the Feature level rather than the Scenario level. |
| 103 | +Ideally, tests tagged with `@QualityGateNewFeatureTest` should be marked with a TODO and reference a post-go-live clean-up ticket so they can be easily identified and updated. |
| 104 | + |
0 commit comments