Cerner Certified App Launch and Redirect URIs

[Rob Sariscak]

Hello,

We are a multi-tenant application using subdomains to identify our customers.  We want to create a connection with Cerner to launch our application using the SMART App Launch process.

With a certified application, will we have to create multiple registrations that include the customer's subdomain in the launch and redirect URIs?  How would that be managed? 

We've created a client registration in the developer sandbox and it authenticates with our application, but it only provides one entry for each URI.  For example, our URI patterns would be something like this.

launch uri: https://{customer}.ancileuperform.com/#?authMode=cerner

redirect uri: https://{customer}.ancileuperform.com/account/callback

Thanks,

Rob

[Benjamin Eichhorn (Cerner)]

Hi,

We highly suggest you do not take the approach you have suggested. By creating an app with multiple launch URLs and even redirect URLs for each domain you go to will result in an increase in the amount of time onboarding will require and you would need to register a new app for each new instance of a domain you go to. This approach will become increasingly more difficult to manage the more domains you onboard too (especially as clients like to onboard an app into their non-prods first). What you can do is use a query parameter within the URL instead that tells your application which client/domain is launching the app. The launch URL can be configured on a per domain basis and will not require you to create a new app (which would result in a new client Id and App Id). This will help decrease overhead and allow onboarding the app quicker.

Thanks,

Ben (Cerner)

[Louis Leff]

Thanks Ben,

We have taken the approach of tracking tenant id's from the iss string you return on launch.  Is this going to remain an effective approach?

Louis

[Rob Sariscak]

Hi Ben,

Thanks for the response.  Unfortunately, our application has been around for a few years and this is the routing that is currently in place.  I'll see if we can implement additional routing to make this process easier.

Regards,

Rob

On Friday, October 16, 2020 at 4:26:16 PM UTC-4 Benjamin Eichhorn (Cerner) wrote:

[Jenni Syed (Cerner)]

Hi Louis,

Using the iss (or the tenant field returned in the token response, if the application can wait until after authorization to flex this logic) are both approaches we recommend for this type of approach.

Regards,

Jenni

[Louis Leff]

Thanks Jenni,

 

We’ll stick with the iss for tenant ID.

 

Best regards and stay safe!

 

Louis

--
You received this message because you are subscribed to a topic in the Google Groups "Cerner FHIR Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cerner-fhir-developers/TyTOrR4sUDI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cerner-fhir-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/f303e727-0c7a-4198-ab5a-777891d94aado%40googlegroups.com.

[Rob Sariscak]

Hi Ben,

One last confirmation before we explore additional routing for a single redirect URI for multiple tenants.  In the Redirect URI section of https://fhir.cerner.com/authorization/#construct-the-authorization-request-url, it says

> If your application has multiple redirect_uri’s registered with Cerner then a redirect_uri is expected to be passed in during the authorization grant request. If no redirect_uri is specified the default redirect_uri registered for the application will be used.

Would this be multiple registered applications that have their own redirect URI and client identifiers, or is this one registered application with one client identifier and multiple redirect URIs?

Thanks for your help,

Rob

[Benjamin Eichhorn (Cerner)]

Hi Rob,

We support multiple redirect URIs for applications, however our code Console (at this time) does not currently support the ability to add additional ones. We can manually add additional redirect URIs as a step in the onboarding process for your app if needed when you join the code Program. Having multiple redirect URIs would be for a singular application with a singular app and client ID. 

Thanks,

Ben (Cerner)

[Brady Mackey]

Hi Ben,

We were working on a similar problem of identifying different partners from the url. We understand using the iss or tenant, but we were wondering if it's possible to embed information as a route param as well as a query param.

For example, our application launch url could be

https://our.application.com/v1/<partner-identifier>/oauth/launch

or

https://our.application.com/v1/oauth/launch?partner-identifier=<partner-identifier>

> The launch URL can be configured on a per domain basis and will not require you to create a new app (which would result in a new client Id and App Id). This will help decrease overhead and allow onboarding the app quicker.

What exactly do you mean by domain in this context? I was having trouble understanding what you mean.

Thanks!

Brady

[Benjamin Eichhorn (Cerner)]

Hi Brady,

What exactly do you mean by domain in this context? I was having trouble understanding what you mean.

By domain I am referring to a specific client's environment. Many clients will have their live production domain as well as various non-prod domains (mock, cert, etc).

In terms of using a route param, it is suggested to use the iss parameter as that is a more interoperable way of determining where your app is launched. In lieu of that though, one thing to remember is that only one launch URI can be configured for your app. So by having a URL, as you mentioned, such as https://our.application.com/v1/<partner-identifier>/oauth/launch would require that a new app be created, this means every single client domain you onboard to (so that would include a new instance of your app for each client nonprods [mock, cert, etc] and production) would require that you have a new app ID and client ID. As I mentioned this will become increasingly more difficult for both you and Cerner to manage and we would likely suggest during validation through our code Program that you refrain from doing this. 

The second URL (https://our.application.com/v1/oauth/launch?partner-identifier=<partner-identifier>) you posted is potentially the only viable alternative but would require some modifications for it to work and is also a less interoperable way of accomplishing your goal. In the code Console (where you registered your app) you would configure your launch URL as https://our.application.com/v1/oauth/launch and when the app is onboarded we can append some pre-defined parameter that can be configured on per-client or per-domain basis. Say there is a client named Baseline East and you assign them an identifier from your application we can call it BLE as an example. When the app is configured to launch in the domain a query parameter can be configured which, when launched would result in a launch URL like so:

https://our.application.com/v1/oauth/launch?cerner_partner-identifier=BLE

The important thing to note is that the query parameter must be prefixed by cerner_. That effectively means you are coupling the implementation of your app to this custom parameter (this also is why it is recommended to utilize the iss parameter versus this approach). Please also note that while this is something that can be done when your app is being launched from Powerchart this is not something we support the ability to simulate within the code Console and so you will not be able to easily test this workflow through it.

Thanks,

Ben (Cerner) 

[Rob Sariscak]

Hi Ben,

Do clients have unique Cerner tenant identifiers for each domain?  Would that would be part of the iss parameter?

> By domain I am referring to a specific client's environment. Many clients will have their live production domain as well as various non-prod domains (mock, cert, etc).

For example:

prod: https://fhir-ehr-code.cerner.com/dstu2/E53C13D7-52E3-4DC9-8C40-2B5B391834C5

test: https://fhir-ehr-code.cerner.com/dstu2/3FB5E34B-65FE-4D82-8AAA-1ED0E4F77F17

dev: https://fhir-ehr-code.cerner.com/dstu2/C08F57BE-D176-46D8-BFE4-74663F011F1A

Thanks,

Rob

[Benjamin Eichhorn (Cerner)]

Hi,

I need to correct a few points in my earlier post as I misunderstood some of the discussion we had internally. 

Specifically this statement:

When the app is configured to launch in the domain a query parameter can be configured which, when launched would result in a launch URL like so:
https://our.application.com/v1/oauth/launch?cerner_partner-identifier=BLE

Is incorrect, this value is actually not appended on the launch URL rather it is provided back to the app on the token response. 

Do clients have unique Cerner tenant identifiers for each domain?  Would that would be part of the iss parameter?

Yes, different domains will produce different iss parameters. And to further clarify, client domains will have a different subdomain than our public sandbox and client nonprods will have a different domain. It is recommended not to parse this URL but rather just store the entire value. 

Thanks,

Ben (Cerner)

[Brady Mackey]

Hey Ben,

I had a quick question about this part

> Is incorrect, this value is actually not appended on the launch URL rather it is provided back to the app on the token response. 

with our current EHR integration, that is actually how we have identified partners. Is it possible to create a application in the Code Console that would include this functionality? If not, we may stick to `iss` so that way we can properly test it before integrating with a partner.

Thanks!

Brady

[Benjamin Eichhorn (Cerner)]

Hi Brady,

Unfortunately this is not something we support in the code Console at this time.

Thanks,

Ben (Cerner)