310 likes | 424 Views
Cross-Enterprise User Authentication Year 2. John F. Moehrke GE Healthcare IT Infrastructure Technical Committee. Agenda. XUA use-case updates – Bill Lober XUA Current Problems Federated ID standards landscape Plan of attack. XUA Patient Access Use-case.
E N D
Cross-Enterprise User Authentication Year 2 John F. Moehrke GE Healthcare IT Infrastructure Technical Committee
Agenda • XUA use-case updates – Bill Lober • XUA Current Problems • Federated ID standards landscape • Plan of attack 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. Interoperability Strategy Workshop
Cross-Enterprise User AuthenticationValue 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 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 Interoperability Strategy Workshop
XDS Affinity Domain (Circle of Trust) XDS Patient ID Source Key: Original Transaction XUA modification Use-Case number ‘n’ St. Johns Auth Prov ID Prov n 1a Any HL7 XDS Registry 0a 1b User auth Any HL7 North Clinic Internal Exported Radiologist Reporting 4 XDS Query Auth Prov ID Prov 5 XDS Register 3 2a XDS Provide & Register 0b XDS Repository 6 Any DICOM XDS Retrieve Family Doctor PACS 2b Any DICOM LAB RID (Browser) 7 Interoperability Strategy Workshop
XUA Transaction Example: an active application (non-browser) such as an EHR. • An EHR will issue XDS Query and/or XDS Retrieve transactions via standard HTTP -- With SAML ECP Profile • 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 Interoperability Strategy Workshop
Normal ECP Transactions XDS Registry or Repository XDS Consumer (e.g. EHR) Interoperability Strategy Workshop
Problems • Federated ID standards immature and contentious • What is ebXML Registry going to do? • ASTM/ISO still working on LDAP Directory schema • HL7, DICOM are very early works that need OASIS review 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 User. • Need to use Liberty Alliance Profiles • Don’t have an HTTP without SOAP solution besides Web-SSO • Need to use Liberty Alliance Profiles • SAML Assertions are accepted as legitimate. • SAML Protocols and Profiles are contested by WS-* 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 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) Interoperability Strategy Workshop
Suggested Approach • Continue to use OASIS SAML v2.0 standard for Assertion. • Don’t define how you know to get an assertion (policy/metadata) • 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) 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. Interoperability Strategy Workshop
(ATNA Secure Node) (ATNA Secure Node) X-Service User user auth provider X-Identity Provider Key: Original Transaction XUA Assertion TLS Protections User Auth Audit Log Cross-Enterprise User AuthenticationImplementation Example EHR XDS Consumer XDS Registry Patient Data Interoperability Strategy Workshop
EHR OVER Simplifications Will NOT result in SAML compliant product!!!! • 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 • Self-assertions with mostly pre-determined content • 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) Interoperability Strategy Workshop
Service OVER Simplifications Will NOT result in SAML compliant product!!!! • No other SAML transactions supported. • Not doing further queries to the IdP • AuthnRequest profiling: • Relying on default behavior • Not including conditions, policy, or scoping • Not asking for re-authentication • Not specific about the kinds of authentication needed • Not validating SAML signatures • Uses Assertion it gets, or returns XDS error Interoperability Strategy Workshop
Normal ECP Transactions 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' Interoperability Strategy Workshop
(2) SAML AuthenRequest HTTP 200 Content-Type: application/vnd.paos+xml Content-Length: 2222 Cache-Control: no-cache, no-store Pragma: no-cache <SOAP-ENV:Envelope xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <paos:Request xmlns:paos="urn:liberty:paos:2003-08" responseConsumerURL="http://xdsreg.example.com/acs-url" messageID="6c3a4f8b9c2d" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAP-ENV:mustUnderstand="1" service="urn:ihe:iti:xua:demo-2006"> </paos:Request> </SOAP-ENV:Header> <SOAP-ENV:Body> <samlp:AuthnRequest Version= ID= IssueInstant=> --see-below-- </samlp:AuthnRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope> The XDS Registry/Repository wants an assertion so it responds with a AuthnRequest 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” IssueInstant=”2002-06-19T17:00:37.795Z” AssertionConsumerServiceURL="http://xdsreg.example.com/acs-url"> <Issuer> https://xdsreg.example.com/ </Issuer> <RequestedAuthnContext Comparison=”exact”> <AuthenContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password </AuthnContextClassRef> </RequestedAuthnContext> </samlp:AuthnRequest> 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 Provider. Interoperability Strategy Workshop
Assertion Content <saml:Assertion Version=”2.0” ID=”buGxcG4gIL” IssueInstant=”2002-06-19T17:05:37.795Z”> <saml:Issuer>EHR.example.com/identitysvc</saml:Issuer> <saml:Conditions NotBefore=”2002-06-19T17:00:37.795Z” NotOnOrAfter=”2002-06-19T17:10:37.795Z”> <AudienceRestriction> <Audience> http://xdsreg.example.com/acs-url/ </Audience> </AudienceRestriction> </saml:Conditions> <saml:Subject> <saml:NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”> john.moehrke@acompany.com </saml:NameID> <SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:bearer”> <SubjectConfirmationData NotOnOrAfter=”2002-06-19T17:10:37.795Z” InResponseTo=”uxGgLI4cGb” Recipient=”http://xdsreg.example.com/asc-url/”> </SubjectConfirmation> </saml:Subject> <saml:AuthnStatement AuthnInstant=”2002-06-19T17:05:17.706Z”> <AuthnContext> <AuthenContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password </AuthnContextClassRef> </AuthnContext> </saml:AuthStatement> </saml:Assertion> 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 <SOAP-ENV:Envelope … Interoperability Strategy Workshop
(5) Authen Response (cont) <SOAP-ENV:Envelope xmlns:paos="urn:liberty:paos:2003-08" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <paos:Response refToMessageID="6c3a4f8b9c2d" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next/" SOAPENV:mustUnderstand="1"/> </SOAP-ENV:Header> <SOAP-ENV:Body> <samlp:Response Version=”2.0” ID=”abI4gxLGuc” IssueInstant=”2002-06-19T17:10:30.706Z” InResponseTo=”uxGgLI4cGb”> <Status> <StatusCode Value=”urn:oasis:names:tc:SAML:2.0:status:Success”> </Status> <saml:Assertion> --see-above-- </saml:Assertion> </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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. Interoperability Strategy Workshop
Cross-Enterprise User AuthenticationSAML 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 person. • Found on the SAML web site • Liberty Alliance SAML v2.0 Technology Tutorial • https://www.projectliberty.org/resources/LibertyTechnologyTutorial.pdf Interoperability Strategy Workshop
SAML v2.0 Certified Liberty Alliance 13 Companies Passed SAML 2.0 Interoperability Testing • ETRI • Ericsson • HP • IBM • NEC • Novell http://www.projectliberty.org/press/details.php?item_id=134 • NTT • Oracle • Reactivity • RSA Security • Sun Microsystems • Symlabs • Trustgenx 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 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 Interoperability Strategy Workshop