Cross-Enterprise User Assertion - Discussion

From IHE Wiki
Jump to navigation Jump to search

Introduction

IHE has defined a profile for Enterprise User Authentication (EUA) and Personnel White Pages (PWP) for use within an enterprise. The IHE is now defining transactions that cross enterprise boundaries, specifically the XDS profile and others that create an Affinity Domain. When transactions cross enterprise boundaries the mechanisms found in the EUA and PWP profile are insufficient and often nonfunctional. To provide accountability in these cross enterprise transactions there is a need to identify the requesting user in a way that the receiver can make access decisions and proper audit entries.

Cross-Enterprise User Assertion(XUA) profile will provide the user identity in transactions that cross enterprise boundaries. Enterprises may choose to have their own user directory and their own unique method of authenticating. To provide accountability in these cross enterprise transactions there is a need to identify the requesting user in a way that the receiver can make access decisions and proper audit entries.

Detailed Profile Proposal for XUA January, 2007 : John Moehrke

The profile document is being developed at Cross-Enterprise User Assertion Profile

Discussion

The profile document is being developed at Cross-Enterprise User Assertion Profile

Notes for IHE Tech Face-to-Face -- March 14, 2007

Conclusions

  • Will rename XUA to Cross-Enterprise User Assertion
  • We will NOT be using WS-I profiles. We will be specifying that WSS be be added to the SOAP message, and that the XML token type be used, and that the XML token type be filled with a SAML v2.0 Assertion. Thus only calling out WSS and SAML 2.0 as standards.
  • Use SAML 2.0 because SAML committee wants that used when legacy install is not present
  • SAML Assertion content: Focus on Authentication and Attribute statements. NOT Authorizations
  • Place the mechanism of obtaining the SAML Assertion out of scope. This is not necessary to profile in order to get interoperability on the specific transaction
    • This means we are not directly profiling identity federation but are enabling identity federation.
  • Will recommend the use of SAML Metadata standard to streamline the configuration. The SAML Metadata standard allows for the communication of things like: Identity Provider Certificate, Service Provider's requirements around assertion attributes, etc
    • IHE may be able to publish a fragment of a WS-Policy with the constraints of the XUA profile. This will further be specialized by each service provider.

XUA Use-Cases

  • User using Registry or Repository where the service provider wants a user identity for additional detail in their audit log
    • User Identity is all that is required
    • The User Identity must come from any trustable identity provider.
      • This may be a single identity provider in an Affinity Domain. (Germany using SmartCard issued chaining back to a single CA)
      • This may be (most likely is) a set of identity providers where these identity providers are likely in the control of each enterprise in the XDS Affinity Domain. (MAYO clinic identity proider, St Mary's identity provider, Kaiser identity provider, etc)
  • User using Registry or Repository where the service provider wants to impose be assured that the user has been authenticated to a specific assurance level. This is not a case of not trusting the system, but recognition that the system supports different levels of authentication. For example the system supports a proximity card as a form of authentication, as well as Smart-Card with PIN. This is not a replacement for ATNA access controls which give distributed access controls.
    • User Identity with level of assurance of that identity is needed..
  • User using Registry or Repository where the service provider wants to impose additional access controls. This is not a replacement for ATNA access controls which give distributed access controls.
    • This use-case may introduce break-glass concerns that will not be addressed.
    • In the simplest form the binding of the user identity to the service providers access controls is out of scope. There is some proprietary mapping of the user identity to local roles to local permissions
    • In more complex forms may want attributes that indicate the user's role
      • May at best leverage the CEN role codes.???????
  • Specialized XDS for Emergency Dataset. In this case the transfer of information to the XDS Consumer is not critical to fully control, and thus the administration is willing to accept requests from any system as long as they can provide a user-assertion from a trusted source. This trusted-source may be a specialized IDP for First Responders. (See RSA Pilot)
    • In this case only a user identity with proper linkage to a trusted IDP is needed. No specific attributes are needed.
  • User using Registry or Repository is the patient. They are using an authorized PHR service which is handling the XDS Consumer responsibilities (including ATNA). The service provider wants to restrict the information returned to those that have been released for patient consumption (for example a lab result that regulations require the provider to discuss in person before releasing the information)
    • In this case the user identity is needed for audit logging
    • In this case the user identity needs to be linked to their role as the patient
  • User using a Cross-Community-Bridge needs to provide a user assertion that can be utilized by the Cross-Community-Bridge.
    • This requires that the Assertions can be re-purposed for the next Bridge or Reg

SAML Assertion Parts

  • Authentication type and strength --> YES
    • Subject:
      • should there be one? --> Likely this is needed as the singular value to go into ATNA log
      • What is the NameID format? --> Transient may be out of scope
      • What type of subject confirmation should be used to assume that an agent does not missue the assertion? Holder-of-key? --> Good topic to discuss for public comment.
    • Conditions: What should be used for audience information? Affinity domain? We can constrain assertions to a specific use. In a bridging case should there be proxy restrictions? --> This is not clear why we would constrain this further. We might give guidance.
    • AuthnStatement: What types of AuthnContext do you accept, just references? If not what does the craziness of comparing contexts to determine ordering per the SAML spec mean?
  • Attributes --> Depending on use-cases
    • AttributeStatement: What's the name format? What are the names? OIDs? (i sure hope not) What specs (ASTM, ISO, etc.) should be profiled as attribute profiles?
  • Authorizations --> Deprecated by SAML committee, that wants us to use XACML
  • The SAML Assertions MUST be signed by the IDP.

EXAMPLE SAML ASSERTION 

1: <saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”
2: Version="2.0"
3: IssueInstant="2005-01-31T12:00:00Z">
4: <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity>
5: http://www.example.com
6: </saml:Issuer>
7: <saml:Subject>
8: <saml:NameID
9: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
10: j.doe@example.com
11: </saml:NameID>
12: </saml:Subject>
13: <saml:Conditions
14: NotBefore="2005-01-31T12:00:00Z"
15: NotOnOrAfter="2005-01-31T12:10:00Z">
16: </saml:Conditions>
17: <saml:AuthnStatement
18: AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">
19: <saml:AuthnContext>
20: <saml:AuthnContextClassRef>
21: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
22: </saml:AuthnContextClassRef>
23: </saml:AuthnContext>
24: </saml:AuthnStatement>
25: </saml:Assertion>
Figure 6: Assertion with Subject, Conditions, and Authentication Statement

Notes from IHE Tech Face-to-Face -- March 13, 2007

The key items to accomplish this week are:

  1. Develop a profile (not clear if this is transaction or content profile or just more parts of the Web-Services Appendix or XDS Actor options or something else)
  2. Focus on XDS Stored Query and XDS WS-Retrieve (while being open to others if time/resources)
    1. remind audience that the use-case involves at least two different administrative domains that are operating under different technology, procedures, role-models, etc. They are cooperating in the XDS Affinity domain under an overarching policy that indicates that these differences can be rationalized. The XDS transactions are transferring control from one entity to another. This fact is important to the discussion about what is reasonable uses of the Assertion.
    2. we will be using XDS to exchange data between a simple doctor, the VA, and MASS General. It is not likely that they will all agree to the same RBAC security model. This is not necessary to have this agreed to, but it is reasonable that at the policy level they can.
    3. This results in an important fact that the XUA is usable for audit logging, but is of a lesser extent useful for access controls.
  3. Leverage WS-I Basic Security Profile (version 1.1)
    1. Need Version 1.1 as it profiles SAML 2.0. http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity
      1. Not clear to me how WS-I Basic Security Profiles will handle MTOM, they both reference SOAP with attachments.
      2. Not clear to me the relationship of WS-I profiles to SOAP 1.2. WS-I seem to me to refer to SOAP 1.1 or 1.0. --> This will be profiling work that we need to do. WS-I is developing 2.0 versions of their profiles with SOAP 2.0 support. (Roberto)
    2. WS-Security header
    3. WS-Security XML Security token using SAML 2.0 Assertions
    4. Focus on Authentication and Attribute statements. NOT Authorizations
    5. Don't restrict Service Providers or Service Users from using other methods, the constraints are a minimal floor for interoperability sake.
    6. Does this impact ATNA (Node Authentication)? Do we further profile WS-I to only TLS, thus not using (allowing) XML Signatures/Encryption? Is there a reason to restrict in this way, Especially for Web-Services?
  4. Leverage SAML-Protocol for the requirements of the IDP (STS), thus no new profiling from IHE
    1. Thus leveraging Liberty Alliance Certification to the SAML 2.0 standards
  5. Examine the potential User Attributes for the use-cases
    1. User is Patient, Provider, Guardian, Application, Clerk, Security Admin, etc
    2. We may find useful attributes to profile:
      1. X.509 certificate compliant from ISO/TS 17090 – Health Informatics PKI, for identify management
      2. Assertion LDAP Metadata compliant from ISO/TS 21091 – Healthcare Informatics – Directory services for security, communications, and identification of professionals and patients (submitted for publication)
      3. Functional and Structural Roles from ISO/DTS 21298 (work item in committee) --- CEN 13606-4 is the same vocabulary and is normative.
      4. List of Professions from ASTM E1633 – Standard Specification for Coded Values Used in Electronic Health Record.
      5. Information access privileges from ASTM E1986 – Standard Guide for Information Access Privileges to Health Information
      6. Role vocabulary from ASTM – Privilege Management Infrastructure (work item document number not assigned)
    3. Need to make the assertion from a patient clearly indicating that the assertion is for a patient
      1. Should include the patient ID
      2. Need to be clear in the profile that there are many issues with patient access that are not handled (e.g. patient accessing lab results that have not yet been released for patient consumption, Consent, Specific provider restrictions, Specific data restrictions, Workflow of a physician that needs to discuss the data before the patient sees it, Delegates (parent, child, guardian, elder)) --> This should go into our Appendix L (policies necessary for Affinity Domain)
      3. Patient accesses XDS through some 'service' like a PHR. The PHR needs to be a member of the Affinity Domain.
      4. Need to be clear on the case where a physician is a patient... which role?
    4. When the User Assertion is about an enterprise personnel (provider, clerk, etc), then we should allow for retrieving of these attributes from PWP. Update PWP profile as necessary with attributes not found there.
  6. Show at least one way that a system using EUA can get XUA Assertions
  7. Show at least one way that a browser [interacting with Middleware] can obtain an XUA Assertions for the Middleware to use in XDS Stored Query requests or XDS WS Retrieve(a common XUA-Consumer arrangement)
  8. Show how the XUA Assertions are encoded in ATNA Audit messages. Some have indicated that the whole SAML Assertion needs to be saved in the audit message. The hope is that we can pull the user identity out of the SAML Assertion.
  9. Show roadmap for other transactions (HL7 V3, HL7 V2, DICOM, Browsers) --> This is likely just a note of the resources to go look at to work with.

The following are open issues that the IHE IT Infrastructure Technical Committee has on the XUA profile. We invite comment on these issues as they will assist with the ultimate profiling into the XUA profile.

  1. Not clear if we need to define any configuration requirements. (aka SAML Metadata standard)
  2. Should we rename this to “Cross-Enterprise User Assertion (XUA)” to show that we are addressing the user assertion and not the act of authenticating the user?
  3. Not clear how much we need to reference WS-SX
  4. There are questions around how the application calling on a service that needs XUA knows that XUA is needed?
  5. There are questions around how the application calling on a service that needs XUA knows what the XUA Assertion needs to contain?
  6. There are questions around error modes around the assertion, transaction, access rights (e.g. do we tell the user why it fails)?
  7. Should we informatively cover an EMR/EHR doing self-assertions are a simplified model that doesn't scale well, but gets around client side lack of standards
  8. How is Emergency Mode handled?
    1. One view is that this is just an infrastructure robustness issue.
    2. This must work for medical devices where the medical device includes all the standards when it is shipped from the manufacture. No ‘agent’ can be required to make this work.
    3. Do we have a well defined way for one actor to declare that it is in emergency mode? Clearly this mode doesn’t have to be accepted. Clearly the use of this mode must be carefully managed with policy.
    4. Possibly a ‘claimed’ functional role.
    5. May need to look at yet a more simple (radical) approach to user identity. This might use something simpler than SAML assertions, or might be SAML assertions in self-assertion mode.
  9. Do we need to further restrict SAML transactions. (ex. Single Logout)?
  10. How will this change if we institute a federated XDS Registry where the initial XDS Query transaction may be reflected and spread to multiple other Registries and possibly further?

I expect that there will be some proposals of how we can accomplish the above that we can discuss Tuesday morning.

HIMSS, IHE, Internet2, and Liberty Breakfast Panel and 2007 plan

February 28, 2007: There was a meeting sponsored by IHE, HIMSS, Internet 2, and Liberty Alliance to discuss the issues facing the healthcare industry around identity. This was organized by Michael J. McGill, PhD from Internet2.

Presentations by:

  • Holt Anderson: Executive Director of NCHICA
  • William Weems: The Texas Medical Center approach
  • John Moehrke: On the IHE process and vision for XUA

This discussion very much made it clear that Policies must worked on. Technical solutions, no matter how elegant or complete, will fail without clear and agreed policies. There is a workgroup between Liberty Alliance and HIMSS that may be a very good place to help gather policy lessons learned and to help create boiler plate policies. It is this combined Policy work with the IHE Technical work that will make this successful.

January 29, 2007 -- Meeting Notes

Detailed Profile Proposal for XUA January, 2007 : John Moehrke

Notes:

  • Will focus on XDS Stored Query and the new XDS Web-Services Retrieve
    • Need to show how future work will fill in other transactions
  • Relies on the updated Web-Services clarifications also taking place this year
  • Need only profile WS-I Basic Security Profile 1.1
    • Use SAML Assertions -- don't need to specify SAML Protocols
  • Need to show how EUA and XUA are related
  • Need to show how the SAML Assertion will be represented in the ATNA Log message
  • Access Controls will NOT be required or specified. XUA should support some reasonable Access Controls.

Open Issues/Questions:

  • How will XUA be published? Important to make it easy for customers to properly ask for the support and for vendors to be clear on what is truly supported.
    • Is it a full profile?
    • Do we change XDS Actors?
    • Do we add XDS Options?
      • Is this a "Global Modular Option"?
        • Might this show up as a profile with no transactions?
    • Do we use IHE Actor Grouping?
    • Is our work this year really "XUA for XDS Consumer"?
  • Will we be forcing WS-Security in all transactions even when no individual user is controlling?
    • For example a system doing a pre-fetch because a patient is scheduled that day

Dec 12, 2006 Face-to-face meeting: IHE XUA, caBIG, Northwestern, and Project Sentinel (Georgetown University)

Dave Channin has observed that these groups are all doing something similar and that IHE may be a good forum to bring them together into a common and interoperable solution. The first use-case that was discussed would be a workstation that needs to interact directly with XDS/XUA while also interacting with caBIG services.

Discussed the IHE solution and XUA path.

Then discussed the caBIG security architecture. In this model there is a service (Dorian) that can interact with SAML assertions (1.1 today but moving to 2.0), and returns Proxy-Certs for the same user to be used with interactions with caBIG. These Proxy-Certs are used in the TLS communications so that the caBIG can attribute the session with a user. caBIG also uses WSRF to provide session based web-services.

It was determined that Dorian could convert an XUA assertion properly. There was some non-optimal solutions for how a caBIG service could convert from the Proxy-Certs back to a SAML assertion for interactions with XUA based services (e.g. XDS). Further investigation is needed but there was some level of confidence that this could be done.

The second, and much harder, use-case is when this workstation interacts with a potential caBIG service that would need to further interact with XDS/XUA. The second use-case is much harder as the caBIG service must be able to be an intermediary for the user credentials. This is complicated because of the caBIG architecture that requires the use of proxy-certs that can not carry with them anything more than the minimal attributes defined by caBIG. Thus converting back to a SAML assertion that can be accepted by the XUA/XDS is very difficult.

Dave Channin will produce more text and diagrams. This project was named "XUA Testbed" (aka the Project Sentinel / Northwestern XUA Pilot.

Dec 5, 2006 -- face-to-face ITI Tech

XUA - Look at XDS Query first year, XDS Retrieve second year. Does query need to be field-able after 1 year? For ATNA purposes, document patient ID can be retrieved by looking up URI in registry. With ATNA there may be an issue with automated pre-fetch. Handle ED differently - different cert per service with different policies. Would MTOM force f-bit encoding (data expansion)?

May want to look at 3 different environments: high, medium, low policy scopes. Should include Roles and Affinity Domain type information. Do not include authentication. What are the interoperability issues? Assertions?

IBM implementation for NHIN - Since Repository doesn't know patient ID, Registry issues timed token for retrieval (illegal in XDS). Thus the Registry acts like an intermediary for repositories. Registry controls access. -- This is not a recommended solution for IHE as the URIs returned by the registry can not be used in documents or in the future. The IHE design is such that the URIs returned can be embedded in documents or used as references in the future (likely by other people).

Discussion on the priority of our transactions to use XUA to help scope the amount of work to do this year (both profile development and product engineering). This discussion focused around using the AHIC Emergency usecase, and recognizing that data use is more important than data export. Thus the query and retrieve are the focus. The query is already a web-service, and thus should be the top priority. But it is recognized that the Retrieve is the more interesting one for two reasons. First it is the one that exposes the high-fidelity data (document vs metadata), second it is the one where the original-enterprise would still be in control as they could be using a local repository. Thus they want to know to whom they are sending the document.

The query is more likely to be automated (pre-fetch) based on an ADT, Order, or Schedule and thus less likely to be able to provide a human user identity. The Retrieve however is more likley to be a human selecting from previously pre-fetched query.

If we update the XDS-Retrieve transaction to a Web-Service, then the XUA work should include both the query and the retrieve.

Plan as of December 2006

  1. The use-cases need to be updated to be more clinical and less technical
    1. To better communicate what we are providing
    2. To better uncover the requirements for the transactions
  2. Maturity concerns
    1. There still is very limited support for SAML 2.0. The vendors are all working on it. The SAML community is all unified that 2.0 is the right one for future work. The problem appears to be vendors trying to get some revenue on existing development.
    2. WS-I and WS-SX appear to be maturing on target.
  3. decide scope
    1. are we only going to focus on web-services transactions? (no support for HL7 v2 MMLP or dicom or wado or RID)
    2. we should focus year one on XDS-Query with an assumed Affinity domain Policy.
    3. Strong (Charles) request to include XDS-Retrieve as well.
      1. Would likely need to have a WS version of Retrieve. Where the old HTTP-GET retrieve never supports user (XUA) identities, where the new one has support.
      2. HITSP Emergency Responder usecase – repository wants to know the user identity that it is handing over information to.
    4. There is evidence that the XDS-Query is more likely to be done by an automated process, where as the XDS-Retrieve is more likely to be attributable to a specific user.
  4. Produce a roadmap that shows how to get this done in multi-year.

References

Normative

See Cross-Enterprise_User_Assertion_Profile#Data_Standards

Informative

[1]

FYI

FYI: Ping Identity white paper

Again, some interesting input to our work.

White Paper From Ping Identity Corp: February 2007, Internet-Scale Identity Systems, An Overview and Comparison

http://www.pingidentity.com/InternetIdentity010707b.pdf

ZXID Version 0.8: A C library Implementing the Full SAML 2.0 Stack

John: This is not an endorsement, but simply pointing at what might be a useful toolkit.

Sampo Kellomaki, Software Announcement

ZXID is a C library that implements the full SAML 2.0 stack and aims to implement all popular federated ID management protocols such as Liberty ID-FF 1.2, WS-Federation, WS- Trust, and ID Web Services such as Liberty ID- WSF 1.1 and 2.0.

http://freshmeat.net/projects/zxid/?branch_id=65768&release_id=245917

SAML Single Sign-On (SSO) Service for Google Apps

Google Apps offers a SAML-based Single Sign-On (SSO) service that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar.

More at http://code.google.com/apis/apps/sso/saml_reference_implementation.html

See also the demo: http://code.google.com/apis/apps/sso/saml_static_demo/saml_demo.html

January 22, 2007 -- OpenID vs SAML OpenID had been the topic of a few conversations, and then I find two nice articles on the topic. I think the choice is still clear that IHE must use SAML.

Comparison: OpenID and SAML Jeff Hodges, Draft Technical Report Version -00

http://www.xmlgrrl.com/blog/archives/2007/01/21/openid-and-saml-a-swirling-nexus/ OpenID and SAML: A Swirling Nexus] Eve Maler, XML Grrl Blog

January 10, 2007 -- Good news in the industry

Liberty Alliance, Microsoft Discuss Identity Protocols Jeremy Kirk, InfoWorld

Pilot Projects

There are a few pilot projects that we are working with to gather lessons-learned so that the XUA profile can be better.

Middle East Technical University, Turkey

See Implementation Experiences On IHE XUA and BPPC December 5, 2006; Tuncay Namlı and Asuman Dogac, Software Research and Development Center, Middle East Technical University, Ankara, Turkey

Also at http://www.srdc.metu.edu.tr/publications

Project Sentinel / Northwestern XUA Testbed

Georgetown University in collaboration with Northwestern Univeristy. We plan to modify the OHF IHE Document Consumer and the NIST Registry to support SAML assertions. The plan is to demonstrate this at RSNA 2007 Annual Meeting. A proposal for such a demonstration has been submitted to the RSNA Radiology Informatics Committee for their consideration at their Feb 2007 planning retreat.

Meeting Notes:

December 12th, 2006

Eclipse Open Healthcare Framework

Don ??

HIMSS - GSA Pilot

PKI in Health Care: HIMSS/GSA E-Authentication Pilot Project

Participating RHIOS

  1. e-Health Connecticut
  2. Michigan Data Sharing & Transaction Infrastructure
  3. CHRISTUS Health of Texas
  4. Community Health Information Collaborative (Minnesota)
  5. Nevada Single Portal Medical Record
  6. Ohio Supercomputer Center Bioinformatics
  7. Virtual Medical Network (Cincinnati, Ohio)

See Presentation given to University of Minnesota's Health Informatics graduate program Dec, 2006, Pete Palmer and John Fraser

European Pilot

Emmanuel to fill in this section

Retrieved from "http://wiki.ihe.net/index.php?title=Cross-Enterprise_User_Assertion_-_Discussion&oldid=3512"