Redox SSO – Under The Hood

The HTTP request

The Redox SSO Data Model will send an HTTP POST request to an endpoint you have configured in the dashboard.

You should:

  1. Verify the JSON Web Token (JWT) signature using the secret also set up in your endpoint
  2. Verify that the token is not expired (normally each SSO request will be a new token)
  3. Respond to the HTTP POSTin one of two ways:
    1. A 302 response with a redirect to where the user should be directed
    2. A 200 response with html that should be returned to the EHR

Shared Security

Redox will vouch that the SSO request coming to your application are indeed valid, authenticated users. Your application needs to handle a few other security details:

  1. Validate the token as described above
  2. Establish a user session via the redirect or HTML method described above
    1. It may be helpful to review the OWASP Session Cheat Sheet
    2. Redox can help you design a strategy for getting session information back to the EHR browser, but your application owns the security of the sessions
  3. Expire the sessions as appropriate.
    1. The JWT will provide an expiration time, but this may need to be shortened based on your application policies
    2. Redox may at some point in the future provide a Singe Logout solution, but many EHR vendors do not support it by default

Best Practices

  1. If you send a 302 to Redox, we’ll return whatever the particular EHR needs – if they can handle redirects we’ll pass it along, if not we’ll find a way to do it. By default we do a triple threat redirect, with `meta http-equiv=”refresh”`, a javascript redirect, and a link to the url if neither of those work. So if you send back a 200 + Content, and want to redirect, make sure you have as many options for redirecting as possible.
  2. Don’t use relative URLs. You don’t know what the url the browser will actually be set to when your content is loaded. For example it could be about:blank, or the initial Redox URL. Relative URLs will not redirect to your content in both of those cases.
  3. Set cookies after you redirect. Cookies are attached to the domain that they are set on, so if your content is inserted into a frame with about:blank, and then you redirect to your URL, the cookie will be inaccessible.
  4. Avoid referencing window.parent, or top in javascript. Your application will either be hosted in an iFrame, or in a full-blown browser embedded into whatever platform the EHR runs on. Operating on the assumption that you are top-level is the safest path.