Username/password on standalone app for smartcard/PIN SSO

242 views
Skip to first unread message
Assigned to kol.k...@gmail.com by jenni...@gmail.com

Tobin Chew

unread,
Jun 11, 2018, 2:03:58 PM6/11/18
to Cerner FHIR Developers
I'm working with a client using SSO and Citrix to access PowerChart. My goal is to setup our app to launch both within PowerChart using the SSO, and be a standalone (web)app on tablet devices.

I'm able to get both the popup login page 
when navigating to my launch.html directly; and become logged in when launching from the Cerner codeportal using 'portal/portal'. 

1 - What should I use to login the standalone login page, portal/portal does not work.
2 - For users normally using SSO / Citrix launched from smartcard + PIN, what would they enter as their username / password?

3 - Is it possible to launch into a Provider user from the CodePortal without a patient context, so that I can test searching and selecting a patient context within the app?

If 2 proves impossible, my plan is to auth users in the webapp using a different Auth service, and a system Cerner account to submit the updates. Is this a 'normal' alternative?

Many thanks,
Tobin

Matt Randall (Cerner)

unread,
Jun 13, 2018, 3:24:01 PM6/13/18
to Cerner FHIR Developers
I can comment on the authentication modality question:

SMART on FHIR currently only supports the Millennium OpenID authentication server in client (as in client-server) environments such as pure browser or mobile devices.  Millennium OpenID limits you to either the user's Millennium password (or LDAP password, if configured for LDAP authentication.)  Development is being done to enable external identity systems to be used for authentication (enabled via a subset of the SAML 2.0 Web Brower SSO Profile), however, I cannot offer any commentary as to when that would be available for use in your scenario.  Your alternative you listed is possible, however, note that any reads / writes performed done via a system account are not done using the end user's privileges (you would need to enforce your own authorization logic), and that the audit trail would reflect the system account having made the modification (not the end user.)  Most access is typically done using the end user's account (and not system access); very few organizations have encountered this problem, as most are using username and password authentication.

- Matt

Kol Kheang (Cerner)

unread,
Jun 13, 2018, 11:26:47 PM6/13/18
to Cerner FHIR Developers
Hi Tobin,

I'll try to answer 1 and 3.

1. For a standalone patient app, you can see a list of patients with the credentials here https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/cerner-fhir-developers/edPUbVPIag0
3. Yes, you can skip the patient selection dialog.  Make sure that you app has user-level scopes (e.g. user/Patient.read).  App launched form code Portal is called EHR launched.  It's not a standalone launch.


Thanks,
Kol

Tobin Chew

unread,
Jun 14, 2018, 3:06:11 AM6/14/18
to Cerner FHIR Developers
Hi Matt,

Thank you so much, that makes a lot of sense. I can see it's a bit of a unique situation. 

To clarify, a System app's Scope is user/patient agnostic, and can read/write into whoever's resources it wants. Looking at the example DocumentReference Create request at https://fhir.cerner.com/millennium/dstu2/infrastructure/document-reference/#create I see I can add attributes:

"subject": {
    "reference": "Patient/53663272"
  },
"author": [
    {
      "reference": "Practitioner/21500981"
    }
  ],

If I POST a `create` from the System app, presumably I can popuplate these fields with the appropriate `reference` data (rather than it filling automatically from the Launch context). Is there another field that states it was submitted by a System app then?

Many thanks,
Tobin

Tobin Chew

unread,
Jun 14, 2018, 3:21:14 AM6/14/18
to Cerner FHIR Developers
Hi Kol,

Thanks for the answers, really helpful.

For 1, do you have any Provider standalone app login options please? 

I didn't realise this, thanks, presumably that's the same for System apps?

Many thanks,
Tobin

Kol Kheang (Cerner)

unread,
Jun 14, 2018, 4:33:06 PM6/14/18
to Cerner FHIR Developers
Hi Tobin,

You can use portal/portal when login to the provider standalone scenario.  You need to specify the iss param with the value for the FHIR server. 

The example above uses Cerner's implementation of FHIR in our Sandbox instance.  More info here: https://fhir.cerner.com/millennium/dstu2/#service-root-url

In code Console, you must request user scopes (e.g. user/Patient.read user/Observation.read).  In your launch page, you should request these scopes: user/Patient.read user/Observation.read online_access openid profile.  Notice that there is no 'launch' or 'launch/patient' scope needed.

This should get allow the app to authorize.  After that, you can perform patient search to locate a patient in the EHR system.


- Kol

Richard Hensel

unread,
Jun 15, 2018, 12:24:56 PM6/15/18
to Cerner FHIR Developers
Can you clarify the ability to use a system account to authenticate to the FHIR server? We have a client who  would like to authenticate via a separate SAML2 IdP and have the FHIR traffic all use a system account. That is possible? Would it use basic auth?

Thanks.

Jenni Syed (Cerner)

unread,
Jun 15, 2018, 4:29:39 PM6/15/18
to Cerner FHIR Developers
See discussion here on concerns around system accounts: https://groups.google.com/d/msg/cerner-fhir-developers/6L7dX11a10w/5Zx_-sgYDgAJ

Cerner's FHIR server allows them to use an existing session (assuming the app launches from their EHR), so they wouldn't be prompted to re-log in. Unless you want to take on the complexity of auditing, privacy, and legal concerns around privacy and data sensitivity, it's recommended to use on behalf of a user when the user themselves is actively signed in.

~ Jenni

Tobin Chew

unread,
Jun 15, 2018, 7:29:30 PM6/15/18
to Cerner FHIR Developers
Hi Jenni,

Thanks for the link ( and the common issues), really useful.

I see your points about why shouldn't really use System Access. My new plan is to allow the user to EHR launch, then send the refresh_token to our app via QR code. My intention is to allow the user to 'pair' their new app with their EHR launched app and grab the relevant person data using a valid acces_token. As long as the app is open, they'll be able to access resources like on a browser / PC, refreshing the access_token, etc. The EHR app would also still be logged in 

One thing that doesn't seem so clear please, the difference between online_access and offline_access revocation. What determines when the online_access session has expired with the stateless token? Ideally I wouldn't use offline_access as allows indefinite access. I want the user to be able to reopen the app, use a simple PIN to allow access to their saved session data (stored on the device), and exchange the stored refresh_token in the device for a new access_token.

If the user closes the EHR launched page, would this revoke the online_access refresh_token? Is there an actual life limit to the token? 

How does one manually revoke the refresh_token? My plan is that from the app, the user can logout and forget the current tokens either manually or from failed PIN entries. But from their EHR launched browser they should be able to revoke all keys.

In the docs I saw it says that we have to 'revoke the original' issuance of the offline_access refresh_token, how does one do that please out of interest?

Many thanks,
Tobin

Matt Randall (Cerner)

unread,
Jun 20, 2018, 10:11:30 AM6/20/18
to Cerner FHIR Developers



One thing that doesn't seem so clear please, the difference between online_access and offline_access revocation. What determines when the online_access session has expired with the stateless token? Ideally I wouldn't use offline_access as allows indefinite access. I want the user to be able to reopen the app, use a simple PIN to allow access to their saved session data (stored on the device), and exchange the stored refresh_token in the device for a new access_token.

If the user closes the EHR launched page, would this revoke the online_access refresh_token? Is there an actual life limit to the token? 

The refresh token is backed by a session at our authorization server; these sessions are time-bound (it's variable based on configuration).  There isn't a workflow at this point defined by SMART on FHIR that enables an application to trigger a log-out; traditionally, this has simply been handled by the fact that SMART apps for providers/practitioners are traditionally delivered inside a browser inside the EMR itself in the Cerner ecosystem.  As you note below, refresh token revocation would likely be an appropriate avenue.
 

How does one manually revoke the refresh_token? My plan is that from the app, the user can logout and forget the current tokens either manually or from failed PIN entries. But from their EHR launched browser they should be able to revoke all keys.

Refresh token revocation has not been implemented.  There is an RFC around this, but no formal Argonaut profiles.
 

In the docs I saw it says that we have to 'revoke the original' issuance of the offline_access refresh_token, how does one do that please out of interest?

Offline access is only available for patient-facing workflows at this point; the tooling does not yet exist for administrators to provision apps with offline access to EHR .  The URL that allows an individual to access this workflow is advertised in the FHIR conformance document as the 'manage' endpoint; an example of this is documented here [1].  Notably, the "manage authorizations" page is correspondingly accessible to users of the provider/practitioner persona, and that it offers a log-out link, which might offer a round-about way to enable the user to log-out.


Reply all
Reply to author
Forward
0 new messages