Tag Archives: saml

RSA 2010

If you are going to be at the RSA Conference this year, we look forward to talking with you.

The RSA Security Expo
Monday March 1st – Thursday March 4th

VeriSign Booth #1717
(see map below)

San Francisco, CA
Moscone Center


This year, we’ve worked with VeriSign to integrate TrustBearer’s technology with VeriSign’s Managed PKI (MPKI) product, and we’ll be showing demos of this joint solution at the VeriSign booth.

We’ll also be showing our updated OpenID and SAML identity provider, which now allows users to register their computer with VeriSign MPKI. Similarly, users with PIV and CAC smart cards, and many other security devices, can use their credential for multi-factor authentication to web applications like Google Apps, Salesforce, and Basecamp.

If you would like to schedule a meeting with us during the conference, send us an email: sales@trustbearer.com.

To learn what we are up to during the conference, follow us on Twitter: @trustbearer.

Advertisements

Healthcare PKI in Denmark

In this post, I muse on Denmark’s implementation of a country-wide system for secure, up-to-date sharing of EMRs and patient identity federation. But I primarily want to share a links  for those interested in what they are doing:

A Cute Introduction

Last week Barack Obama visited Copenhagen to support his home city’s bid to have the 2016 Olympics hosted in Chicago. Later this year the U.S. President will meet with international leaders in Copenhagen for a UN summit, negotiating the successor to the Kyoto protocol.

In U.S. political news, the international happenings in Denmark have offered a nice break from the ongoing, rancorous national debate over reforming the U.S. health care system. Political events have stirred a broader conversation about the overall state of American health care, such as the cost and effectiveness of the current system. In a moment of free association, the events in Denmark reminded me of some interesting things about that nation’s health care system: the Danes are rather progressive—no, not because they’ve socialized, I’ll entirely leave this matter aside—in regards to they’re health care IT infrastructure.

What is Denmark Doing?

Denmark’s system is interesting so I’ll share what I’ve learned of the nation’s overall approach to health care IT and, in greater detail, discuss their implementation of PKI.

There are many Danish organizations involved with the reform of health care IT. Foremost are MedCom, the Danish Centre for Health Telematics, who is the coordinating organization for health care in Denmark and manager of the Danish Health Data Network; the National Board of Health for Denmark, who developed the data model and terminology server for the system, and leads the country’s overall health IT stragegy; and the Ministry of Science, Technology and Innovation (MTVU) in Denmark, who develops most of Denmark’s technical standards and recommended a standard for Service-Oriented Architecture (SOA) identity federation to be used in various Danish systems.

The National Board of Health’s stated goal for the reformed system was “to provide a connected health care sector in which health professionals have access to all relevant EHR data regardless of where citizens seek treatment and no matter where or when this information was registered.” Lofty, indeed 1. Unlike most countries, though, Denmark has robust broadband access in most of the country. And most general practices and hospitals already use electronic medical records (EMRs). The National Board of Health knew it would need to implement a nationwide SOA for the secure web sharing of data.

Implementation of PKI

Denmark built it’s PKI on top of it’s existing virtual private network (VPN) architecture, which is made available to all health care providers in the country, and it was already in use by many for remote collaboration. At the behest of  MVTU,  SAML was selected as the framework for identity federation and the exchange of authentication assertions. Health care professionals are issued DanID, a X.509 certificate from the Danish OECS CA. The following step explain how authentication is performed between Danish health systems 2:

  1. User authenticates as part of login to local EHR system and a digitally signed, SAML assertion is created.
    – this is a SAML security token, referred to as a virtual health professional identity card.
  2. A direct request is made to a central security token service (STS), which checks the validity of the local system’s digital signature, the user’s signature, certificate validity and revocation status, and core certificate attributes3.
  3. STS signs the SAML token and sends a response to the local system.
  4. The SAML security token can be used until it expires (after 24 hours).

Denmark PKI

I’m not sure what plans Denmark has for the authentication of everyday citizens to health care services and portals4. The foundations are certainly in place. The infrastructure for the clinical exchange of medical records, which utilizes the Danish Central Person Registry (number), provides a unique identifier for all national patients. Sundhed.dk is a public portal for Danish citizens where patients can access (some) of their health information, receive online consultation, schedule health services, and renew prescriptions/treatments. While Denmark does not issue electronic ID cards, each citizen is given a digital certificate, which is automatically derived from that citizen’s CPR number. With a combination of these parts, each Danish citizen could use their digital certificate for authentication to sundhed.dk and for the signing of health documents.

Lesson from Denmark’s System?

What can be learned from Denmark? Well, one could try to point out the things Denmark has done right, as Gartner did in their study, which will be either unmissable or made up: Denmark used a “[g]radual approach with realistic time frames”; they gave “Incentives to vendors”; they used a “project-based approach”; they “[kept] an appropriate balance between central coordination and local leadership.”; the country has a “culture of consensus”.

As all observers have pointed out, its too early to tell what improvements the reformed IT changes have made. What Denmark seems to have done right is to start with a basic, but sound architecture that makes use of existing infrastructure and technologies. They have similarly, worked to make the systems simple, affordable, and feasible for all of the country’s health providers, using open standards and technologies.

Beyond the broader success of the program, I was interested to understand how adoption and use of the PKI has been. But, it seem too early to ascertain the problems with the reformed system or understand the parts of the systems that will need to be improved. From TrustBearer’s perspective, we are interested in problems experienced while deploying and using PKI,  issues such as interoperability between relying systems, certificate policies, certificate validation, and renewal, distinguishing between levels of identity assurance, and usability for end-users. I could not find much information in regard to these issues in the Danish system, so this will be a topic left for future blog posts. One thing of note was that developers involved in the Danish project found some things lacking in the the SAML/XML schema, because its was not possible to express certain types of requirements and policies as part of an authentication/authorization assertion5. (This is related, rather loosely, to a problem TrustBearer was trying to solve in another context, signifying the strength of an authentication method in the OpenID Provider Authentication Policy Extension.)

1. A Federation of Web Services for Danish Health Care

2. As outlined in A Federation of Web Services for Danish Health Care.

3. Exchange of tokens over SOAP. http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html

4. There is a least one pilot of software-certificate-based PKI access for out patients. http://nortelemed.custompublish.com/healthnets-and-new-services-electronic-patient-records.47966-5213.html?id=48665&cat=5385

5. http://www.ecom.jp/report/Study_on_PKI_2006_in_EUROPE-FINAL.pdf

Emerging Technology Presentation from CTST

Earlier this week I gave a presentation on an Emerging Technology panel at Card Tech Secure Tech (CTST) in New Orleans. Much of the content was taken from the Virginia Security Summit presentation given a week prior, but I elaborated on using smart cards for strong authentication. A couple of the slides got into using digital certificates to prove someone’s “real” identity to a relying party using OpenID extensions and digital certificate path discovery & validation.

Where do we go from here? I would like to see some of the identity verification concepts that I touched on in the presentation be tested in a pilot. There are also opportunities here to evolve the OpenID specs and extensions, such as PAPE. TrustBearer would like to continue this discussion and explore some pilot ideas. Contact me if you are interested.

Presentation on OpenID, SAML and Authentication

This past Monday I gave a presentation as part of the Identity Management track at the first Virginia Security Summit in Richmond, VA. The audience here was a mixture of Virginia state & local technology decision makers (CIO / CTO) and implementers. This included local government, education and transportation representatives.

The session description was rather broad.

A comprehensive security plan has to start with user authentication. It is not an easy task when the range of users is constantly growing and shifting, as are potential threats. Using just one tactic is not enough – it takes a combination of technologies and procedures. This session looks at the latest technologies and approaches as well as their strengths and shortcomings.

So, I decided to give a primer on the Security Assertion Markup Language (SAML) and OpenID single sign on standards. At the beginning of the presentation I took a poll of the crowd and found that about one quarter of those in attendance (~50 people) knew something about each of these standards.

In addition to comparing and contrasting SAML and OpenID, I also talked about several strong authentication options available for each of these SSO standards. I basically wanted to convey that there are better options then making users (citizens) create yet another username & password, and various strong authentication technologies can be used with both OpenID & SAML.

One resource online that really helped me frame some ideas was the Overlap of identity technologies article published on the Google OAuth & Federated Login Research site. This is an excellent summary authored by Eric Sachs, Ashish Jain, Paul Madsen. Thanks, guys.

I’m going to be giving a similar, but more authentication focused talk at CTST in New Orleans next Tuesday, May 5. Track D: Emerging Technology, D14: Smart Cards, Tokens & Digital Identity, 4:00 PM – 5:30 PM. Hope to catch some of you out there.

Now supporting Salesforce.com and Google Apps

Big upgrade this week: TrustBearer OpenID now supports SAML-based authentication with Google Apps and Salesforce.com. You can use you existing TrustBearer OpenID account, or create a new one. Here’s how it works:

  1. Sign-In to your TrustBearer OpenID dashboard.
  2. Click the Enable SAML checkbox and create a new association.
  3. After creating your association, click Details to download the SAML certificate that will be uploaded to Google Apps or Salesforce.com.
     
  4. Login to your Salesforce.com or Google Apps account using an administrative account.
  5. Enable Single Sign On and upload the certificate that you downloaded from TrustBearer OpenID.
     
  6. Save changes and attempt to login to your Google Apps domain.
  7. Google Apps will recognize that SSO has been enabled and will redirect your login to https://openid.trustbearer.com.
  8. Connect your device and click Proceed.
     
  9. After successfully verifying your PIN, TrustBearer OpenID will pass a signed assertion to Google Apps with the account username that was configured earlier.
     
  10. And you’re in!
We’ve also added the ability for administrators to grant access to other TrustBearer OpenID accounts to login to the same company Salesforce.com or Google Apps domain.
Create a free account and give it a try. We’re excited about this new feature and look forward to hearing your feedback.