Coder Social home page Coder Social logo

klg-docs's Introduction

KL Gateway

This repository serves as the technical issue tracker during the development phase of the KL Gateway project. Users of the KL Gateway project being the municipality patient journal vendors are encouraged to create an issue in this repo if a problem is encountered when sending information to the KL Gateway. For general documentation of the KL Gateway please visit https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2189361157/Care+Gateway

klg-docs's People

Contributors

curadevelopment avatar jvitrifork avatar ksoeren3 avatar mikaelkorsgaard avatar mira-novax avatar nigtrifork avatar ohetrifork avatar renesvendsen avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

klg-docs's Issues

Authorization error

Is something wrong with the authorizaotn server we are getting a strange error we haven't seen before.

 {"error":"server_error","error_description":"Organization Id Lookup failed"}

Fails in test and my unit tests.

Update: logs are saying error has been since Thursday. Everything ran fin Wednesday we have had no changes.

@jkiddo

StatusCode: 500, ReasonPhrase: 'Internal Server Error', Version: 1.1, Content: System.Net.Http.HttpConnectionResponseContent, Headers:
{
  Cache-Control: no-store
  Date: Fri, 17 Jun 2022 11:49:26 GMT
  Pragma: no-cache
  Referrer-Policy: no-referrer
  Server: istio-envoy
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  x-b3-traceid: 312d8a07dec2d8d9894a0f3e0760893d
  X-Content-Type-Options: nosniff
  x-envoy-upstream-service-time: 82
  X-Frame-Options: SAMEORIGIN
  X-Request-ID: 2741ef8a-74da-92e4-94c7-9a9f225cacb5
  X-XSS-Protection: 1; mode=block
  Connection: keep-alive
  Content-Type: application/json
  Content-Length: 76
}

Model Issues: This property must be an Array, not an Object

I have a large number of unit tests which I use to test my mapping of objects. They are all failing. These tests all worked against the previous post endpoint since June 2021.

All the reports that we have been testing with over the last five months we are talking about thousands of reports that previously were sent to the gateway with no issues. are now also failing.

Lets have a look at a report. Again this bundle was previously sent with no issues to the Post Endpoint we have been using since June 2021 to test.

bundle.json

The first thing to note in the large number of errors returned. But lets just look at this one since it seams to be a treading theme across the errors. This property must be an Array, not an Object

     {
            "severity": "error",
            "code": "processing",
            "diagnostics": "This property must be an Array, not an Object",
            "location": [
                "Bundle.entry[0].resource.category",
                "Line 32, Col 22"
            ]
        },

Line 32 is coding

    "category": {
         "coding": [
           {
             "system": "http://terminology.hl7.org/CodeSystem/condition-category",
             "code": "problem-list-item"
           }
         ]
       },

Theses tests all use the documented model found here KLGateway as well as the samples found here Downloads

If we look at the file entitled Condition-ProblemerMedPersonligPleje.json

You will notice that it looks exactly the same.

 "category": {
    "coding": [
      {
         "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "problem-list-item"
      }
    ]
  },

This makes me wonder why I am getting a This property must be an Array, not an Object message.

I decided to try and see what would happen if I changed it from an object to an array and see what happens.

    "category": [
           {
             "system": "http://terminology.hl7.org/CodeSystem/condition-category",
             "code": "problem-list-item"
           }
         ]        ,

This results in two errors

  {
            "severity": "error",
            "code": "processing",
            "diagnostics": "Unrecognised property '@system'",
            "location": [
                "Bundle.entry[0].resource.category[0]",
                "Line 33, Col 84"
            ]
        },
        {
            "severity": "error",
            "code": "processing",
            "diagnostics": "Unrecognised property '@code'",
            "location": [
                "Bundle.entry[0].resource.category[0]",
                "Line 35, Col 14"
            ]
        },

So not only is category no longer an object and it is now an array but system and code are not valid for category.

  • It took us months to test the model as it is.
  • Can someone explain to me why the model has changed?
  • What changes exactly where made?
  • This appears to be a treading theme. If the model was changed this can be considered again Breaking changes. Why were we not informed that it had been changed?

update

Still trying to debug this If we check the Care Gateway page which was given to use a few weeks ago you will notice that.

 "category": {
    "coding": [
      {
         "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "problem-list-item"
      }
    ]
  },

Appears to be gone.

If we check Resource Profile: CareCondition it appears to still be required

image

kombit serviceaftale

Hej jeg har oprettet serviceaftale som kombit er ved at kigge på. TIl det spørger de følgende:

Hvorfor er det KOMBIT I tester den med?
Hvorfor er det med videregivelse af data?
Hvem fra KOMBIT kender til denne testopstilling?

Er det noget i kan give svar til?

PlannedIntervention.Status, PlannedIntervention.ActivityStatus

I PlannedIntervention skal vi indberette hhv. "indsatsstatus" og "indsatsAktivitetsstatus". Vi har læst beskrivelserne, men vi er statig i tvivl om, hvordan de adskiller sig. Eksemplerne viser kun "active" og "completed" for "indsatsstatus", imens alle eksempler med "indsatsAktivitetsstatus" viser "in-progress".

Vil I uddybe (evt. ved hjælp af eksempler), hvordan vi skelner mellem de to statusser?

Access denied by rule: ManagingOrganization is not contained in JWT sor claim

We are getting the response
"resourceType": "OperationOutcome",
"issue": [ {
"severity": "error",
"code": "processing",
"diagnostics": "Access denied by rule: ManagingOrganization is not contained in JWT sor claim"

when trying to send citizen information to the gateway-test

I don't see anything about ManagingOrganization in the documentation. What are we missing?

How to request a client id for KL gateway authorization.

In an attempt to keep things organized I thought it would be a good idea to create a new issue dedicated to the keys and credentials that are needed to connect and how to apply for them.

My current understanding is that KLG needs a public key from each kommune in order for us to apply for a KLG client id. Again one for each kommune is needed.

The public key is created from the P12 certificate file using the password for the file to extract.

We need information on where and how to apply for these p12 certificates.

  • Do we contact Kombit STS? If so do you have contact information?
  • Do we need to contact each kommune and ask them to contact Kombit STS. If so do you have contact information and what they should ask for?

We are under a deadline hear and need to get this working ASAP.

A certificate is either invalid or has been revoked

Does this error mean anything to anyone? It seams our certs where revoked from service platform. Is this something anyone has seen before.

{"Code":400,"Message":"A certificate is either invalid or has been revoked or an error has happened during the validation process. Status code:System.Net.WebException: The remote name could not be resolved: 'crl.ica04.trust2408.com'\r\n at System.Net.HttpWebRequest.GetResponse()\r\n at org.openoces.ooapi.utils.HttpClient.ReadBytesFromUri(Uri uri)\r\n at org.openoces.ooapi.validation.HttpCrlDownloader.Download(String location)\r\n at org.openoces.ooapi.validation.ItemCache1.DownloadItemAndUpdateCache(String key, Func1 download)\r\n at org.openoces.ooapi.validation.CachedHttpCrlDownloader.DownloadNewCrl(String location, CrlCache crlCache)\r\n at org.openoces.ooapi.validation.LocalFileAndCachedHttpCrlDownloader.FromCacheOrFallback(String location, CrlCache crlCache, String filePath)\r\n at org.openoces.ooapi.validation.CachedHttpCrlDownloader.Download(String location)\r\n at org.openoces.ooapi.validation.FullCrlOfflineRevocationChecker.DownloadCrl(String crlDistributionPoint)\r\n at org.openoces.ooapi.validation.FullCrlOfflineRevocationChecker.IsRevoked(IOcesCertificate certificate)\r\n at Safewhere.IdentityProviderModel.OcesCertificateValidator.Validate(X509Certificate2 certificate)"}

Serviceplatformen dynamic routing information

In order to successfully upload files onto ext-test of serviceplatformen we need to have a trigger file with specific information, however currently there is no single source of truth on the matter and as such we don't really know what to include in the individual fields thus the following questions NEED to be clarified:

  1. Which SENDER do we need to use?
    • What to put in the <Sender> </Sender> field
  2. What SYSTEM do we need to use and what is the ID of said system?
    • What to put in the <SenderIt-system> </SenderIt-System field
  3. What is the SENDER AUTHORITY that we're supposed to use?
    • What to put in the <SenderAuthority> </SenderAuthority>
  4. What is the RECIPIENT AUTHORITY that we're supposed to use?
    • What to put in the <RecipientAuthority> </RecipientAuthority>

Here's an example of the XML that we currently send:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:Trigger xmlns:ns2="http://serviceplatformen.dk/xml/wsdl/soap11/SFTP/1/types">
    <FileDescriptor>
        <FileName>test_data_1_2022-02-10.xml</FileName>
        <SizeInBytes>36</SizeInBytes>
        <Sender>FUT-Gateway</Sender>
        <Recipients>ROUTING_V1_0_0</Recipients>
    </FileDescriptor>
    <FileContentDescriptor>
        <SFTPDynamicRoutingInfo>
            <InfRef>Omsorgsdata_1</InfRef>
            <SenderIt-system>aff4e7d5-e35f-4021-b99f-e34593a678ff</SenderIt-system>
            <SenderAuthority>urn:oio:cvr-nr:19435075</SenderAuthority>
            <TransactionId>4a112a7d-1f6f-43ef-a364-7169bc5cb4d5</TransactionId>
            <SenderTimestamp>2022-02-10T13:46:37.632+01:00</SenderTimestamp>
            <RecipientAuthority>urn:oio:cvr-nr:19435075</RecipientAuthority>
        </SFTPDynamicRoutingInfo>
    </FileContentDescriptor>
</ns2:Trigger>

However, this produces:

<ns2:TechnicalReceipt xmlns:ns2="http://serviceplatformen.dk/xml/wsdl/soap11/SFTP/1/types">
    <FileTransferUUID>1ab09ad0-1eff-4eca-a99d-472c54e8c829</FileTransferUUID>
    <ErrorMessage>
        <ErrorCode>64</ErrorCode>
        <ErrorCodeDescription>RejectedNoSFTPForSendingItSystemFound</ErrorCodeDescription>
        <ErrorDescription>Error occurred while process trigger file. Contact Serviceplatformen Helpdesk. Transaction uuid: 1ab09ad0-1eff-4eca-a99d-472c54e8c829.</ErrorDescription>
    </ErrorMessage>
</ns2:TechnicalReceipt>

Error messages without help

I have a large number of errors in my bundles due to model changes. I am having a hard time tracking down what the issues are as they are not displaying any line number or any information about where the issue is.

 {
      "severity": "error",
      "code": "processing",
      "diagnostics": "Array cannot be empty - the property should not be present if it has no values"
    },

The old system was quite helpful telling us which section of the bundle was causing the problem can we have that information back please.

Using JWTs in token exchange instead of SAML assertion

I was wondering whether is is possible to use JWTs instead of SAML assertions to get the gateway access token?

I believe that using SAML assertions could be an issue for companies not using software which doesn't directly support working with SAML such as .NET Core. Examples on Kombit website are using .NET Framework 4.8.2 with WCF, support for which does not exist in .NET Core.

Kombit with Serviceplatformen added support for fetching Bearer tokens in 2023 - Section - Adgangsstyring for webservices - Ny version af Security Token Service (https://digitaliseringskataloget.dk/l%C3%B8sninger/adgangsstyring-systemer)
Would it be possible to add support to use those tokens in token exchange?

I believe request would look similarly:

POST: https://saml.test001.ehealth.sundhed.dk/auth/realms/ehealth/protocol/openid-connect/token
Headers: 
    Content-Type=application/x-www-form-urlencoded
Body: 
    client_id=eoj
    client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
    client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCIgOiAicn...
    grant_type=urn:ietf:params:oauth:grant-type:token-exchange
    subject_issuer=kombit-sts
    subject_token_type=urn:ietf:params:oauth:token-type:access_token
    subject_token=eyJhbGciOiJSUzI1NiIsImtpZCIgOiAicn... // token from Kombit STS

Is this approach with JWTs something that would be considered?

AccessToken reuse - fishing for advice.

In my experience access tokens are normally good for 3600 seconds or one hour. If we then take into account clock skew i normally use them for 55 minutes and then refresh them.

The access tokens we are getting from sundhed.dk authorization server are only good for 500 seconds or 8 minutes give or take.

If we then take into account clock skew we can only use an access token for three minutes before refreshing it?

Or do you know something I dont?

Refresh tokens appear to be good for 30 minutes so this at least is a little better.

Duplicate

What exactly triggers a duplicate? Is it bundle id across everything? or is it effected by date, or by sor?

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "processing",
      "diagnostics": "DUPLICATE_ENTITY: Entity with id 'Bundle/A7AA9FAF-0F4B-4F5B-ADE7-43065769DC87' already exists"
    }
  ]
}

Missing constraint and examples

As stated by Torben:

Jeg er ikke længere på projektet men svarer lige med den intension der ligger bag :-)

Eftersom intervention og activity.detail er 1..1 vil det være oplagt at status på disse sættes til det samme. Hvis du kigger på definition for de to felter vil du også se at beskrivelserne er identiske. Felterne skal begge være der fordi de er påkrævede i FHIR ressourcen. (... og ja det kunne godt have været gjort i eksemplerne og evt. sat på som en constraint :-| )

Originally posted by @hagensen-software in #28 (comment)

How to gerneate a Subject_token

SAML Assertion to JWT Exchange

States that requests for an access token and a refresh token need to contain

  • subject_issuer: The ID of the subject token issuer e.g. kombit-sts.
  • subject_token_type: Always urn:ietf:params:oauth:token-type:saml2.
  • subject_token: The Base64url encoded SAML Assertion issued by subject_issuer

There no information on the above page with regards to how to create a subject_token.

soap web service

Apparently the subject_token must be requested from a web service. adgangsstyring-systemer

The documented web service end point found here does not work

https://adgangsstyring.eksterntest-stoettesystemerne.dk/runtime/services/trust/14/certificatemixed

It returns a 404.

other links

Saml Trust certifcates

CarePlan - level3 koder

Vi har tidligere fået afklaret på Zulip, at der skal oprettes nye instanser af CarePlan for hver level3 kode, fordi modellen kun kan indeholde én level3 kode i hver CarePlan instans (https://chat.fhir.org/#narrow/stream/274483-denmark.2Fkl.2Fprofile.2Fkl-gateway/topic/Multiple.20level.203.20interventions)

Men vi har et par spørgsmål til, hvordan level3 koderne skal håndteres i indberetningen.

  • Hvis en level3 kode registreres senere end level2 koden og vi indsender en ny instans af CarePlan med level 3 koden og den tilhørende level2 kode, hvilket tidspunkt forventer I så at modtage i period.start for den nye instans? Er det samme tidspunkt som for level2 koden, fordi det tilsvarer tidspunktet for, hvornår indsatsen er bevilget?

  • Hvis level3 koden afsluttes inden level2 koden (indsatsen) afsluttes, hvordan skal CarePlan instansen, hvor level3 koden er indeholdt, så opdateres?

  • Hvis der er registreret en level2 kode og en level3 kode på samme tid, så indsender vi altid to instanser af CarePlan: level2 koden i én instans (uden level3 koden) og level3 koden i en anden instans. Vi gør det for at have mulighed for at opdatere level3 kode instansen, uden at det påvirker level2 kode instansen, sådan at level2 kode instansen kan fortsætte, selvom level3 koden afsluttes. Stemmer det overens med det I forventer?

Condition - Encounter som en-til-mange relation

Modellen ser ikke ud til at supportere, at en condition kan have flere encounters (opfølgninger). Vi bruger extension (KLGatewayCareFollowUpEncounterExtension) via condition til at lave relationen mellem condition og encounter, men får nedenstående fejl, når en condition er relateret til flere (historiske) opfølgninger.

"
"severity": "error",
"code": "processing",
"diagnostics": "Condition.extension:followUpEncounter: max allowed = 1, but found 3 (from http://gateway.kl.dk/1.0/StructureDefinition/klgateway-care-condition)",
"location": [ "Bundle.entry[4].resource.ofType(Condition)", "Line 218, Col 21" ]
"

Er I kun interesseret I at få den seneste Encounter?

Welcome

Welcome to the issue management of KL Gateway

Issues with invalid endpoint. "The FHIR endpoint on this server does not know how to handle POST operation[Bundle]"

I think I have authorization working but when I try to send requests to the new endpoint. I am getting an error.

I was told that this is the new endpoint https://care-gateway.test001.ehealth.sundhed.dk/fhir I assume that the endpoint to post the bundle to would then be https://care-gateway.test001.ehealth.sundhed.dk/fhir/Bundle

If I don't send an access token I get the following, as I would expect since I am not authorized.

RBAC: access denied

Request attempt 1 (sanity check)

Sending to just the basic endpoint with an access token. results in an error as i am not sending an operation name that being bundle.

https://care-gateway.test001.ehealth.sundhed.dk/fhir

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "error",
            "code": "processing",
            "diagnostics": "This is the base URL of FHIR server. Unable to handle this request, as it does not contain a resource type or operation name."
        }
    ]
}

request attempt two

So i tried sending the request to the bundle endpoint.

https://care-gateway.test001.ehealth.sundhed.dk/fhir/Bundle

The error message i am getting confuses me. This is a Http post request with the json body of the bundle i am trying to post. This is the exact same post that i made to the old endpoint. Why would it be looking for Http parameters? The old endpoint supported ?_format=json&_pretty=true query parms but this endpoint doesn't appear to support them.

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "error",
            "code": "not-supported",
            "diagnostics": "Invalid request: The FHIR endpoint on this server does not know how to handle POST operation[Bundle] with parameters [[]]"
        }
    ]
}

update attempt 3

Tried adding the bundle Id. I am just guessing at this point I cant find anything about parameters for the Post request in the documentation Care Gateway

https://care-gateway.test001.ehealth.sundhed.dk/fhir/Bundle?id=TestReport

{ "resourceType": "OperationOutcome", "issue": [ { "severity": "error", "code": "not-supported", "diagnostics": "Invalid request: The FHIR endpoint on this server does not know how to handle POST operation[Bundle] with parameters [[id]]" } ] }

Post body sending for both requests is

{
  "resourceType": "Bundle",
  "id": "TestReport",
  "meta": {
    "profile": [
      http://gateway.kl.dk/1.0/StructureDefinition/klgateway-care-delivery-report
    ]
  },
  "type": "collection",
  "timestamp": "2021-05-31T12:03:24.280864+02:00",
  "entry": [
    {
      "fullUrl": "Patient/TestPatient001",
      "resource": {
        "resourceType": "Patient",
        "id": "TestPatient001",
        "meta": {
          "profile": [
            http://gateway.kl.dk/1.0/StructureDefinition/klgateway-care-citizen
          ]
        },
        "identifier": {
          "use": "official",
          "system": "urn:oid:1.2.208.176.1.2",
          "value": "0101010101"
        },
        "managingOrganization": {
          "identifier": {
            "use": "official",
            "system": "urn:oid:1.2.208.176.1.1",
            "value": "123456789012345"
          }
        }
      }
    },
    {
      "fullUrl": "Encounter/bfa70a76-318d-453d-9abc-76982f8d13ca",
      "resource": {
        "resourceType": "Encounter",
        "id": "bfa70a76-318d-453d-9abc-76982f8d13ca",
        "meta": {
          "profile": [
            http://gateway.kl.dk/1.0/StructureDefinition/klgateway-care-encounter
          ]
        },
        "status" :"planned",
        "subject": {
          "reference": "Patient/TestPatient001"
        },
        "period": {
          "start": "2021-05-31T12:03:24.2828042+02:00"
        },
        "class": {
          "system": http://terminology.hl7.org/CodeSystem/v3-ActCode,
          "code": "HH"
        },
        "type": [
          {
            "coding": [
              {
                "system": http://kl.dk/fhir/common/caresocial/CodeSystem/KLCommonCareSocialCodes,
                "code": "9f03dfbb-7a97-45a5-94db-d4c3501714a9"
              }
            ]
          }
        ],
        "performedDateTime": "0001-01-01T00:00:00"
      }
    },
    {
      "fullUrl": "Condition/VaskeSigLetteBegraensninger",
      "resource": {
        "resourceType": "Condition",
        "id": "VaskeSigLetteBegraensninger",
        "meta": {
          "profile": [
            http://gateway.kl.dk/1.0/StructureDefinition/klgateway-care-condition
          ]
        },
        "extension": [
          {
            "url": http://gateway.kl.dk/1.0/StructureDefinition/klgateway-care-follow-up-encounter-extension,
            "valueReference": {
              "reference": "Encounter/bfa70a76-318d-453d-9abc-76982f8d13ca"
            }
          }
        ],
        "clinicalStatus": {
          "coding": [
            {
              "system": http://terminology.hl7.org/CodeSystem/condition-clinical,
              "code": "active"
            }
          ]
        },
        "category": {
          "coding": [
            {
              "system": http://terminology.hl7.org/CodeSystem/condition-category,
              "code": "problem-list-item"
            }
          ]
        },
        "code": {
          "coding": [
            {
              "system": http://kl.dk/fhir/common/caresocial/CodeSystem/FSIII,
              "code": "J1.1"
            }
          ]
        },
        "severity": {
          "coding": [
            {
              "system": http://kl.dk/fhir/common/caresocial/CodeSystem/FSIII,
              "code": "B2"
            }
          ]
        },
        "subject": {
          "reference": "Patient/TestPatient001"
        },
        "recordedDate": "2021-05-31T12:03:24.2821854+02:00"        
      }
    },
    {
      "fullUrl": "Observation/OpleverIkkeBegraensningerMedVaskeSig",
      "resource": {
        "resourceType": "Observation",
        "id": "OpleverIkkeBegraensningerMedVaskeSig",
        "meta": {
          "profile": [
            http://gateway.kl.dk/1.0/StructureDefinition/klgateway-care-citizens-own-observation
          ]
        },
        "code": {
          "coding": [
            {
              "system": http://kl.dk/fhir/common/caresocial/CodeSystem/FSIII,
              "code": "D"
            }
          ]
        },
        "subject": {
          "reference": "Patient/TestPatient001"
        },
        "status": "final",
        "effectiveDateTime": "2021-05-31T12:03:24.2816811+02:00",
        "valueCodeableConcept": {
            "coding": [
          {
            "system": http://kl.dk/fhir/common/caresocial/CodeSystem/FSIII,
            "code": "D1"
          }]
        },
        "focus": [
          {
            "reference": "Condition/VaskeSigLetteBegraensninger"
          }
        ]
      }
    }
  ]
}

Signature on JWT token failed validation

Vi er begyndt at få fejlbeskeden:
{ "error": "invalid_client", "error_description": "Client authentication with signed JWT failed: Signature on JWT token failed validation" }
Når vi tester med client id "systematic-columna-cura-test"

Vi har ikke ændret noget på vores side, er der ændret noget på gateways keycloak, som kan give denne fejl, jeg kan ikke selv se hvad fejlen ellers kan skyldes.

Jeg har vedhæftet et eksempel på et jwt der giver fejlen:

eyJraWQiOiJHeF9yVmNUVjRwamZOdERuWFRVQW5BTUExelRmNDZ1ZDAxcWVzamVfczNZIiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJzeXN0ZW1hdGljLWNvbHVtbmEtY3VyYS10ZXN0IiwiYXVkIjoiaHR0cHM6Ly9zYW1sLnRlc3QwMDEuZWhlYWx0aC5zdW5kaGVkLmRrL2F1dGgvcmVhbG1zL2VoZWFsdGgvcHJvdG9jb2wvb3BlbmlkLWNvbm5lY3QvdG9rZW4iLCJuYmYiOjE2NzQ2NDcwODQsImlzcyI6InN5c3RlbWF0aWMtY29sdW1uYS1jdXJhLXRlc3QiLCJleHAiOjE2NzQ2NDczODQsImlhdCI6MTY3NDY0NzA4NCwianRpIjoiNGMwNDYxNmEtYjA3Ni00MmU0LTliMmEtMjkwYzY2MDg2OTFkIn0.lZ_Rx9fe3gEWuFy08ebBJ4jATvRJAlr3IQSPioo8YWgTE7ygRrk9GEVV1aNWsf5cjM4HeiZ47B4u2_tgiuUitHr2tAaM0TyYxTpSt0iyLhSgddMY_Dh6nPbw9Ot0Ow0QT7PD8z-e451trMfv-RSNXIBopik0k5DYgV1SMbawip_srXcgN8h00MahhkhwNCzu2_JBVkgznb5P6QxcoMYjgxyyWj5j7dYrz6_8rwPHxzvqwy11gFy7E_INyrOdYLRhGGWxulp9iqrLpBebbKU1pkPriH5ODrEOUYOjIbXgmD_xUbU7Gp3ogD7-hef0qfKmoAs_r_885BSrB0UunqahxA

Production client id

Should i assume we are using the same client id in production.

This is what we are using currently in tests: kmd-nexus-test given to us in #12

No mention of a new client id in 37

Documentation confusion Encounter.type.coding vs Encounter.type.coding.code

Resource Profile: CareEncounter

If we read first this part.

It is important in FSIII to be able to express follow-up encounters. In the planning state, these are documented by setting Encounter.status = “planned”, and Encounter.type.coding = “opfølgning”. When a followUp has been performed, the Encounter.status is changed to “finished”.

Then we check the model.

image

Not only does the model not match Encounter.type.coding but type.coding.code is a fixed value.

Condition.Status change to potential

En tilstand skifter mellem aktiv og inaktiv, men den kan også skifte til potentiel. Hvordan håndterer jeg denne status ændring i condition, når en potentiel indsats skal indberettes i MatterOfInterestObservation?

DeliveryReport - opdatering eller nyt id hver gang

Vi er ikke helt sikre på, hvordan vi skal forstå "The id of any resource must be universally unique, e.g. a uuid. Resources with the same id as previously reported are considered to be an update of the previous reported information at the time indicated in the metadata of the resource." fra IG'en. Vi forstod det egentligt som om, at når der sker en ændring/opdatering i information om en bestemt borgers indsatser, så vil vi skulle sende en delivery report med samme id som den tidligere version af denne borgers delivery report, så det på gatewayen bliver set som en update. Men her kan vi se, at der sendes flere delivery reports med forskellige id'er for samme borger.

Hvad er den rigtige tilgang? Er det opdateringer af allerede indberettede delivery reports (samme Bundle.id) eller nye delivery reports (nyt Bundle.id)? Og hvis man laver nye delivery reports for hver borger, er der så stadig situationer hvor man vil lave en opdatering, og hvad er disse situationer?

Body height validation error and motor function unknown

I am testing submitting my report on Test server and I've encountered following issues which I am not sure if I am doing something wrong or if there is some other underlying issue.

First thing is that when submitting Body Height observation I cannot seem to provide a decimal value, because it fails validation with following error:
[ERROR] (no details)(further diagnostics: Rule obs-1: 'If height is given as a decimal point number, an error is returned' Failed)

And the documentation - https://fhir.kl.dk/children/2.0.0/StructureDefinition-klgateway-children-bodyheight.html - says that obs-1 error is returned when precision is more than one decimal place. This is following part of the report that won't pass validation:

{
      "fullUrl": "Observation/RikkeHeight",
      "resource": {
        "resourceType": "Observation",
        "id": "RikkeHeight",
        "meta": {
          "profile": [
            "http://fhir.kl.dk/children/StructureDefinition/klgateway-children-bodyheight"
          ]
        },
        "status": "final",
        "category": [
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/observation-category",
                "code": "vital-signs"
              }
            ]
          }
        ],
        "code": {
          "coding": [
            {
              "system": "http://loinc.org",
              "code": "8302-2"
            },
            {
              "system": "http://snomed.info/sct",
              "code": "1153637007",
              "display": "Body height"
            }
          ]
        },
        "subject": {
          "reference": "Patient/Rikke"
        },
        "encounter": {
          "reference": "Encounter/2mthEncounter"
        },
        "effectiveDateTime": "2020-07-08T12:45:00+02:00",
        "valueQuantity": {
          "value": 39.5,
          "unit": "cm",
          "system": "http://unitsofmeasure.org",
          "code": "cm"
        }
      }
    },

Second issue that I am having is that I can't provide a Motor Function observation, as it errors out with following message:
[ERROR] (no details)(further diagnostics: Profile reference 'http://fhir.kl.dk/children/StructureDefinition/klgateway-children-motor-function' has not been checked because it is unknown)

This is part of the report that contains this observation:

    {
      "fullUrl": "Observation/RikkeMotorik",
      "resource": {
        "resourceType": "Observation",
        "id": "RikkeMotorik",
        "meta": {
          "profile": [
            "http://fhir.kl.dk/children/StructureDefinition/klgateway-children-motor-function"
          ]
        },
        "status": "final",
        "code": {
          "coding": [
            {
              "system": "http://fhir.kl.dk/term/CodeSystem/FBOE",
              "code": "e04f2ca1-888a-4671-a97a-371b525cd2a3",
              "display": "Motorik"
            }
          ]
        },
        "subject": {
          "reference": "Patient/Rikke"
        },
        "encounter": {
          "reference": "Encounter/2mthEncounter"
        },
        "effectiveDateTime": "2020-07-08T12:45:00+02:00",
        "valueCodeableConcept": {
          "coding": [
            {
              "system": "http://fhir.kl.dk/term/CodeSystem/FBOE",
              "code": "936a0163-08eb-4fdb-bf0c-bcf5bc7cb3f6",
              "display": "Få tegn på udfordret motorik"
            }
          ]
        }
      }
    },

Access token request results in forbidden

This same unit test was working all morning to return an access token .

Does anyone have a second to check your logs to figure out why I cant get access tokens anymore?

Genaktivering af tilstande og tilstandsområder

I indberetningsvejledningen og IG'en står beskrevet, at tilstande opdateres, når de skifter status fra aktiv til inaktiv, og at tilstandsområder opdateres til value = 'ikke relevant', når de ikke længere er i fokus.
Hvordan skal vi håndtere det, hvis det modsatte sker, og de genaktiveres?

  • Altså hvis en tilstand er afsluttet og efterfølgende startes igen (med samme kode som tidligere)? Skal det betragtes som en ny tilstand over for gatewayen med nyt id, eller skal det være en opdatering af den tidligere tilstand?
  • Eller hvis et tilstandsområde er markeret med 'ikke relevant' og bliver relevant igen efterfølgende? Skal det betragtes som et nyt tilstandsområde over for gatewayen med nyt id, eller skal det være en opdatering af den tidligere tilstand?

DUPLICATE_ENTITY:

This is our first attempt at running. I'm curious as to where the DUPLICATE_ENTITY is coming from.

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "processing",
      "diagnostics": "DUPLICATE_ENTITY: Entity with id \u0027Bundle/9866EBF2-6A1E-4EC6-BCC0-1449BF741ECA\u0027 already exists"
    }
  ]
}

We will be testing this over the next month. I hope your Test server will be able to handle us sending requests more then once in a day.

Encounter - versionering

Vi kan i indberetningsvejledningen og i IG'en læse, at den Encounter, der skal sendes med altid er den næste opfølgningskontakt på en tilstand.
Betyder det, at når en opfølgningskontakt er gennemført, så skal vi ikke længere sende den med? I IG'en under Encounter står der, at Encounter.status skal skiftes til "finished", når opfølgningen er gennemført - men det har ikke så meget effekt at ændre status'en, hvis vi alligevel ikke skal sende den Encounter-instans. Skal en gennemført Encounter nogle gange sendes med, og i så fald: i i hvilke situationer?

Unable to connect to gateway keycloak

This issue is a duplicate of the discussion in #36
when connecting to the gateway keycloak I get the error:
{"error":"unknown_error"} with code 500

with assertion

	<Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://saml.adgangsstyring.eksterntest-stoettesystemerne.dk</Issuer>
	<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
			<Reference URI="#_cc63a2c7-86a2-4927-aa04-72f14e90dc3d">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<DigestValue>fPRzcc/NMKNh3dPwTw++zcG18DZIeC+v684Eqz4hZLE=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>REDACTED</SignatureValue>
		<KeyInfo>
			<X509Data>
				<X509Certificate>MIIGHTCCBQWgAwIBAgIEXgiTCTANBgkqhkiG9w0BAQsFADBAMQswCQYDVQQGEwJESzESMBAGA1UECgwJVFJVU1QyNDA4MR0wGwYDVQQDDBRUUlVTVDI0MDggT0NFUyBDQSBJVjAeFw0yMTA2MDgwNzA3MDNaFw0yNDA2MDgwNzA2MzVaMIGQMQswCQYDVQQGEwJESzEjMCEGA1UECgwaS09NQklUIEEvUyAvLyBDVlI6MTk0MzUwNzUxXDAgBgNVBAUTGUNWUjoxOTQzNTA3NS1GSUQ6NjA0OTI3ODgwOAYDVQQDDDF0ZXN0LWVrc3Rlcm4tYWRnYW5nc3N0eXJpbmcgKGZ1bmt0aW9uc2NlcnRpZmlrYXQpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnEbT2230TEC+ZnAgOWwAaBtoSjOszdaMBxcl1WCCfv8Rc5NFMp1FT68rexN9/k1GcTNWREPLSjEh9RUtQ5QHrEDUYDv3g/lL2YSKaVuY7YiqMn+Ei81tgKWO9N5P1UNdeLW0+5DjNSO++CC33B0AElXXVI9YhQFnSR6qTZsYPQnsD/J6FA41RMyizfk5MFmFurYn06nw9CkW3CtY5T3+FU4q55gIOiwSGplHm5emeFEyxMkXtQBaoRXpgOeSqJJ1r2GYkK3gk/1DGk/s2CKc1wPlhhU9vJOV0cNyyJ/wvUscWjjrgT5UgLX2OK3lZUiQ72W7DMgExOcKTxbvKjP+YwIDAQABo4ICzDCCAsgwDgYDVR0PAQH/BAQDAgO4MIGJBggrBgEFBQcBAQR9MHswNQYIKwYBBQUHMAGGKWh0dHA6Ly9vY3NwLmljYTA0LnRydXN0MjQwOC5jb20vcmVzcG9uZGVyMEIGCCsGAQUFBzAChjZodHRwOi8vZi5haWEuaWNhMDQudHJ1c3QyNDA4LmNvbS9vY2VzLWlzc3VpbmcwNC1jYS5jZXIwggFDBgNVHSAEggE6MIIBNjCCATIGCiqBUIEpAQEBBAMwggEiMC8GCCsGAQUFBwIBFiNodHRwOi8vd3d3LnRydXN0MjQwOC5jb20vcmVwb3NpdG9yeTCB7gYIKwYBBQUHAgIwgeEwEBYJVFJVU1QyNDA4MAMCAQEagcxGb3IgYW52ZW5kZWxzZSBhZiBjZXJ0aWZpa2F0ZXQgZ+ZsZGVyIE9DRVMgdmlsa+VyLCBDUFMgb2cgT0NFUyBDUCwgZGVyIGthbiBoZW50ZXMgZnJhIHd3dy50cnVzdDI0MDguY29tL3JlcG9zaXRvcnkuIEJlbeZyaywgYXQgVFJVU1QyNDA4IGVmdGVyIHZpbGvlcmVuZSBoYXIgZXQgYmVncuZuc2V0IGFuc3ZhciBpZnQuIHByb2Zlc3Npb25lbGxlIHBhcnRlci4wgZcGA1UdHwSBjzCBjDAuoCygKoYoaHR0cDovL2NybC5pY2EwNC50cnVzdDI0MDguY29tL2ljYTA0LmNybDBaoFigVqRUMFIxCzAJBgNVBAYTAkRLMRIwEAYDVQQKDAlUUlVTVDI0MDgxHTAbBgNVBAMMFFRSVVNUMjQwOCBPQ0VTIENBIElWMRAwDgYDVQQDDAdDUkwzMDgzMB8GA1UdIwQYMBaAFFy7dWIWMpmqNqC4mvtvpwxf8ArVMB0GA1UdDgQWBBR2bXVUcWt5i4zO9J9kpBrq5fJufDAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQBQ015R55ZZ+83w+eR/CNfZx9ykOKHqf70bOpM9yu7UxG2teAAE+4xA8Zt/F/SPbtLbxAZLkSBevmX4oVVYtNn6C0HrS8V/Gt65rS7VxEI/vBttD0EOOvwxJPW61wM4f5EXY84XZPzL9UY3ErjhDvz3W6trxYNp5wS1V4x85SI8WCesNXjryMHphPakK252IOTXvuybGNjyVwQL3DGI9i/DcOxzIPi0CaBlBEVUTvggR9E7v4P/YpxvQyrerqtEfy8PIJ/a2lysCyoMeeg0TTq5A51BK25SlWzo0muyJ7tbKuRLkPfGtuSq8uGfBBVyouNl4/nH0QDoU9mHDP17gSZZ</X509Certificate>
			</X509Data>
		</KeyInfo>
	</Signature>
	<Subject>
		<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">SERIALNUMBER=CVR:78834412-FID:93554192 + CN=Columna Cura Aalborg Uddannelse (funktionscertifikat), O=SYSTEMATIC A/S // CVR:78834412, C=DK</NameID>
		<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
			<SubjectConfirmationData xmlns:a="http://www.w3.org/2001/XMLSchema-instance" NotBefore="2022-05-23T08:02:22.134Z" NotOnOrAfter="2022-05-23T16:02:22.134Z" Recipient="http://ehealth.sundhed.dk/service/CareGateway/1" a:type="KeyInfoConfirmationDataType">
				<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
					<X509Data>
						<X509Certificate>MIIGJTCCBQ2gAwIBAgIEXl36YDANBgkqhkiG9w0BAQsFADBAMQswCQYDVQQGEwJESzESMBAGA1UECgwJVFJVU1QyNDA4MR0wGwYDVQQDDBRUUlVTVDI0MDggT0NFUyBDQSBJVjAeFw0yMjA1MDYwOTI4MDFaFw0yNTA1MDYwOTI3MDlaMIGYMQswCQYDVQQGEwJESzEnMCUGA1UECgweU1lTVEVNQVRJQyBBL1MgLy8gQ1ZSOjc4ODM0NDEyMWAwIAYDVQQFExlDVlI6Nzg4MzQ0MTItRklEOjkzNTU0MTkyMDwGA1UEAww1Q29sdW1uYSBDdXJhIEFhbGJvcmcgVWRkYW5uZWxzZSAoZnVua3Rpb25zY2VydGlmaWthdCkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCFuzhnWzMF74WPNIomwFTDmLq5gWwWT1XUHqYC5KYl5Ju7oJlgG8gZTYslWX4moZrQPL6G1sXI3o9xRQPlq8Sw7b2ettdUAQZcaMH6t1L4FpGA5hoy6IRsI1OZoaX9z29wRUfrpEXmMODuanwHnNyVVmx1fVQV9NkoqxdzXPdFv6vp3419yg1Zvwdcq5CDdXW3WVw5iWPb/6jznHpNI6+behvoZF6oeOMFIX8pAOYeMltpQrTdY1EDyIle50MWlyhsItYFO3Ja6NSVwB8jbgnUaFm6Ix/ANC+NqXdypZ1CWVsFvTqYQvKIrEQdtQshD4fHfpsnLzo2+1B+r6VQAgeZAgMBAAGjggLMMIICyDAOBgNVHQ8BAf8EBAMCA7gwgYkGCCsGAQUFBwEBBH0wezA1BggrBgEFBQcwAYYpaHR0cDovL29jc3AuaWNhMDQudHJ1c3QyNDA4LmNvbS9yZXNwb25kZXIwQgYIKwYBBQUHMAKGNmh0dHA6Ly9mLmFpYS5pY2EwNC50cnVzdDI0MDguY29tL29jZXMtaXNzdWluZzA0LWNhLmNlcjCCAUMGA1UdIASCATowggE2MIIBMgYKKoFQgSkBAQEEAzCCASIwLwYIKwYBBQUHAgEWI2h0dHA6Ly93d3cudHJ1c3QyNDA4LmNvbS9yZXBvc2l0b3J5MIHuBggrBgEFBQcCAjCB4TAQFglUUlVTVDI0MDgwAwIBARqBzEZvciBhbnZlbmRlbHNlIGFmIGNlcnRpZmlrYXRldCBn5mxkZXIgT0NFUyB2aWxr5XIsIENQUyBvZyBPQ0VTIENQLCBkZXIga2FuIGhlbnRlcyBmcmEgd3d3LnRydXN0MjQwOC5jb20vcmVwb3NpdG9yeS4gQmVt5nJrLCBhdCBUUlVTVDI0MDggZWZ0ZXIgdmlsa+VyZW5lIGhhciBldCBiZWdy5m5zZXQgYW5zdmFyIGlmdC4gcHJvZmVzc2lvbmVsbGUgcGFydGVyLjCBlwYDVR0fBIGPMIGMMC6gLKAqhihodHRwOi8vY3JsLmljYTA0LnRydXN0MjQwOC5jb20vaWNhMDQuY3JsMFqgWKBWpFQwUjELMAkGA1UEBhMCREsxEjAQBgNVBAoMCVRSVVNUMjQwODEdMBsGA1UEAwwUVFJVU1QyNDA4IE9DRVMgQ0EgSVYxEDAOBgNVBAMMB0NSTDY4MDIwHwYDVR0jBBgwFoAUXLt1YhYymao2oLia+2+nDF/wCtUwHQYDVR0OBBYEFBTtUctEIgLEIaYeP5dwe4tt4AP1MAkGA1UdEwQCMAAwDQYJKoZIhvcNAQELBQADggEBAK3FNLf0N4V53L2gaULh4a2pGaEIMgFzTPPZampcgRh/8tawh8pg0n8E/7I9TL1TBnNsy1SxtqjVLSaLo32eqd0nG/msVoOsCWSQnplbdg8n9pXrxsLpgD2pChQ4e7fDf63VU6nAny2is/Xpag3o9WN77qVf8Le9MqqT2e4GwlyG3Pn3vLVDfe3BccasazPSaOOOaWN7ZIuuNSx0gViwShwFtT73CrMSdIg1oWJsFhZ9o6Tuh514GmWDSrfd/7qI4mK1BML4+hgopXquqifTjr9jbb6c8LtP1veHCXOaEZ01cRyyoChzU2Q3CYEKcG+5qpuXOpXTP8dcGXB4M2QKHaI=</X509Certificate>
					</X509Data>
				</KeyInfo>
			</SubjectConfirmationData>
		</SubjectConfirmation>
	</Subject>
	<Conditions NotBefore="2022-05-23T08:02:22.134Z" NotOnOrAfter="2022-05-23T16:02:22.134Z">
		<AudienceRestriction>
			<Audience>http://ehealth.sundhed.dk/service/CareGateway/1</Audience>
		</AudienceRestriction>
	</Conditions>
	<AttributeStatement>
		<Attribute Name="dk:gov:saml:attribute:CvrNumberIdentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
			<AttributeValue>29189420</AttributeValue>
		</Attribute>
		<Attribute Name="dk:gov:saml:attribute:AssuranceLevel" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
			<AttributeValue>3</AttributeValue>
		</Attribute>
		<Attribute Name="dk:gov:saml:attribute:SpecVer" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
			<AttributeValue>DK-SAML-2.0</AttributeValue>
		</Attribute>
		<Attribute Name="dk:gov:saml:attribute:KombitSpecVer" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
			<AttributeValue>1.0</AttributeValue>
		</Attribute>
		<Attribute Name="dk:gov:saml:attribute:Privileges_intermediate" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
			<AttributeValue>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48YnBwOlByaXZpbGVnZUxpc3QgeG1sbnM6YnBwPSJodHRwOi8vaXRzdC5kay9vaW9zYW1sL2Jhc2ljX3ByaXZpbGVnZV9wcm9maWxlIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIj48UHJpdmlsZWdlR3JvdXAgU2NvcGU9InVybjpkazpnb3Y6c2FtbDpjdnJOdW1iZXJJZGVudGlmaWVyOjI5MTg5NDIwIj48UHJpdmlsZWdlPmh0dHA6Ly9laGVhbHRoLnN1bmRoZWQuZGsvcm9sZXMvc2VydmljZXN5c3RlbXJvbGUvY2FyZV9kZWxpdmVyeV9yZXBvcnRlcl9zeXN0ZW0vMTwvUHJpdmlsZWdlPjwvUHJpdmlsZWdlR3JvdXA+PC9icHA6UHJpdmlsZWdlTGlzdD4=</AttributeValue>
		</Attribute>
	</AttributeStatement>
	<AuthnStatement AuthnInstant="2022-05-23T08:02:22.134Z">
		<AuthnContext>
			<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</AuthnContextClassRef>
		</AuthnContext>
	</AuthnStatement>
</Assertion>

and request:

  • client_id: cura_aalborg_udd
  • client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
  • client_assertion: eyJraWQiOiItcy1lR0tOdnFHZkJQQzhJb3ltQ2tzanQ1U2FrMU0tU2QtcGw4ZE05cHRRIiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJjdXJhX2FhbGJvcmdfdWRkIiwiYXVkIjoiaHR0cHM6Ly9zYW1sLnRlc3QwMDEuZWhlYWx0aC5zdW5kaGVkLmRrL2F1dGgvcmVhbG1zL2VoZWFsdGgiLCJuYmYiOjE2NTMzMDQ5ODMsImlzcyI6ImN1cmFfYWFsYm9yZ191ZGQiLCJleHAiOjE2NTMzMDUyODMsImlhdCI6MTY1MzMwNDk4MywianRpIjoiNjE4MDUzY2QtZDVlNi00YzU1LWExM2EtNjJlODBjZTY2MzJkIn0.PkNsAZ93l5hQ_Y5i2KzOrWVdYDR8YGWQc5luE6GwJF1cv0mXZVvP6W0Wv4JKiJrn3BYTkaFtKdy6DY221qww0esSSBIZCvg352wiP_rltbcjKglUUGL-zL9trJuARsK_ow3DJbGX3P7BkXyCEqs-EMliTv2m1Mvv5fejfoS76KPpGkPmj_Q4eiVWjOs6AxYDOaIfGozrksFU4AM_JlkNVgu8eRWcMhdYEUb4xmL2XiH4dog8yegFMMMUrh7MniimCxSW90-XcINGDkDTEFrEW72ue4b_zWc1wJutxZOjFjJrjcfGf52zpsJ0ltRQtZ_gqfxsQG6X_V4Wy6qxK_1G8g
  • subject_issuer: kombit-sts
  • subject_token_type: urn:ietf:params:oauth:token-type:saml2
  • subject_token: base64 url encoded string from previous post
  • grant_type: urn:ietf:params:oauth:grant-type:token-exchange

The same implementation can however work if we use our other client id (and matching certificate)

"unable to load public key" error

hello we have gotten far enough to get a SAML token from kombit, but we are unable to get a token from the keycloak due to an error saying "Unable to load public key", the KID on the jwt should be correct, since I followed the steps in the guide for our own certificate and compared with what we get with the test one. I cannot see what else could be wrong with our request.

I have attached a request and response below, that we tried to send via postman, but were unable to do so successfully.

POST /auth/realms/ehealth/protocol/openid-connect/token HTTP/1.1
User-Agent: PostmanRuntime/7.28.4
Accept: */*
Cache-Control: no-cache
Postman-Token: 376931a4-a02f-4eee-8c6e-a679f03f1547
Host: saml.test001.ehealth.sundhed.dk
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 11895
 
client_id=systematic-columna-cura-test&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=eyJraWQiOiJzNmJXcUZzRi1sX29VZjg3YUVFZG5IMGJ2YTV6V0J2cTdQR1pDRWVlRkRRPSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJzeXN0ZW1hdGljLWNvbHVtbmEtY3VyYS10ZXN0IiwiYXVkIjoiaHR0cHM6Ly9zYW1sLnRlc3QwMDEuZWhlYWx0aC5zdW5kaGVkLmRrL2F1dGgvcmVhbG1zL2VoZWFsdGgiLCJuYmYiOjE2NDU2MjE3MDAsImlzcyI6InN5c3RlbWF0aWMtY29sdW1uYS1jdXJhLXRlc3QiLCJleHAiOjE2NDU3MDgxMDAsImlhdCI6MTY0NTYyMTcwMCwianRpIjoiOTNmMDE1MjItZTQzYi00NjFjLThjNDgtMGM3ZjNjMjNiNTE5In0.ZoMYUaApvFFyvKqeM3SCvzM4ie3GKGvoSXTWJHqItJQd4M9exmMlEcVkiO8Y2CFv5_FR6TOE-iJa09UrQJkGSpTVV6cppeXpAOv1WVBEIr2slzUDqixF09jDqsdK9Q8UICF0Vup-_W94lxt7HXVcdNZSCIyr0xjsHMjF5XlhLFd7ZjmdMJln-bw0l-1Wslb3EX7zz-uXElec0L3Y62IbNzbJBkLMXKFsgOYewS0wMpKaCbNWkuORQmylWgB_Uj9nWPfxxFCVb81KMxmjdq4rJpfRVF8qf9dvy6_t-s7eAh8SiVpOq6WLxDTdRQO-KkvgOBQTinRRzxY1qwooNjsGMw&subject_issuer=kombit-sts&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2&subject_token=PEFzc2VydGlvbiB4bWxucz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiIgSUQ9Il8xZTk2NTE1MC02M2Q3LTQ5MjEtYTRlZS1lMTNjOTVhNzg5NmEiIElzc3VlSW5zdGFudD0iMjAyMi0wMi0yM1QxMzowODoyMC4xOTVaIiBWZXJzaW9uPSIyLjAiPjxJc3N1ZXIgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZvcm1hdDplbnRpdHkiPmh0dHBzOi8vc2FtbC5hZGdhbmdzc3R5cmluZy5la3N0ZXJudGVzdC1zdG9ldHRlc3lzdGVtZXJuZS5kazwvSXNzdWVyPjxTaWduYXR1cmUgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPjxTaWduZWRJbmZvPjxDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8-PFNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNpZy1tb3JlI3JzYS1zaGEyNTYiLz48UmVmZXJlbmNlIFVSST0iI18xZTk2NTE1MC02M2Q3LTQ5MjEtYTRlZS1lMTNjOTVhNzg5NmEiPjxUcmFuc2Zvcm1zPjxUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25hdHVyZSIvPjxUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48L1RyYW5zZm9ybXM-PERpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3NoYTI1NiIvPjxEaWdlc3RWYWx1ZT5uc0wvb2ZDZ1VxdWFuOHA2RkNaWkNueEE1MUZmdXZxZU9ER2ZpYlZyeUd3PTwvRGlnZXN0VmFsdWU-PC9SZWZlcmVuY2U-PC9TaWduZWRJbmZvPjxTaWduYXR1cmVWYWx1ZT5pR2ZKVEJLYWduVjYzWVBtZWU4c3FpNVFwVVpvNnlHbUR2d081bW81WlZTMWh5b1R2aUVoczd2N0RsVUVFQ0tPUFhmSElqV2U2YktBamhFblY2UHpuK1JuRkNTRWE4STlwNEc3aHh6R0d3cm1kaUg5R2pZM3hYZXVQVnF4SGt2SGUvUkozUTFhWnhLQ1pIMXNrVjYrY2JxclpnVGwyK1ptblNIYXE3Q0FGK3k3aEp0U0EzRnhnSithUGRPRWVtaFlpNlNBUXE5QU5oN2pYbnhBTUhZRUNpNFBqcnQ5UE9xaVhMS2ZXcDVmRlBRNHNJKzdxTk1BNk5DUHExTEFJUmhtd09uMVBveTRETWNGVzBKK3MweW5UcmNDeDRvQWpTZ0tOazFEK1ZzVExnK2Y4UHNEdFZSVkZraThJZHFMODJSaFlsTGNKaXJjb3lvazBackRlR0pWbXc9PTwvU2lnbmF0dXJlVmFsdWU-PEtleUluZm8-PFg1MDlEYXRhPjxYNTA5Q2VydGlmaWNhdGU-TUlJR0hUQ0NCUVdnQXdJQkFnSUVYZ2lUQ1RBTkJna3Foa2lHOXcwQkFRc0ZBREJBTVFzd0NRWURWUVFHRXdKRVN6RVNNQkFHQTFVRUNnd0pWRkpWVTFReU5EQTRNUjB3R3dZRFZRUUREQlJVVWxWVFZESTBNRGdnVDBORlV5QkRRU0JKVmpBZUZ3MHlNVEEyTURnd056QTNNRE5hRncweU5EQTJNRGd3TnpBMk16VmFNSUdRTVFzd0NRWURWUVFHRXdKRVN6RWpNQ0VHQTFVRUNnd2FTMDlOUWtsVUlFRXZVeUF2THlCRFZsSTZNVGswTXpVd056VXhYREFnQmdOVkJBVVRHVU5XVWpveE9UUXpOVEEzTlMxR1NVUTZOakEwT1RJM09EZ3dPQVlEVlFRRERERjBaWE4wTFdWcmMzUmxjbTR0WVdSbllXNW5jM04wZVhKcGJtY2dLR1oxYm10MGFXOXVjMk5sY25ScFptbHJZWFFwTUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUFuRWJUMjIzMFRFQytabkFnT1d3QWFCdG9Tak9zemRhTUJ4Y2wxV0NDZnY4UmM1TkZNcDFGVDY4cmV4TjkvazFHY1ROV1JFUExTakVoOVJVdFE1UUhyRURVWUR2M2cvbEwyWVNLYVZ1WTdZaXFNbitFaTgxdGdLV085TjVQMVVOZGVMVzArNURqTlNPKytDQzMzQjBBRWxYWFZJOVloUUZuU1I2cVRac1lQUW5zRC9KNkZBNDFSTXlpemZrNU1GbUZ1clluMDZudzlDa1czQ3RZNVQzK0ZVNHE1NWdJT2l3U0dwbEhtNWVtZUZFeXhNa1h0UUJhb1JYcGdPZVNxSkoxcjJHWWtLM2drLzFER2svczJDS2Mxd1BsaGhVOXZKT1YwY055eUovd3ZVc2NXampyZ1Q1VWdMWDJPSzNsWlVpUTcyVzdETWdFeE9jS1R4YnZLalArWXdJREFRQUJvNElDekRDQ0FzZ3dEZ1lEVlIwUEFRSC9CQVFEQWdPNE1JR0pCZ2dyQmdFRkJRY0JBUVI5TUhzd05RWUlLd1lCQlFVSE1BR0dLV2gwZEhBNkx5OXZZM053TG1sallUQTBMblJ5ZFhOME1qUXdPQzVqYjIwdmNtVnpjRzl1WkdWeU1FSUdDQ3NHQVFVRkJ6QUNoalpvZEhSd09pOHZaaTVoYVdFdWFXTmhNRFF1ZEhKMWMzUXlOREE0TG1OdmJTOXZZMlZ6TFdsemMzVnBibWN3TkMxallTNWpaWEl3Z2dGREJnTlZIU0FFZ2dFNk1JSUJOakNDQVRJR0NpcUJVSUVwQVFFQkJBTXdnZ0VpTUM4R0NDc0dBUVVGQndJQkZpTm9kSFJ3T2k4dmQzZDNMblJ5ZFhOME1qUXdPQzVqYjIwdmNtVndiM05wZEc5eWVUQ0I3Z1lJS3dZQkJRVUhBZ0l3Z2VFd0VCWUpWRkpWVTFReU5EQTRNQU1DQVFFYWdjeEdiM0lnWVc1MlpXNWtaV3h6WlNCaFppQmpaWEowYVdacGEyRjBaWFFnWitac1pHVnlJRTlEUlZNZ2RtbHNhK1Z5TENCRFVGTWdiMmNnVDBORlV5QkRVQ3dnWkdWeUlHdGhiaUJvWlc1MFpYTWdabkpoSUhkM2R5NTBjblZ6ZERJME1EZ3VZMjl0TDNKbGNHOXphWFJ2Y25rdUlFSmxiZVp5YXl3Z1lYUWdWRkpWVTFReU5EQTRJR1ZtZEdWeUlIWnBiR3ZsY21WdVpTQm9ZWElnWlhRZ1ltVm5jdVp1YzJWMElHRnVjM1poY2lCcFpuUXVJSEJ5YjJabGMzTnBiMjVsYkd4bElIQmhjblJsY2k0d2daY0dBMVVkSHdTQmp6Q0JqREF1b0N5Z0tvWW9hSFIwY0RvdkwyTnliQzVwWTJFd05DNTBjblZ6ZERJME1EZ3VZMjl0TDJsallUQTBMbU55YkRCYW9GaWdWcVJVTUZJeEN6QUpCZ05WQkFZVEFrUkxNUkl3RUFZRFZRUUtEQWxVVWxWVFZESTBNRGd4SFRBYkJnTlZCQU1NRkZSU1ZWTlVNalF3T0NCUFEwVlRJRU5CSUVsV01SQXdEZ1lEVlFRRERBZERVa3d6TURnek1COEdBMVVkSXdRWU1CYUFGRnk3ZFdJV01wbXFOcUM0bXZ0dnB3eGY4QXJWTUIwR0ExVWREZ1FXQkJSMmJYVlVjV3Q1aTR6TzlKOWtwQnJxNWZKdWZEQUpCZ05WSFJNRUFqQUFNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUJRMDE1UjU1WlorODN3K2VSL0NOZlp4OXlrT0tIcWY3MGJPcE05eXU3VXhHMnRlQUFFKzR4QThadC9GL1NQYnRMYnhBWkxrU0Jldm1YNG9WVll0Tm42QzBIclM4Vi9HdDY1clM3VnhFSS92QnR0RDBFT092d3hKUFc2MXdNNGY1RVhZODRYWlB6TDlVWTNFcmpoRHZ6M1c2dHJ4WU5wNXdTMVY0eDg1U0k4V0Nlc05YanJ5TUhwaFBha0syNTJJT1RYdnV5YkdOanlWd1FMM0RHSTlpL0RjT3h6SVBpMENhQmxCRVZVVHZnZ1I5RTd2NFAvWXB4dlF5cmVycXRFZnk4UElKL2EybHlzQ3lvTWVlZzBUVHE1QTUxQksyNVNsV3pvMG11eUo3dGJLdVJMa1BmR3R1U3E4dUdmQkJWeW91Tmw0L25IMFFEb1U5bUhEUDE3Z1NaWjwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURhdGE-PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjxTdWJqZWN0PjxOYW1lSUQgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoxLjE6bmFtZWlkLWZvcm1hdDpYNTA5U3ViamVjdE5hbWUiPlNFUklBTE5VTUJFUj1DVlI6Nzg4MzQ0MTItRklEOjE5MTYyMDI2ICsgQ049U3lzdGVtYXRpYyBDb2x1bW5hIEN1cmEgVGVzdCAoZnVua3Rpb25zY2VydGlmaWthdCksIE89U1lTVEVNQVRJQyBBL1MgLy8gQ1ZSOjc4ODM0NDEyLCBDPURLPC9OYW1lSUQ-PFN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206aG9sZGVyLW9mLWtleSI-PFN1YmplY3RDb25maXJtYXRpb25EYXRhIHhtbG5zOmE9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiBOb3RCZWZvcmU9IjIwMjItMDItMjNUMTM6MDg6MjAuMTk1WiIgTm90T25PckFmdGVyPSIyMDIyLTAyLTIzVDIxOjA4OjIwLjE5NVoiIFJlY2lwaWVudD0iaHR0cDovL2VoZWFsdGguc3VuZGhlZC5kay9zZXJ2aWNlL0NhcmVHYXRld2F5LzEiIGE6dHlwZT0iS2V5SW5mb0NvbmZpcm1hdGlvbkRhdGFUeXBlIj48S2V5SW5mbyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI-PFg1MDlEYXRhPjxYNTA5Q2VydGlmaWNhdGU-TUlJR0t6Q0NCUk9nQXdJQkFnSUVXNjA4TURBTkJna3Foa2lHOXcwQkFRc0ZBREJJTVFzd0NRWURWUVFHRXdKRVN6RVNNQkFHQTFVRUNnd0pWRkpWVTFReU5EQTRNU1V3SXdZRFZRUUREQnhVVWxWVFZESTBNRGdnVTNsemRHVnRkR1Z6ZENCWVdFbEpJRU5CTUI0WERURTVNVEl4TnpBNE1ERXdPRm9YRFRJeU1USXhOekE0TURBd05Wb3dnWlV4Q3pBSkJnTlZCQVlUQWtSTE1TY3dKUVlEVlFRS0RCNVRXVk5VUlUxQlZFbERJRUV2VXlBdkx5QkRWbEk2TnpnNE16UTBNVEl4WFRBZ0JnTlZCQVVUR1VOV1VqbzNPRGd6TkRReE1pMUdTVVE2TVRreE5qSXdNall3T1FZRFZRUUREREpUZVhOMFpXMWhkR2xqSUVOdmJIVnRibUVnUTNWeVlTQlVaWE4wSUNobWRXNXJkR2x2Ym5OalpYSjBhV1pwYTJGMEtUQ0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUxZa0srTzFUTmhtYW9sK1JDN3lmMHlMNXBvOXg3U0xxUUhPMzh0Z1BJajJRUDNUWXBVMUZ4NXJva09Za3ZiOHI4eUJQQVQrbjIrQjFndS9BK0Yrb0liMXRqU2I1M0J3SThvRnJVRmNQaDQ4YnJwV2NROUR5eXlMVkVPRHJDYUdSaWpEOG1CaWNIQjU0cnc1TWpMaWVxdUlIcXFsbzdqaGM1ZjVqY09WNWprUVhBTXFDMXhOWW8yYjJMakFoWDRYcHIxakdkRlE2alVwTm1ncjlyOWNKWGpTV0tDR0V6S05waTRxVFh3T3RiR0JwVWNKZEl0emwvTUZtSGI1YlBwK1NJQlhKK3RRK0xNS25OQ3VzZHVZRkVmME12c2VHTkNUQklyZm1zRmM2Mi9HRi9xd0ZGeklHZVpxcXg5aFM2MTk0NDQ1QW5EN0hnNVVTVVJFYW05bm0yVUNBd0VBQWFPQ0FzMHdnZ0xKTUE0R0ExVWREd0VCL3dRRUF3SUR1RENCbHdZSUt3WUJCUVVIQVFFRWdZb3dnWWN3UEFZSUt3WUJCUVVITUFHR01HaDBkSEE2THk5dlkzTndMbk41YzNSbGJYUmxjM1F5TWk1MGNuVnpkREkwTURndVkyOXRMM0psYzNCdmJtUmxjakJIQmdnckJnRUZCUWN3QW9ZN2FIUjBjRG92TDJZdVlXbGhMbk41YzNSbGJYUmxjM1F5TWk1MGNuVnpkREkwTURndVkyOXRMM041YzNSbGJYUmxjM1F5TWkxallTNWpaWEl3Z2dFZ0JnTlZIU0FFZ2dFWE1JSUJFekNDQVE4R0RTc0dBUVFCZ2ZSUkFnUUdCQU13Z2Ywd0x3WUlLd1lCQlFVSEFnRVdJMmgwZEhBNkx5OTNkM2N1ZEhKMWMzUXlOREE0TG1OdmJTOXlaWEJ2YzJsMGIzSjVNSUhKQmdnckJnRUZCUWNDQWpDQnZEQU1GZ1ZFWVc1SlJEQURBZ0VCR29HclJHRnVTVVFnZEdWemRDQmpaWEowYVdacGEyRjBaWElnWm5KaElHUmxibTVsSUVOQklIVmtjM1JsWkdWeklIVnVaR1Z5SUU5SlJDQXhMak11Tmk0eExqUXVNUzR6TVRNeE15NHlMalF1Tmk0MExqTXVJRVJoYmtsRUlIUmxjM1FnWTJWeWRHbG1hV05oZEdWeklHWnliMjBnZEdocGN5QkRRU0JoY21VZ2FYTnpkV1ZrSUhWdVpHVnlJRTlKUkNBeExqTXVOaTR4TGpRdU1TNHpNVE14TXk0eUxqUXVOaTQwTGpNdU1JR3RCZ05WSFI4RWdhVXdnYUl3UGFBN29EbUdOMmgwZEhBNkx5OWpjbXd1YzNsemRHVnRkR1Z6ZERJeUxuUnlkWE4wTWpRd09DNWpiMjB2YzNsemRHVnRkR1Z6ZERJeU1TNWpjbXd3WWFCZm9GMmtXekJaTVFzd0NRWURWUVFHRXdKRVN6RVNNQkFHQTFVRUNnd0pWRkpWVTFReU5EQTRNU1V3SXdZRFZRUUREQnhVVWxWVFZESTBNRGdnVTNsemRHVnRkR1Z6ZENCWVdFbEpJRU5CTVE4d0RRWURWUVFEREFaRFVrd3lNVFF3SHdZRFZSMGpCQmd3Rm9BVXE2Z0JSQm13czBPWjJ2cDh6TklBR0FQblBMOHdIUVlEVlIwT0JCWUVGQkc0SzBnaXAxRkJnQU9HUm9qZDhKcklsQnFVTUFrR0ExVWRFd1FDTUFBd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFCaE4zUkdWYlh2ZElBTXVYTk93Q21heGhYTzZWRFlxbkxUaUg0eUxBM0t4KzZvbFhsWGVzaDFLSytoRVdCeXpFTUFmbGYyOGRHdmRNUy9NbXRIdkEzZVhoaVdHMFFDQU5FMS9EejVSVnYwczVjTCt6QmdOOXN5eDdxM1VNVjNwcktEbEtKTFNUOWZadndQYkdkbFVTWUZUZitKdXlyZHNrYlRkRnJLcjBXbXhIMWxhVjBRTTE1YWluandVVXJHU3pwVS9xd1NjaVZENFgrS2d4Y1pucC9YaGswVzVvbTg2SWxyOUtNQkVsT3Ric1VMQkJWM0J4UFVmU2VJUXozUlpmdWhkVVY5S3hvY2xKUTRZY0hralA5bjlNUngxS1BvMGRQSzE2ODBFN0ZsMzdBeTJOcUdiWGkvdzlsdzJRdUkrNkdNSWtPRE1CaEJJaHYxcmhETkVXSHc9PC9YNTA5Q2VydGlmaWNhdGU-PC9YNTA5RGF0YT48L0tleUluZm8-PC9TdWJqZWN0Q29uZmlybWF0aW9uRGF0YT48L1N1YmplY3RDb25maXJtYXRpb24-PC9TdWJqZWN0PjxDb25kaXRpb25zIE5vdEJlZm9yZT0iMjAyMi0wMi0yM1QxMzowODoyMC4xOTVaIiBOb3RPbk9yQWZ0ZXI9IjIwMjItMDItMjNUMjE6MDg6MjAuMTk1WiI-PEF1ZGllbmNlUmVzdHJpY3Rpb24-PEF1ZGllbmNlPmh0dHA6Ly9laGVhbHRoLnN1bmRoZWQuZGsvc2VydmljZS9DYXJlR2F0ZXdheS8xPC9BdWRpZW5jZT48L0F1ZGllbmNlUmVzdHJpY3Rpb24-PC9Db25kaXRpb25zPjxBdHRyaWJ1dGVTdGF0ZW1lbnQ-PEF0dHJpYnV0ZSBOYW1lPSJkazpnb3Y6c2FtbDphdHRyaWJ1dGU6Q3ZyTnVtYmVySWRlbnRpZmllciIgTmFtZUZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmF0dHJuYW1lLWZvcm1hdDpiYXNpYyI-PEF0dHJpYnV0ZVZhbHVlPjI5MTg5NDIwPC9BdHRyaWJ1dGVWYWx1ZT48L0F0dHJpYnV0ZT48QXR0cmlidXRlIE5hbWU9ImRrOmdvdjpzYW1sOmF0dHJpYnV0ZTpBc3N1cmFuY2VMZXZlbCIgTmFtZUZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmF0dHJuYW1lLWZvcm1hdDpiYXNpYyI-PEF0dHJpYnV0ZVZhbHVlPjM8L0F0dHJpYnV0ZVZhbHVlPjwvQXR0cmlidXRlPjxBdHRyaWJ1dGUgTmFtZT0iZGs6Z292OnNhbWw6YXR0cmlidXRlOlNwZWNWZXIiIE5hbWVGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphdHRybmFtZS1mb3JtYXQ6YmFzaWMiPjxBdHRyaWJ1dGVWYWx1ZT5ESy1TQU1MLTIuMDwvQXR0cmlidXRlVmFsdWU-PC9BdHRyaWJ1dGU-PEF0dHJpYnV0ZSBOYW1lPSJkazpnb3Y6c2FtbDphdHRyaWJ1dGU6S29tYml0U3BlY1ZlciIgTmFtZUZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmF0dHJuYW1lLWZvcm1hdDpiYXNpYyI-PEF0dHJpYnV0ZVZhbHVlPjEuMDwvQXR0cmlidXRlVmFsdWU-PC9BdHRyaWJ1dGU-PEF0dHJpYnV0ZSBOYW1lPSJkazpnb3Y6c2FtbDphdHRyaWJ1dGU6UHJpdmlsZWdlc19pbnRlcm1lZGlhdGUiIE5hbWVGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphdHRybmFtZS1mb3JtYXQ6YmFzaWMiPjxBdHRyaWJ1dGVWYWx1ZT5QRDk0Yld3Z2RtVnljMmx2YmowaU1TNHdJaUJsYm1OdlpHbHVaejBpVlZSR0xUZ2lQejQ4WW5Cd09sQnlhWFpwYkdWblpVeHBjM1FnZUcxc2JuTTZZbkJ3UFNKb2RIUndPaTh2YVhSemRDNWtheTl2YVc5ellXMXNMMkpoYzJsalgzQnlhWFpwYkdWblpWOXdjbTltYVd4bElpQjRiV3h1Y3pwNGMyazlJbWgwZEhBNkx5OTNkM2N1ZHpNdWIzSm5Mekl3TURFdldFMU1VMk5vWlcxaExXbHVjM1JoYm1ObElqNDhVSEpwZG1sc1pXZGxSM0p2ZFhBZ1UyTnZjR1U5SW5WeWJqcGthenBuYjNZNmMyRnRiRHBqZG5KT2RXMWlaWEpKWkdWdWRHbG1hV1Z5T2pJNU1UZzVOREl3SWo0OFVISnBkbWxzWldkbFBtaDBkSEE2THk5bGFHVmhiSFJvTG5OMWJtUm9aV1F1WkdzdmNtOXNaWE12YzJWeWRtbGpaWE41YzNSbGJYSnZiR1V2WTJGeVpWOWtaV3hwZG1WeWVWOXlaWEJ2Y25SbGNsOXplWE4wWlcwdk1Ud3ZVSEpwZG1sc1pXZGxQand2VUhKcGRtbHNaV2RsUjNKdmRYQStQQzlpY0hBNlVISnBkbWxzWldkbFRHbHpkRDQ9PC9BdHRyaWJ1dGVWYWx1ZT48L0F0dHJpYnV0ZT48L0F0dHJpYnV0ZVN0YXRlbWVudD48QXV0aG5TdGF0ZW1lbnQgQXV0aG5JbnN0YW50PSIyMDIyLTAyLTIzVDEzOjA4OjIwLjE5NVoiPjxBdXRobkNvbnRleHQ-PEF1dGhuQ29udGV4dENsYXNzUmVmPnVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlg1MDk8L0F1dGhuQ29udGV4dENsYXNzUmVmPjwvQXV0aG5Db250ZXh0PjwvQXV0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 
HTTP/1.1 400 Bad Request
cache-control: no-store
content-type: application/json
date: Wed, 23 Feb 2022 13:11:09 GMT
pragma: no-cache
referrer-policy: no-referrer
server: istio-envoy
strict-transport-security: max-age=31536000; includeSubDomains
x-b3-traceid: cd3c80a5adf110fc4f503e8e2e840956
x-content-type-options: nosniff
x-envoy-upstream-service-time: 4
x-frame-options: SAMEORIGIN
x-request-id: 232cf418-1c11-4ad1-8985-0eedce8b2c3f
x-xss-protection: 1; mode=block
Content-Length: 74
Connection: keep-alive
 
{"error":"invalid_client","error_description":"Unable to load public key"}

RBAC: access denied

Intermittent error. clarification please.

{
  "issue": [
    {
      "HttpErrorResponse": "RBAC: access denied"
    }
  ]
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.