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

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

Embed Size (px)

Citation preview

Cross-Enterprise User AuthenticationYear 2

Cross-Enterprise User AuthenticationYear 2

John F. MoehrkeGE Healthcare

IT Infrastructure Technical Committee

August 24, 2005 Interoperability Strategy Workshop2

AgendaAgenda

• XUA use-case updates – Bill Lober

• XUA Current Problems

• Federated ID standards landscape

• Plan of attack

August 24, 2005 Interoperability Strategy Workshop3

XUA Patient Access Use-caseXUA 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 Interoperability Strategy Workshop4

Cross-Enterprise User AuthenticationCross-Enterprise User Authentication

Value PropositionValue 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 Interoperability Strategy Workshop5

Cross-Enterprise User Authentication Cross-Enterprise User Authentication

Standards UsedStandards 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 Interoperability Strategy Workshop6

XDS Affinity Domain

XDS Patient ID

Source

XDSRepository

XDS Registry

St. Johns

North Clinic

AuthProv

AuthProv

RadiologistReporting

Family Doctor

0a

0b

User auth

3

4

XDSProvide& Register

XDS Register5

XDS Query

1a

1bAny HL7

Any HL7

LAB7

RID (Browser)

6XDS Retrieve

Key:

Original Transaction

XUA modification

Use-Case number ‘n’ n

PACS

2aAny DICOM

2b Any DICOM

InternalExported

IDProv

IDProv

(Circle of Trust)

August 24, 2005 Interoperability Strategy Workshop7

XUA TransactionXUA TransactionExample: 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

August 24, 2005 Interoperability Strategy Workshop8

Normal ECP TransactionsNormal ECP Transactions

XDS Registry or Repository

XDS Consumer

(e.g. EHR)

August 24, 2005 Interoperability Strategy Workshop9

ProblemsProblems

• 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

August 24, 2005 Interoperability Strategy Workshop10

SAML 2.0 ProblemsSAML 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-*

August 24, 2005 Interoperability Strategy Workshop11

Federated ID Wild-CardFederated 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 Interoperability Strategy Workshop12

Radical ApproachRadical 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 Interoperability Strategy Workshop13

Suggested ApproachSuggested 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)

August 24, 2005 Interoperability Strategy Workshop15

SAML v2 DetailsSAML 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 Interoperability Strategy Workshop16

Key:

Original Transaction

XUA Assertion

TLS Protections

EHR

PatientData

XDS Consumer XDS Registry

X-Service User

user auth provider

X-Identity Provider

Cross-Enterprise User AuthenticationCross-Enterprise User Authentication

Implementation ExampleImplementation Example

UserAuth

(ATNA Secure Node)

(ATNA Secure Node)

AuditLog

August 24, 2005 Interoperability Strategy Workshop17

EHR OVER SimplificationsEHR 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!!!!

August 24, 2005 Interoperability Strategy Workshop18

Service OVER SimplificationsService 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!!!!

August 24, 2005 Interoperability Strategy Workshop19

Normal ECP TransactionsNormal ECP Transactions

August 24, 2005 Interoperability Strategy Workshop20

(1) XDS Transaction Request(1) XDS Transaction RequestThe 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.1Host: xdsreg.example.comAccept: text/html; application/vnd.paos+xmlPAOS: ver='urn:liberty:paos:2003-08’;'urn:ihe:iti:xua:demo-2006'

August 24, 2005 Interoperability Strategy Workshop21

(2) SAML AuthenRequest(2) SAML AuthenRequestThe XDS Registry/Repository wants an assertion so it responds with a AuthnRequest

HTTP 200Content-Type: application/vnd.paos+xmlContent-Length: 2222Cache-Control: no-cache, no-storePragma: 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>

August 24, 2005 Interoperability Strategy Workshop22

(2) SAML AuthenRequest (cont)(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>

August 24, 2005 Interoperability Strategy Workshop23

(3 & 4) EHR Internals(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.

August 24, 2005 Interoperability Strategy Workshop24

Assertion ContentAssertion 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”> [email protected] </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>

August 24, 2005 Interoperability Strategy Workshop25

(5) AuthnResponse(5) AuthnResponseThe 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.1Host: xdsreg.example.comAccept: text/html; application/vnd.paos+xmlPAOS: ver='urn:liberty:paos:2003-08'; 'urn:ihe:iti:xua:demo-2006’Content-Type: application/vnd.paos+xmlContent-Length: 2222Cache-Control: no-cache, no-store, must-revalidate, privatePragma: no-cache<SOAP-ENV:Envelope

August 24, 2005 Interoperability Strategy Workshop26

(5) Authen Response (cont)(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>

August 24, 2005 Interoperability Strategy Workshop27

XDS ReplyXDS 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 Interoperability Strategy Workshop28

Cross-Enterprise User AuthenticationCross-Enterprise User AuthenticationSAML ResourcesSAML 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

August 24, 2005 Interoperability Strategy Workshop29

SAML v2.0 CertifiedSAML 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

August 24, 2005 Interoperability Strategy Workshop30

Get involved in the HIMSS DemoGet 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:[email protected]

August 24, 2005 Interoperability Strategy Workshop31

More information….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