Healthx Single Sign-On Techniques (Outbound)

Over the past 13 years, Healthx has implemented many dozens of Single Sign-On integrations with 3rd-party sites or vendors.  This experience has allowed us to recognize best practices for implementing SSO's as well as steer clear of some of the common pitfalls that lead to insecure and non-robust integrations.  A survey of our SSO implementations reveal three common techniques that we see partners use and we can easily accommodate:


SAML 2.0 Based SSO

Security Assertion Markup Language (SAML) is the emerging standard in SSO integrations for web-based software.  It is among the most flexible and robust SSO standard currently available.  This also means that unless a Partner codes SAML support into their website framework natively, they would likely need to use 3rd party Software or Hardware to parse and evaluate the SAML tokens prior to authentication into their site.  Some general information regarding the SAML standard is available here:

http://en.wikipedia.org/wiki/SAML_2.0

The following link contains a sequence diagram of the SAML flow.  In this diagram, Healthx would be represented as the 'identity provider' and the site that Healthx is SSO'ing into would be in the role of 'service provider'.  Also note that Healthx only supports a 'passive' (aka IdP-Initiated aka Identity-Provider-Initiated) SSO and the integration between Healthx and the service provider would start with the auto-form POST at step #4:

http://en.wikipedia.org/wiki/SAML_2.0#SP_POST_Request.3B_IdP_POST_Response

 

Some of the drawbacks to this technique are:

    • Partner would likely require 3rd party software/hardware to process the SAML tokens which could take considerable expertise to configure.
    • If the partner chooses, instead, to implement their own SAML processor (as Healthx has), it may require significant development effort.

 

The strengths of this technique are:

    • This is a standardized protocol and many premiere web sites support this method of SSO integration (Google, Salesforce.com, etc).
    • Very robust and secure standard with support for:
      • Encrypting of data
      • Digital signing of POST/GET data to ensure it has not been tampered with
      • Prevent against 'replays'
      • Possible support for 'unattended' user account provisioning (creation, updating)
    • Good selection of 3rd party software, hardware, and libraries that help in implementation of this standard


Web Service Based SSO (custom per partner)

This is a technique of SSO'ing that is not as common today in newer applications as it was a few years ago.  The workflow for this integration is:

    1. A logged-in Healthx user clicks a link to navigate to partner's website
    2. Healthx web server performs a web service call into partner's web server passing in the users information (Policy #, Member ID, etc)
    3. Partner's web server responds to web service call with a security token (a unique identifier that is stored in partner's database)
    4. Healthx web server redirects the user to the partner 'SSO landing page' passing along the security token on the url
    5. Partner verifies the security token and user proceeds on the partner site

 

Some of the drawbacks to this technique are:

    • Server-to-server communication via custom web services that may require Firewall/DMZ configuration
    • Added delay in serving the page to the user because the initial server-to-server communication prior to web server response
    • Maintenance of the web service, such as adding of additional validation fields or changing of endpoints, may require additional coding and releasing of code to production

 

When to use this technique:

    • If the partner already has this type of SSO implemented and require meeting their specifications

  

'Redirect 3.0' Based SSO

'Redirect 3.0' is a tool that Healthx has built and uses to configure, test, and run simple Url based SSO's.  These typically work by including user-identifiable information on the querystring of a GET request or the form elements of a POST request.  This sensitive information can be encrypted, hashed, etc, based on a previously agreed-upon algorithm supported by both Healthx and the partner.  The workflow for this integration is:

    1. A logged-in Healthx user clicks a link to navigate to partner's website
    2. Healthx web server encrypts users information (Policy #, Member ID, etc) and sends response to the browser along with javascript that will perform either the redirect or the form submission to the partner 'SSO landing page'
    3. Partner decrypts and/or verifies the signature of the information passed and user proceeds on the partner site

 

Some of the drawbacks to this technique are:

    • Requires additional thought regarding passing of personal information to ensure that the SSO is tamper-proof.  For best security, should require signature or encryption of personal information passed from Healthx to Partner site.

The strengths of this technique are:

    • Relatively easy for Partners to develop and maintain the 'SSO Landing Page'
    • Very flexible and depending on requirements, you can implement many security mechanisms such as
      • Encrypting of data
      • Digital signing of POST/GET data to ensure it has not been tampered with
      • Inclusion of timestamp to prevent against 'replays'
    • Does not require commercial 3rd party software or libraries (beyond standard development framework) to develop

 



 

Once a SSO technique is chosen, the next steps would be to:

  1. Determine the unique user identifying information that is common in the two systems and will be sent in the SSO to identify the proper account that is authenticating.  This may include:  Policy #, Member ID, SSN, etc
  2. Discuss session keep-alives, so that the user remains logged in to Healthx when they are navigating the Partner's site.  We typically perform this by having the partner include a unviewable image in their website that references the Healthx domain and keeps the session active
  3. Discuss whether to embed the Partner pages in an iFrame within Healthx pages or to open in a new window.  Possible side-issues may be logout functionality, as well as iFrame resizing to eliminate nested scroll bars.  We typically accomplish this by having the partner include javascript into their pages that allows the Healthx page to properly resize the iFramed partner page.
Comments