|
|
| Line 2: |
Line 2: |
| | | | |
| | | | |
| − | ==Summary== | + | ==Heading 1== |
| | | | |
| − | '''Cross-Enterprise User Assertion Profile (XUA)''' - provides a means to communicate claims about the identity of an authenticated principal (user, application, system...) in transactions that cross enterprise boundaries. To provide accountability in these cross-enterprise transactions there is a need to identify the requesting principal in a way that enables the receiver to make access decisions and generate the proper audit entries. The XUA Profile supports enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, as well as others that may have chosen to use a third party to perform the authentication | + | '''Bold text is encoded in double quotes''' - regular text goes here |
| | + | Note that the table of contents is built automatically, contents of the TOC come from the items in your heading lines |
| | | | |
| | ==Benefits== | | ==Benefits== |
| | | | |
| − | '''Assistance to sites in implementing security and confidentiality policies''' | + | '''More bold text''' |
| − | There are transactions defined by IHE that cross enterprise boundaries and are web-services based on ITI TF-2:Appendix V. The existing IHE profiles for an authenticated user identity (IHE Enterprise User Authentication Profile [EUA]) are not intended to function in cross-enterprise transactions. In a cross-enterprise environment it is more likely that the transactions will be going between two enterprises that maintain their own independent user directories (IHE Personnel White Pages [PWP]). This type of requirement is the focus of the Identity Federation standards. Identity Federation has received much attention by the security and the platforms industry. Identity Federation is agnostic to the type of user directory; it allows for a centralized user directory, but also supports the more powerful federation of user directories.
| + | Another paragraph |
| | | | |
| − | ==Details==
| |
| | | | |
| − | The vast majority of the use-cases rely on claims about an authenticated identity, which a SAML 2.0 Identity Assertion can provide. This is a mature standard produced by OASIS. XUA Profile is focused on Web-Services transactions that follow ITI TF-2:Appendix V. XUA specifies that when a Cross-Enterprise User Assertion is needed, these Web-Services transactions will additionally use the Web-Services Security header with a SAML 2.0 Token containing the identity Assertion. As with any IHE profile, the applications are not forbidden to use other methods of providing the principal (user) identity, providing that interoperability has been assured through some policy.
| |
| − |
| |
| − | A very clear need on all the use-cases is the recording of the user identity in any security audit logs. The XUA profile does not define these auditable events. The need to record a security audit event is driven by the grouped transactions (e.g., XDS.b Registry Stored Query, and XDS.b Retrieve Document Set). XUA does specify how to reference the Identity Assertion in an ATNA Audit Message.
| |
| − |
| |
| − | The method of authenticating the principal (user) and the method that the X-Service User Actor (e.g. XDS.b Document Consumer) uses to get the Identity Assertion are outside the scope of this profile. There are principal (user) attributes that appear to be needed in the use-cases: Doctor, Patient, Guardian, Emergency-Access. The Identity Assertion can contain attributes about the principal (user). At this time it is not clear what standards to use to identify these attributes and their values, so this is left to specific implementations that have defined a local vocabulary or vocabulary translation.
| |
| − |
| |
| − | The method used by the X-Service User (e.g. XDS.b Document Consumer) Actor to determine the contents of the Identity Assertion is outside the scope of this profile. This might be accomplished using the SAML Metadata and WS-Policy.
| |
| − | It is expected that extending this solution to HL7 and DICOM will be supported in the future.
| |
| − |
| |
| − | ==Systems Affected==
| |
| − |
| |
| − | Systems involved in this profile are:
| |
| − |
| |
| − | * Any application or service that utilizes Web-Services transactions.
| |
| | | | |
| | '''Actors & Transactions:''' | | '''Actors & Transactions:''' |
| | | | |
| − | [[image:XUA_Actors_Figure_05.jpg|thumbnail|center|600px|'''Figure 13.4-1 Cross-Enterprise User Assertion Actor Diagram''']] | + | [[image:XUA_Actors_Figure_05.jpg|thumbnail|center|600px|'''This is the name of your figure. We will upload a jpg and point to it in this line''']] |
| | | | |
| | ==Specification== | | ==Specification== |
| | | | |
| − | '''Profile Status:''' [[Comments| Final Text]]
| + | In the next line, you will see how to encode a link. The first part is the web address, then a space, then a phrase that appears as the link on the page |
| | | | |
| | '''Documents:''' | | '''Documents:''' |
| Line 41: |
Line 27: |
| | :* Vol. 2(b) - Sections 3.40 | | :* Vol. 2(b) - Sections 3.40 |
| | | | |
| − | '''Underlying Standards:''' | + | '''Another Header''' |
| − | * OASIS http://www.oasis-open.org/committees/security/. | + | * sample bullet list. 1st level is preceded by a star |
| − | ** [http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAMLCore] SAML V2.0 Core standard | + | ** sub bullet items preceded by 2 stars |
| − | ** [http://docs.oasis-open.org/ws-sx/ws-trust/200512 WS-Trust] OASIS Committee Draft, "WS-Trust 1.3", September 2006
| + | ** another sub bullet |
| − | ** [http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 WS-SecureConversation] OASIS Committee Draft, “WS-SecureConversation 1.3", September 2006
| + | ** another sub bullet |
| − | ** [http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf WSS10] OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", March 2004.
| |
| − | ** [http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf WSS11] OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006.
| |
| − | ** [http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf WSS:SAMLTokenProfile1.0] OASIS Standard, “Web Services Security: SAML Token Profile”, December 2004 | |
| − | ** [http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf WSS:SAMLTokenProfile1.1] OASIS Standard, “Web Services Security: SAML Token Profile 1.1”, February 2006 | |
| − | | |
| − | [[ITI XUA Extension]]
| |
| − | | |
| − | ==See Also==
| |
| − | | |
| − | This profile supports the security/privacy model discussed in [[IHE Security and Privacy for HIE]] white paper.
| |
| − | | |
| − | '''Related Profiles'''
| |
| − | | |
| − | * [[Consistent_Time | Consistent Time]] [CT] ''< supports XUA in some fashion >''
| |
| − | | |
| − | 2010 - [[ITI XUA Extension]] supplement is extending XUA
| |
| − | | |
| − | | |
| − | This page is based on the [[Profile Template]]
| |
| − | | |
| − | [[Category:Profiles]]
| |
| − | [[Category:ITI Profile]]
| |
| − | | |
| − | Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].
| |
| − | | |
| − | There are two articles on this topic. First there is the [[Cross-Enterprise User Assertion - Discussion]]. The profile document is being developed at [[Cross-Enterprise User Assertion Profile]]
| |
