1 / 31

Cross-Enterprise User Authentication Year 2

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.

kiele
Download Presentation

Cross-Enterprise User Authentication Year 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cross-Enterprise User Authentication Year 2 John F. Moehrke GE Healthcare IT Infrastructure Technical Committee

  2. Agenda • XUA use-case updates – Bill Lober • XUA Current Problems • Federated ID standards landscape • Plan of attack Interoperability Strategy Workshop

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. Normal ECP Transactions XDS Registry or Repository XDS Consumer (e.g. EHR) Interoperability Strategy Workshop

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. (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

  16. 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

  17. 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

  18. Normal ECP Transactions Interoperability Strategy Workshop

  19. (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

  20. (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

  21. (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

  22. (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

  23. 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

  24. (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

  25. (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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

More Related