consumerdataright / mock-data-recipient

A mock version of a Consumer Data Right Data Recipient Software Product that can be used in the development and testing of CDR solutions

Consumer Data Right - Mock Data Recipient

This project includes source code, documentation and instructions for a Consumer Data Right (CDR) Mock Data Recipient.

This repository contains a mock implementation of a Data Recipient and is offered to help the community in the development and testing of their CDR solutions.

Mock Data Recipient - Alignment

The Mock Data Recipient in this release:

• aligns to v1.27.0 of the Consumer Data Standards;
• can connect to and complete authentication against both FAPI 1.0 Migration Phase 2 and Phase 3 compliant data holders.

Getting Started

The Mock Data Recipient uses the Mock Register and the Banking and Energy Mock Data Holders. You can swap out any of the Mock Data Holders, Mock Data Register and Mock Data Recipient solutions with a solution of your own.

There are a number of ways that the artefacts within this project can be used:

1. Build and deploy the source code
2. Use the pre-built image
3. Use the docker compose file to run a multi-container mock CDR Ecosystem

Build and deploy the source code

To get started, clone the source code.

git clone https://github.com/ConsumerDataRight/mock-data-recipient.git

Set your debug profile to CDR.DataRecipient.Web

To get help on launching and debugging the solution, see the help guide.

If you would like to contribute features or fixes back to the Mock Data Recipient repository, consult the contributing guidelines.

Use the pre-built image

A version of the Mock Data Recipient is built into a single Docker image that is made available via docker hub.

Pull the latest image

docker pull consumerdataright/mock-data-recipient

To get help on launching and debugging the solutions as containers and switching out your solution(s), see the help guide.

Certificate Management

Consult the Certificate Management documentation for more information about how certificates are used for the Mock Data Recipient.

Use the docker compose file to run a multi-container mock CDR Ecosystem

The docker compose file can be used to run multiple containers from the Mock CDR Ecosystem.

Note: the docker compose file utilises the Microsoft SQL Server Image from Docker Hub. The Microsoft EULA for the Microsoft SQL Server Image must be accepted to use the docker compose file. See the Microsoft SQL Server Image on Docker Hub for more information.

To get help on launching and debugging the solutions as containers and switching out your solution(s), see the help guide.

Mock Data Recipient - Architecture

The following diagram outlines the high level architecture of the Mock Data Recipient:

Dynamic Client Registration Interface:

Mock Data Recipient - Components

The Mock Data Recipient contains the following components:

• Website & API
  • Hosted at https://localhost:9001
  • Contains the user interface for testing a variety of interactions with participants, including:
    • Get Data Holder Brands
    • Get SSA
    • Dynamic Client Registration
    • Consumer Data Sharing
    • OIDC Authentication can be enabled in appsettings by including the issuer details.
    • Pushed Authorisation Request (PAR). Supports FAPI 1.0 Migration Phase 3
  • Also contains the JWKS and CDR Arrangement Revocation endpoints.
• SDK
  • Used internally within the Mock Data Recipient to simplify interactions with the Register and Data Holders.
• Azure Functions
  • Azure Functions that can automate the continuous Get Data Holders discovery and Dynamic Client Registration process.
  • For each Data Holder retrieved from the Register, a message will be added to the DynamicClietnRegistration queue. A function listening to the queue, will pick up the message and attempt to register the Data Recipient with the Data Holder.
  • To get help on the Azure Functions, see the help guide.
• Repository
  • A SQL repository is included that contains local data used within the Mock Data Recipient.
  • Includes the following collections:
    • data-holder-brands - populated when a response is received from the Register's Get Data Holder Brands API.
    • client-registrations - populated when a response is received from a successful DCR request to a Data Holder.
    • cdr-arrangements - populated after a successful consent and authorisation flow with a Data Holder.

Technology Stack

The following technologies have been used to build the Mock Data Recipient:

• The source code has been written in C# using the .Net 6 framework.
• The Repository utilises a SQL instance.

Testing

The Mock Data Recipient has been built as a test harness to demonstrate the interactions between the Register and Data Holders. The Mock Data Recipient allows the end user to test the various interactions by changing input values, executing and viewing the response. The Mock Data Recipient requires a Mock Register and a Banking and Energy Mock Data Holder to completely mimic the CDR Ecosystem. You can swap out any of the Mock Data Holders, Mock Data Register and Mock Data Recipient solutions with a solution of your own.

Consents and Authorisation flow of FAPI 1.0 Migration Phase 1 is no longer supported. Use the Pushed Authorisation Request (PAR) flow when testing against data holders that have implemented FAPI 1.0 Migration Phase 2 or Phase 3.

Contribute

We encourage contributions from the community. See our contributing guidelines.

Code of Conduct

This project has adopted the Contributor Covenant. For more information see the code of conduct.

Security Policy

See our security policy for information on security controls, reporting a vulnerability and supported versions.

License

MIT License

Notes

The Mock Data Recipient is provided as a development tool only. It conforms to the Consumer Data Standards.

mock-data-recipient's Issues

Mock-Data-Recipient from Ecosystem Compose crashes immediately after starting.

Describe the bug
When running the Mock CDR ecosystem using the provided docker-compose file, the mock-data-recipient image repeatedly starts and crashes, and is not accessible on port 9001.

To Reproduce
Steps to reproduce the behaviour:

1. I am running the containers on a Linux x86_64 machine.
2. Pull the docker-compose file linked above onto your machine.
3. Add the needed hosts into the host file; mock-register, mock-data-holder, mock-data-holder-energy and mock-data-recipient should all resolve to the equivalent of IPv4 localhost.
4. Spin up the docker images using docker-compose up -d.
5. Let them run for a minute or 2 to get started.
6. Inspect the logs of the recipient image; docker logs mock-data-recipient
7. If error has occurred, log lines like those shown below will be shown over and over again.

CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
INFO supervisord started with pid 1
INFO spawned: 'CDR.DataRecipient.Web' with pid 7
INFO success: CDR.DataRecipient.Web entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
INFO exited: CDR.DataRecipient.Web (exit status 1; not expected)
INFO spawned: 'CDR.DataRecipient.Web' with pid 24
INFO success: CDR.DataRecipient.Web entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
INFO exited: CDR.DataRecipient.Web (exit status 1; not expected)
INFO spawned: 'CDR.DataRecipient.Web' with pid 41
INFO success: CDR.DataRecipient.Web entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
INFO exited: CDR.DataRecipient.Web (exit status 1; not expected)

Expected behaviour
My expectation was that the service CDR.DataRecipient.Web would start and stay up, and would be openable in browser at an address like https://localhost:9001/, and should load a page similar to the one in the screenshot at the bottom of the HELP.md file.

DCR request contains string instead of array for redirect_uris and response_types fields

Describe the bug
When DR makes a DCR request, it sends a string instead of an array for redirect_uris and response_types fields, for example:

{
  ...
  "redirect_uris": "https://dr.cdrsandbox.gov.au/consent/callback",
  "grant_types": [
    "client_credentials",
    "authorization_code",
    "refresh_token"
  ],
  "response_types": "code id_token",
  ...
}

To Reproduce
Run DR and use Client registration option.

Expected behaviour
Even if redirect_uris / response_types contains a single string, it should send it as one element array as per RFC spec: https://www.rfc-editor.org/rfc/rfc7591.html, for example:

{
  ...
  "redirect_uris": [
    "https://dr.cdrsandbox.gov.au/consent/callback"
  ],
  "response_types": [
    "code id_token"
  ]
  ...
}

Screenshots
n/a

Additional context
This issue was spotted when using https://dr.cdrsandbox.gov.au/

Consumer Data Sharing not running in browser

Describe the bug
Unable to retrieve data via Consumer Data Sharing on banking resource api’s that have valid consents.
(Ie the /data-sharing/proxy) injection is not working in browser.

However successfully hit the mock data holder endpoint using mtls and access tokens via postman on get banking/accounts.

To Reproduce
Steps to reproduce the behavior:

1. Successfully pulled and composed docker container with all three mocks as per default config and data
2. Successfully navigated to mock adr url and performed the below actions
3. Successfully executed Discovered Data Holders
4. Successfully executed DCR
5. Successfully created consent
6. Successfully refreshed tokens
7. Attempted get banking/accounts from Consumer Data Sharing after selecting the created arrangement
8. Error message within swagger execute page
9. Failed to fetch, refer screenshot

Expected behaviour
Data should be retrieved for get accounts and shown as a valid response on the page

Screenshots
If applicable, add screenshots

to help explain your problem.

Additional context
Add any other context about the problem here.

Data Sharing is not displaying the Banking API swagger

Describe the bug
Data sharing swagger is not displaying on the data sharing page.

To Reproduce
Steps to reproduce the behaviour:

1. Complete Dynamic Client Registration steps
2. Complete Consents and Authorisation steps
3. Open Data Sharing page
4. Error occurs

Expected behaviour
Banking swagger should display allowing user to make requests against a banking data holder.

Mistaken Issue

The current path should be <RecipientBaseUri>/arrangements/revoke(#security-endpoints)

Whilst the mock-data-recipient is using /revocation which aligns with what was defined in the SSA. But according to #443, revocation_uri in SSA is now literally deprecated.

"IndustryName" validation causing proxy to discovery endpoints failed

Currently the data recipient's proxy controller expects something like /cds-au/v1/common/status('common' as the industry name), but it should be /cds-au/v1/discovery/status.

mock data recipient's client certificate expired today (15/06/2023)

PKCE support

Is your feature request related to a problem? Please describe.

PKCE support is marked as mandatory after the 16th of September:
ConsumerDataStandardsAustralia/standards#209

Describe the solution you'd like
Data recipient should support PKCE: https://www.rfc-editor.org/rfc/rfc7636.html

Describe alternatives you've considered

Additional context

redirect_uris and response_types in DCR request should be array of string

Describe the bug
redirect_uris and response_types in DCR request should be array of string but a single string value is passed from mock data recipient.
Sample DCR request from mock data recipient:

{
    // ...
    "authorization_signed_response_alg": "PS256",
    "authorization_encrypted_response_alg": "",
    "authorization_encrypted_response_enc": "",
    // expect string array here but got string
    "redirect_uris": "https://host.docker.internal:9001/consent/callback",
    "grant_types": [
        "client_credentials",
        "authorization_code",
        "refresh_token"
    ],
    // expect string array here but got string
    "response_types": "code id_token",
    "exp": 1681966415,
    "iss": "c6327f87-687a-4369-99a4-eaacd3bb8210",
    "aud": "https://localhost:7132"
}

The address property in the userinfo endpoint should be an object instead of a string

Describe the bug
When calling the userinfo endpoint with the address scope, the mock-data-recipient expects a string for the address property while the openID connect specs expect a JSON object.
References:

• section 5.1 Standard Claims
• CDS Scopes and Claims requirements

To Reproduce
Steps to reproduce the behavior:

1. Register a data_holder and a user with its address parsed as an object
2. Call userinfo endpoint with the address scope
3. The mock data recipient returns a 500 error

Expected behaviour
The userinfo endpoint is supposed to return the userinfo data with the address as a JSON object instead of a string as per the openID specs. The address JSON object contains the following properties:

"address": {
    "formatted": "...",
    "street_address": "...",
    "locality": "...",
    "region": "...",
    "postal_code": "...",
    "country": "..."
}