Healthx has more than a decade of experience integrating third-party vendors and partners into the Healthx platform seamlessly so that the user needs only to possess a single username and password. This integration is known as Single Sign-On (SSO). This experience has allowed us to recognize best practices for implementing SSOs as well as steer clear of some of the common pitfalls that lead to insecure or brittle integrations. A survey of our SSO implementations reveals three common and supported techniques.

SAML 2.0

Security Assertion Markup Language (SAML) is a widespread standard in SSO integrations for web-based software. It is among the most flexible and robust contemporary SSO standard. Dozens of libraries for some of the most common web technology stacks exist for implementing SAML SSO token parsing, so vendors can use SAML without writing their own native parser. 

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 authenticating 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 third-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 third-party software, hardware, and libraries that help in implementation of this standard

Web Service (custom per partner)

Web Service based SSOs are becoming less common as newer and more robust technologies become more widely adopted. Nevertheless, a number of Healthx partners and vendors still support this technique. 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 service

Redirect 3.0 is a tool that Healthx has built and uses to configure, test, and run simple Url based SSOs. 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 third-party software or libraries (beyond standard development framework) to develop

 

---

 

Once a SSO technique has been identified:

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.