Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sandbox Data Recipient - configurable certificate #8

Open
ikawalec opened this issue Sep 8, 2022 · 3 comments
Open

Sandbox Data Recipient - configurable certificate #8

ikawalec opened this issue Sep 8, 2022 · 3 comments
Labels

Comments

@ikawalec
Copy link

ikawalec commented Sep 8, 2022

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

Looking at the answer here: #7 (comment) it seems that if data recipient has the client certificate configurable (my understanding is that there is only one certificate embedded in the docker), then it should be possible to get a software statement for and register a client. Right now, only the first client succeeded to register and the remaining ones are failing.

Describe the solution you'd like

Add a way to dynamically configure a client certificate.
It could be done via some settings in the data recipient UI.
With that feature, it should be really easy to test the authorization flows.
Right now, it seems that we only option to test data recipient with sandbox registry is to deploy it somewhere using a docker, that might be a difficult process.

Describe alternatives you've considered

Additional context

@Aiden-Ziegelaar
Copy link

I think this should only affect ADR clients from the context on #7. For data holders the same client certificate should be able to register with multiple DH, as has been illustrated with the registrations with both example DHs.

@ikawalec
Copy link
Author

I agree that we same certificate can be used to register with multiple DH.
Since the cert is embedded, it seems that every client is trying to register with the same software statement.

On the DH side we receive the following DCR request:

{
  "jti": "7d9d3377-08d3-49b7-afef-9804be3c056e",
  "iat": 1662992745,
  "token_endpoint_auth_signing_alg": "PS256",
  "token_endpoint_auth_method": "private_key_jwt",
  "application_type": "web",
  "id_token_signed_response_alg": "PS256",
  "id_token_encrypted_response_alg": "RSA-OAEP",
  "id_token_encrypted_response_enc": "A256GCM",
  "request_object_signing_alg": "PS256",
  "software_statement": "eyJhbGciOiJQUzI1NiIsImtpZCI6IkY0RUEyOTlDNjA3OTQ3RTQ1OUFDNDdFNjlGNzI4OUYxNzRCNUI0REYiLCJ0eXAiOiJKV1QifQ.ewogICJsZWdhbF9lbnRpdHlfaWQiOiAiMThiNzVhNzYtNTgyMS00YzllLWI0NjUtNDcwOTI5MWNmMGY0IiwKICAibGVnYWxfZW50aXR5X25hbWUiOiAiU2FuZGJveCBEYXRhIFJlY2lwaWVudCIsCiAgImlzcyI6ICJjZHItcmVnaXN0ZXIiLAogICJpYXQiOiAxNjYyOTkyNzQzLAogICJleHAiOiAxNjYyOTkzMzQzLAogICJqdGkiOiAiZTcxODRlMDY3NDY4NGQ1NTg2YjU0YzYxOGRmODlhZTYiLAogICJvcmdfaWQiOiAiZmZiMWM4YmEtMjc5ZS00NGQ4LTk2ZjAtMWJjMzRhNmI0MzZmIiwKICAib3JnX25hbWUiOiAiU2FuZGJveCBEYXRhIFJlY2lwaWVudCIsCiAgImNsaWVudF9uYW1lIjogIlNhbmRib3ggRGF0YSBSZWNpcGllbnQgU29mdHdhcmUgUHJvZHVjdCIsCiAgImNsaWVudF9kZXNjcmlwdGlvbiI6ICJBIHByb2R1Y3QgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgZWNvc3lzdGVtIiwKICAiY2xpZW50X3VyaSI6ICJodHRwczovL2RyLmNkcnNhbmRib3guZ292LmF1IiwKICAicmVkaXJlY3RfdXJpcyI6IFsKICAgICJodHRwczovL2RyLmNkcnNhbmRib3guZ292LmF1L2NvbnNlbnQvY2FsbGJhY2siCiAgXSwKICAibG9nb191cmkiOiAiaHR0cHM6Ly9jZHJzYW5kYm94Lmdvdi5hdS9sb2dvMTkyLnBuZyIsCiAgInRvc191cmkiOiAiaHR0cHM6Ly9kci5jZHJzYW5kYm94Lmdvdi5hdS90b3MiLAogICJwb2xpY3lfdXJpIjogImh0dHBzOi8vZHIuY2Ryc2FuZGJveC5nb3YuYXUvcG9saWN5IiwKICAiandrc191cmkiOiAiaHR0cHM6Ly9kci5jZHJzYW5kYm94Lmdvdi5hdS9qd2tzIiwKICAicmV2b2NhdGlvbl91cmkiOiAiaHR0cHM6Ly9kci5jZHJzYW5kYm94Lmdvdi5hdS9yZXZvY2F0aW9uIiwKICAicmVjaXBpZW50X2Jhc2VfdXJpIjogImh0dHBzOi8vZHIuY2Ryc2FuZGJveC5nb3YuYXUiLAogICJzb2Z0d2FyZV9pZCI6ICJjNjMyN2Y4Ny02ODdhLTQzNjktOTlhNC1lYWFjZDNiYjgyMTAiLAogICJzb2Z0d2FyZV9yb2xlcyI6ICJkYXRhLXJlY2lwaWVudC1zb2Z0d2FyZS1wcm9kdWN0IiwKICAic2NvcGUiOiAib3BlbmlkIHByb2ZpbGUgY29tbW9uOmN1c3RvbWVyLmJhc2ljOnJlYWQgY29tbW9uOmN1c3RvbWVyLmRldGFpbDpyZWFkIGJhbms6YWNjb3VudHMuYmFzaWM6cmVhZCBiYW5rOmFjY291bnRzLmRldGFpbDpyZWFkIGJhbms6dHJhbnNhY3Rpb25zOnJlYWQgYmFuazpyZWd1bGFyX3BheW1lbnRzOnJlYWQgYmFuazpwYXllZXM6cmVhZCBlbmVyZ3k6YWNjb3VudHMuYmFzaWM6cmVhZCBlbmVyZ3k6YWNjb3VudHMuZGV0YWlsOnJlYWQgZW5lcmd5OmFjY291bnRzLmNvbmNlc3Npb25zOnJlYWQgZW5lcmd5OmFjY291bnRzLnBheW1lbnRzY2hlZHVsZTpyZWFkIGVuZXJneTpiaWxsaW5nOnJlYWQgZW5lcmd5OmVsZWN0cmljaXR5LnNlcnZpY2Vwb2ludHMuYmFzaWM6cmVhZCBlbmVyZ3k6ZWxlY3RyaWNpdHkuc2VydmljZXBvaW50cy5kZXRhaWw6cmVhZCBlbmVyZ3k6ZWxlY3RyaWNpdHkuZGVyOnJlYWQgZW5lcmd5OmVsZWN0cmljaXR5LnVzYWdlOnJlYWQgY2RyOnJlZ2lzdHJhdGlvbiIKfQ.RsbV3kAXa2qi4rrl-ZfjdhZPgqRT0o8EyBJYM0B5IgP9887I4K8vSyGYujBJB3lo_mb-DyZtPgVUuzKMalc7_KsWrDLHviCi9uNQa1-yflidzv5aF13zso3yQxrTqytyezHnse8Ye69gh_hustMexbLgCzxBfOOjiVIvtBR5rm57xYBag_16HwmplMrY5yB3eOokihTdxYpg6Okl8MSNAoDgChYP5Or7dyhwfe82mJ0_ZyNVlBc8RSo5xkxfIR78a-lNFwafHdnKm7okOgIr-HF20_bCvlq1ZS1X4uuZZkmUkdLeXybIMs2_pPje-vNQiR1AUDE70mMwf7D3SWzPzQ",
  "redirect_uris": "https://dr.cdrsandbox.gov.au/consent/callback",
  "grant_types": [
    "client_credentials",
    "authorization_code",
    "refresh_token"
  ],
  "response_types": "code id_token",
  "exp": 1662993045,
  "iss": "c6327f87-687a-4369-99a4-eaacd3bb8210",
  "aud": "https://0dd7-185-108-70-201.eu.ngrok.io/default/cdr"
}

Software statement payload:

{
  "legal_entity_id": "18b75a76-5821-4c9e-b465-4709291cf0f4",
  "legal_entity_name": "Sandbox Data Recipient",
  "iss": "cdr-register",
  "iat": 1662992743,
  "exp": 1662993343,
  "jti": "e7184e0674684d5586b54c618df89ae6",
  "org_id": "ffb1c8ba-279e-44d8-96f0-1bc34a6b436f",
  "org_name": "Sandbox Data Recipient",
  "client_name": "Sandbox Data Recipient Software Product",
  "client_description": "A product to interact with the ecosystem",
  "client_uri": "https://dr.cdrsandbox.gov.au/",
  "redirect_uris": [
    "https://dr.cdrsandbox.gov.au/consent/callback"
  ],
  "logo_uri": "https://cdrsandbox.gov.au/logo192.png",
  "tos_uri": "https://dr.cdrsandbox.gov.au/tos",
  "policy_uri": "https://dr.cdrsandbox.gov.au/policy",
  "jwks_uri": "https://dr.cdrsandbox.gov.au/jwks",
  "revocation_uri": "https://dr.cdrsandbox.gov.au/revocation",
  "recipient_base_uri": "https://dr.cdrsandbox.gov.au/",
  "software_id": "c6327f87-687a-4369-99a4-eaacd3bb8210",
  "software_roles": "data-recipient-software-product",
  "scope": "openid profile common:customer.basic:read common:customer.detail:read bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read bank:regular_payments:read bank:payees:read energy:accounts.basic:read energy:accounts.detail:read energy:accounts.concessions:read energy:accounts.paymentschedule:read energy:billing:read energy:electricity.servicepoints.basic:read energy:electricity.servicepoints.detail:read energy:electricity.der:read energy:electricity.usage:read cdr:registration"
}

I've reported another issue here: https://github.com/ConsumerDataRight/mock-data-recipient that is causing DH to fail to register a client due to invalid format of redirect_uris / response_types.

@CDR-AndrewG
Copy link

Hi @ikawalec,

Thank you for highlighting the above issue. We have logged the issue and will include a fix in a future release.

Regarding configurable certificates for the Sandbox Data Recipient, it may not be possible to provide all functions through the use of one Sandbox Data Recipient. You are correct that multiple Data Recipients either hosted in the Sandbox or hosted by Sandbox Participants would be required. Those Data Recipients would be required to have their own register entries and client certificates.

We will look into this request further and add an item to our backlog. Our backlog is prioritised based on customer value and is reprioritised as new initiatives arise. As such, we cannot guarantee that this enhancement request will be fulfilled.

Something else worth looking into - It is possible to take the mock-data-recipient and replace the Client Certificate before building a new docker container or running in Visual Studio.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants