Document Sample
IHE-XUA-TC-20051207 Powered By Docstoc
					Cross-Enterprise User Authentication
               Year 2

               John F. Moehrke
                   GE Healthcare
       IT Infrastructure Technical Committee

•   XUA use-case updates – Bill Lober
•   XUA Current Problems
•   Federated ID standards landscape
•   Plan of attack

August 24, 2005        2          Interoperability Strategy Workshop
            XUA Patient Access Use-case
1) At the 2005 IHE showcase, we were able to demonstrate a Patient-centered Health Record
(UW PcHR) which shared CCR data through the IHE registry/repository. Therefore, the patient
could maintain medical information, in their own record, that could be viewed by the other IHE
systems, just as the CCR and CDA documents from other systems could be viewed in the
patient's record. Of note, CapMed's product could also support the same use case. This is the
situation to which I intended to write the XUA use case. It is also a politically compelling,
forward looking, scenario of patient-centered care, which resonates with the language of the IOM
reports, AHRQ program announcements, etc.
But, patient centered care is a new concept, and it would be simpler to explain if...
2) We could simply say that the patient can view records in provider systems. This is what John
had been thinking, but it still suggests that the patient's authentication must be done in a way that
it can be trusted by cross-enterprise systems, the same as the providers' authentication.
From the XUA point of view, I think the authentication issues are the basically same (patient's
authentication information has to be independent of any specific provider system, provider
systems needs to accept authentication to provide views of its data). The only wrinkle that #1
adds is that the patient's system needs to also accept "foreign" authentication of providers to
whom the patient elects to grant personal health record access. I think its a good, and symmetric,
wrinkle that does not require any transactions that are not already included, though it does require
a small paradigm shift from usual care.
       August 24, 2005                            3                    Interoperability Strategy Workshop
Cross-Enterprise User Authentication
                   Value Proposition

• Extend User Identity to Affinity Domain
   – Supports any cross-enterprise transaction
   – Federated or Centralized
• Provide information necessary so that XDS
  actors can make Access Control decisions
   – Does not include Access Control mechanism
• Provide information necessary so that XDS
  actors can produce detailed and accurate
  Security Audit Trail
 August 24, 2005           4             Interoperability Strategy Workshop
Cross-Enterprise User Authentication
                   Standards Used

   • Employs SAML 2.0 Profiles
   • Specifies use of SAML Browser SSO Profile
     and Enhanced Client/Proxy Profile
   • Specifies SAML Profile to use with XDS
     (ebXML Registry)
         – Consistent with ebXML 3.0 use of SAML
   • Extends SAML 2.0 Profiles into HL7
         – future DICOM

 August 24, 2005               5            Interoperability Strategy Workshop
                                        XDS Affinity Domain
                                        (Circle of Trust)
                                                     XDS                               Key:
         St. Johns                                 Patient ID                          Original Transaction

    Auth         ID                                 Source                             XUA modification

    Prov        Prov                                                                   Use-Case number ‘n’     n
                              Any HL7                    XDS
    0a                                                  Registry        1b
 User auth                                                              Any HL7

                                                                                           North Clinic
             Radiologist                                    XDS Query
                                               4                                          Auth      ID
             Reporting                                             5                      Prov    Prov
                                        XDS Register

      2a                XDS        3                                                          0b
Any DICOM               & Register             XDS
                                                                   XDS Retrieve
PACS                                                                                  Doctor
                                       2b   Any DICOM

                  LAB                                   RID (Browser)
August 24, 2005
                                                   76                             Interoperability Strategy Workshop
                     XUA Transaction
Example: an active application (non-browser) such as an
• An EHR will issue XDS Query and/or XDS Retrieve
  transactions via standard HTTP -- With SAML ECP
• The XDS Registry will obtain SAMLv2.0 authentication
  information using the SAMLv2.0 Enhance Client/Proxy
  (ECP) Profile:
• The EHR uses the X-Identity Provider to get the Assertion
• The EHR will respond to the XDS Registry using an
  HTTP request carrying the SAML Assertion
• Service will use the SAML assertion to make access
  control decisions and audit trail logs

   August 24, 2005           7           Interoperability Strategy Workshop
          Normal ECP Transactions

August 24, 2005      8      Interoperability Strategy Workshop
• Federated ID standards immature and contentious
• What is ebXML Registry going to do?
• ASTM/ISO still working on LDAP Directory
• HL7, DICOM are very early works that need
  OASIS review

  August 24, 2005       9          Interoperability Strategy Workshop
                    SAML 2.0 Problems
• SAML v2 is very new (13 vendors passed cert)
• Standards don’t yet exist for all the needed links between
  Authentication Provider, Identity Provider, and Service
   – Need to use Liberty Alliance Profiles
• Don’t have an HTTP without SOAP solution besides
   – Need to use Liberty Alliance Profiles
• SAML Assertions are accepted as legitimate.
• SAML Protocols and Profiles are contested by WS-*

  August 24, 2005               10           Interoperability Strategy Workshop
               Federated ID Wild-Card
• WS-Trust, WS-Federation, WS-Policy*
   – Focus on Web-Services
   – Supports SAML Assertions
• Have complete solution, all standards needed available
  (draft) and profiled
   –   InfoCard  XML description of a user and methods
   –   WS-SecurityPolicy  Description of Service Provider needs
   –   WS-MetadataExchange  How a Service User gets Policy
   –   WS-Trust  How a Service user gets assertions
• Don’t have a HTTP without SOAP solution?
   – XDS Query
• DICOM and HL7 continue to use SAML2

  August 24, 2005               11             Interoperability Strategy Workshop
                  Radical Approach

• Since our transactions are protected by TLS
• Since we have ATNA assurance that a user
  is authenticated
• Simply transfer the user-identity string
• No XML wrapper
     – DICOM and HL7 Support this already today
     – HTTP Basic Auth (fake password)

August 24, 2005          12          Interoperability Strategy Workshop
                  Suggested Approach

• Continue to use OASIS SAML v2.0 standard for
     – Don’t define how you know to get an assertion
     – Don’t define how you got an assertion (saml protocol)
     – Don’t define how you use an assertion (out of scope)
• Complete HL7, and DICOM work
• Complete Assertion content based on ISO/ASTM
  final standards (also requires updates to PWP)
August 24, 2005                13             Interoperability Strategy Workshop
                   SAML v2 Details

• OASIS Security Services (SAML) TC -- Official SAML site
     – http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

• [SAMLBind] S. Cantor et al. Bindings for the OASIS Security
  Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005.
  Document ID saml-bindings-2.0-os.
• [SAMLConform] P. Mishra et al. Conformance Requirements for the
  OASIS Security Assertion Markup Language (SAML) V2.0. OASIS
  SSTC, March 2005. Document ID samlconformance-2.0-os.
• [SAMLProf] S. Cantor et al. Profiles for the OASIS Security Assertion
  Markup Language (SAML) V2.0. OASIS SSTC, March 2005.
  Document ID saml-profiles-2.0-os.

August 24, 2005                         15                   Interoperability Strategy Workshop
Cross-Enterprise User Authentication
                    Implementation Example
      EHR (ATNA Secure Node)
                           XDS Consumer
                                                         XDS Registry
                                    X-Service           (ATNA Secure Node)

                      user auth   X-Identity
                      provider    Provider

                                                Original Transaction
Patient      Audit     User
 Data        Log       Auth                     XUA Assertion
                                                TLS Protections

  August 24, 2005                         16       Interoperability Strategy Workshop
          EHR OVER Simplifications
• No other SAML transactions supported.
  –No need for IdP interfaces
  –No need for browser profiles
  –No re-authentication supported
  –No single logout supported
• Authentication will be by password contained in EHR
                      Will NOT result in
• Self-assertions with mostly pre-determined content
                      SAML compliant
   –Assertion will be “bearer” type
  –No Signing of the Assertion (we have a controlled environment in
   the demo, IdP is not a third party, ECP profile would require it)
  –Subject will not contain EncryptedID
• Manual Configuration (no SAML MetaData profile)
   August 24, 2005              17             Interoperability Strategy Workshop
      Service OVER Simplifications
• No other SAML transactions supported.
  – Not doing further queries to the IdP
• AuthnRequest profiling:
  – Relying on default behavior
                  Will NOT policy,
  – Not including conditions,result in or scoping
  – Not asking forSAML compliant
  – Not specific about the kinds of authentication needed
• Not validating SAML signatures
• Uses Assertion it gets, or returns XDS error
  August 24, 2005           18             Interoperability Strategy Workshop
          Normal ECP Transactions

August 24, 2005      19     Interoperability Strategy Workshop
        (1) XDS Transaction Request
The EHR, conducting the XDS Consumer query or
XDS Retrieve, adds the PAOS information to the
initial HTTP headers in the HTTP GET request to
the XDS Registry/Repository. This indicates to the
XDS Registry that, should authentication be
necessary, the EHR is willing to use the Reverse
SOAP over HTTP (PAOS) interaction:
 GET /index?q=servicequery HTTP/1.1
 Host: xdsreg.example.com
 Accept: text/html; application/vnd.paos+xml
 PAOS: ver='urn:liberty:paos:2003-08’;'urn:ihe:iti:xua:demo-2006'

  August 24, 2005               20             Interoperability Strategy Workshop
             (2) SAML AuthenRequest
The XDS Registry/Repository wants an assertion so it
responds with a AuthnRequest
                HTTP 200
                     Content-Type: application/vnd.paos+xml
                     Content-Length: 2222
                     Cache-Control: no-cache, no-store
                     Pragma: no-cache
                         <paos:Request xmlns:paos="urn:liberty:paos:2003-08"
                       <samlp:AuthnRequest Version= ID=
   August 24, 2005                      21                   Interoperability Strategy Workshop
    (2) SAML AuthenRequest (cont)
The AuthnRequest issued by the XDS Registry is as follows. The
AuthnRequest is directed at the EHR and conceptually presented to
the X-Identity Provider by the X-Service User.

<samlp:AuthnRequest Version=”2.0” ID=”uxGgLI4cGb”
<RequestedAuthnContext Comparison=”exact”>

   August 24, 2005                    22                Interoperability Strategy Workshop
                  (3 & 4) EHR Internals

The EHR, now acting as an identity provider, having
received the SAML Request (in the form of the
AuthRequest, conceptually presented by the X-
Service User), performs the required SAMLv2.0
validations of the Request, and prepares a SAML
Response containing a SAML Assertion or a SAML
error status. The relationship building between the
X-Service User, X-Identity Provider is easy in this
EHR scenario because of the fact that the EHR is the
authentication provider and includes the X-Identity

August 24, 2005             23         Interoperability Strategy Workshop
                      Assertion Content
                  <saml:Assertion Version=”2.0” ID=”buGxcG4gIL”
                  <saml:Conditions NotBefore=”2002-06-19T17:00:37.795Z”
                        <SubjectConfirmationData NotOnOrAfter=”2002-06-19T17:10:37.795Z”
                    <saml:AuthnStatement AuthnInstant=”2002-06-19T17:05:17.706Z”>
August 24, 2005   </saml:Assertion>         24                   Interoperability Strategy Workshop
                    (5) AuthnResponse
The EHR returns the Assertion in a SAML Response to the
XDS Registry’s Assertion Consumer Service URL. To
accomplish this the EHR initiates a new PAOS exchange
with an HTTP POST having as content a SOAP envelope
containing in its SOAP Body the SAML Response..

       POST /acs-url HTTP/1.1
       Host: xdsreg.example.com
       Accept: text/html; application/vnd.paos+xml
       PAOS: ver='urn:liberty:paos:2003-08'; 'urn:ihe:iti:xua:demo-2006’
       Content-Type: application/vnd.paos+xml
       Content-Length: 2222
       Cache-Control: no-cache, no-store, must-revalidate, private
       Pragma: no-cache

  August 24, 2005                    25                Interoperability Strategy Workshop
          (5) Authen Response (cont)
    <paos:Response refToMessageID="6c3a4f8b9c2d"
    <samlp:Response Version=”2.0” ID=”abI4gxLGuc”
        <StatusCode Value=”urn:oasis:names:tc:SAML:2.0:status:Success”>

  August 24, 2005                     26                Interoperability Strategy Workshop
                     XDS Reply
• The XDS Registry conducts the required validation of the
  SAML Response and the Assertion, completing its role as
  SAML Requester and relying party.
• The XDS Registry uses the Assertion as is. It does not
  challenge the EHR’s IDP in any further way.
• The XDS Registry records an audit entry (ATNA)
• The XDS Registry now responds as a service provider to
  the EHR’s original request – returning an HTTP response
  containing the requested service or an error.

   August 24, 2005           27           Interoperability Strategy Workshop
     Cross-Enterprise User Authentication
                              SAML Resources

• OASIS Security Services (SAML) TC -- Official SAML site
   – http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
• SAML V2.0 slides from Eve Maler (Sun) This is a good presentation
  that covers SAML V2.0 in depth, with examples and references.
   – http://www.oasis-open.org/committees/download.php/12958/SAMLV2.0-basics.pdf
• SAML V2.0 Technical Overview (still in active development) – This
  is a good overview of SAML written as an introduction for a technical
   – Found on the SAML web site
• Liberty Alliance SAML v2.0 Technology Tutorial
   – https://www.projectliberty.org/resources/LibertyTechnologyTutorial.pdf

     August 24, 2005                        28                  Interoperability Strategy Workshop
                      SAML v2.0 Certified
Liberty Alliance 13 Companies Passed SAML 2.0
              Interoperability Testing

•   ETRI                              •NTT
•   Ericsson                          •Oracle
•   HP
                                      •RSA Security
•   IBM
                                      •Sun Microsystems
•   NEC                               •Symlabs
•   Novell                            •Trustgenx

    August 24, 2005             29              Interoperability Strategy Workshop
    Get involved in the HIMSS Demo

• IHE is looking for a few willing vendors
  (EHR as well as Registry/Repository) to
  show off XUA at HIMSS.
• The above simplifications will be used.
• Contact mailto:John.Moehrke@med.ge.com

August 24, 2005     30         Interoperability Strategy Workshop
                    More information….
• IHE Web sites: www.ihe.net
• Technical Frameworks, Supplements
  – Fill in relevant supplements and frameworks
• Non-Technical Brochures :
        •   Calls for Participation
        •   IHE Fact Sheet and FAQ
        •   IHE Integration Profiles: Guidelines for Buyers
        •   IHE Connect-a-thon Results
        •   Vendor Products Integration Statements

  August 24, 2005                 31             Interoperability Strategy Workshop

Shared By: