Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Cross-Enterprise User Authentication Year 2 Cross-Enterprise User Authentication Year 2 John F. Moehrke GE Healthcare IT Infrastructure Technical Committee."— Presentation transcript:

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

2 August 24, 2005Interoperability Strategy Workshop2 Agenda XUA use-case updates – Bill Lober XUA Current Problems Federated ID standards landscape Plan of attack

3 August 24, 2005Interoperability Strategy Workshop3 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.

4 August 24, 2005Interoperability Strategy Workshop4 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

5 August 24, 2005Interoperability Strategy Workshop5 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

6 August 24, 2005Interoperability Strategy Workshop6 XDS Affinity Domain XDS Patient ID Source XDS Repository XDS Registry St. Johns North Clinic Auth Prov Auth Prov Radiologist Reporting Family Doctor 0a 0b User auth 3 4 XDS Provide & Register XDS Register 5 XDS Query 1a 1b Any HL7 LAB 7 RID (Browser) 6 XDS Retrieve Key: Original Transaction XUA modification Use-Case number ‘n’ n PACS 2a Any DICOM 2b Any DICOM Internal Exported ID Prov ID Prov (Circle of Trust)

7 August 24, 2005Interoperability Strategy Workshop7 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

8 August 24, 2005Interoperability Strategy Workshop8 Normal ECP Transactions XDS Registry or Repository XDS Consumer (e.g. EHR)

9 August 24, 2005Interoperability Strategy Workshop9 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

10 August 24, 2005Interoperability Strategy Workshop10 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-*

11 August 24, 2005Interoperability Strategy Workshop11 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

12 August 24, 2005Interoperability Strategy Workshop12 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)

13 August 24, 2005Interoperability Strategy Workshop13 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)

14

15 August 24, 2005Interoperability Strategy Workshop15 SAML v2 Details OASIS Security Services (SAML) TC -- Official SAML site –http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=securityhttp://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.

16 August 24, 2005Interoperability Strategy Workshop16 Key: Original Transaction XUA Assertion TLS Protections EHR Patient Data XDS Consumer XDS Registry X-Service User user auth provider X-Identity Provider Cross-Enterprise User Authentication Implementation Example User Auth (ATNA Secure Node) Audit Log

17 August 24, 2005Interoperability Strategy Workshop17 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 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) Will NOT result in SAML compliant product!!!!

18 August 24, 2005Interoperability Strategy Workshop18 Service OVER Simplifications 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 Will NOT result in SAML compliant product!!!!

19 August 24, 2005Interoperability Strategy Workshop19 Normal ECP Transactions

20 August 24, 2005Interoperability Strategy Workshop20 (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'

21 August 24, 2005Interoperability Strategy Workshop21 (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 <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/"> <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"> <samlp:AuthnRequest Version= ID= IssueInstant=> --see-below--

22 August 24, 2005Interoperability Strategy Workshop22 (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"> https://xdsreg.example.com/ urn:oasis:names:tc:SAML:2.0:ac:classes:Password

23 August 24, 2005Interoperability Strategy Workshop23 (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.

24 August 24, 2005Interoperability Strategy Workshop24 Assertion Content <saml:Assertion Version=”2.0” ID=”buGxcG4gIL” IssueInstant=”2002-06-19T17:05:37.795Z”> EHR.example.com/identitysvc <saml:Conditions NotBefore=”2002-06-19T17:00:37.795Z” NotOnOrAfter=”2002-06-19T17:10:37.795Z”> http://xdsreg.example.com/acs-url/http://xdsreg.example.com/acs-url <saml:NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”> john.moehrke@acompany.com <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/”>http://xdsreg.example.com/asc-url urn:oasis:names:tc:SAML:2.0:ac:classes:Password

25 August 24, 2005Interoperability Strategy Workshop25 (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 …

26 August 24, 2005Interoperability Strategy Workshop26 (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/"> <paos:Response refToMessageID="6c3a4f8b9c2d" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next/" SOAPENV:mustUnderstand="1"/> <samlp:Response Version=”2.0” ID=”abI4gxLGuc” IssueInstant=”2002-06-19T17:10:30.706Z” InResponseTo=”uxGgLI4cGb”> --see-above--

27 August 24, 2005Interoperability Strategy Workshop27 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.

28 August 24, 2005Interoperability Strategy Workshop28 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=securityhttp://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.pdfhttp://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.pdfhttps://www.projectliberty.org/resources/LibertyTechnologyTutorial.pdf

29 August 24, 2005Interoperability Strategy Workshop29 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

30 August 24, 2005Interoperability Strategy Workshop30 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.commailto:John.Moehrke@med.ge.com

31 August 24, 2005Interoperability Strategy Workshop31 More information…. IHE Web sites: www.ihe.net 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


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

Similar presentations


Ads by Google