Cross-Enterprise User Assertion (XUA) Profile

Introduction

This is a draft of the Cross-Enterprise User Assertion Profile (XUA) supplement to the ITI Technical Framework. This draft is a work in progress, not the official supplement or profile. The official versions for Trial Implementation is published in PDF form to assure that public comments received are easily located.

Approved Trial Implementation July 26, 2007: ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr5-2007-2008/Technical_Cmte/Profile_Work/XUA/IHE_ITI_TF_Supplement_XUA_TI_Approved_2007-07-26.doc

This profile supports the security/privacy model discussed in IHE Security and Privacy for HIE white paper.

Profile Abstract

The 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 the receiver can 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.

This profile will likely take two years. In the first year we will be focusing only on XDS.b Registry Stored Query and Retrieve Document Set transactions. The motivator for this is that these are the most exposed transactions that IHE has defined; their use is expected to be from a wide variety of consuming applications and enterprises; and they utilize modern Web-Services standards.

Open Issue Log

XUA001

In first year there are no required mandatory communications of Attributes. This includes any form of functional or structural role. The main reason is the lack of a globally accepted vocabulary, mechanisms to rationalize with local Role-Based Access Control (RBAC) infrastructures, and an unclear set of use-cases that can be used to properly architect. It is noted that an Affinity Domain can choose to add attributes.

XUA002

Support for IHE-XCA is out-of-scope. A user using an Initiating Community-Gateway needs to provide a user assertion that can be utilized by the Receiving Community-Gateway. Where the Cross-Community-Gateway needs to act-on-behalf of the requester, this will require that the Assertions can be re-purposed (delegation) for the next Gateway or Registry

XUA004

Break-glass is out of scope and needs not be supported by XUA. E.g. Doctor in an emergency situation requests to retrieve documents that would under normal conditions would not be accessible because the patient privacy consent has restricted access. Break-glass, in this case, is a consent management related capability.

XUA005

XUA does not specify how the X-Service User obtains the Assertion. XUA does not specify how the X-Service Provider would obtain attributes not included in the Assertion provided. These operations are specific to environments and are well profiled by other organizations (OASIS, Liberty Alliance, etc)

For further discussion and review of the closed issues, see the discussion on the IHE Wiki http://wiki.ihe.net/index.php?title=Cross-Enterprise_User_Assertion_-_Discussion

Glossary

Add the following items to the Glossary 

XUA

Cross-Enterprise User Assertion (Formerly Cross-Enterprise User Authentication)

User Assertion

a set of claims about an authenticated principal (user, application, system...) that is issued by an identity provider

Principal

An end user, an application, a machine, or any other type of entity that may act as a requester in a transaction. A principal is typically represented in a transaction with a digital identity and the principal may have multiple valid digital identities to use with different transactions

X-Assertion Provider

This is a SAML Identity Provider (IDP) or WS-Trust Security Token Service (STS), and is not further specified by IHE.

Volume I

Add the following bullet to the list of profiles in section 1.7 

• The 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 the receiver can 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.

Dependencies

Add the following row(s) to the list of dependencies in section 2.1

Integration Profile	Dependency	Dependency Type	Purpose
Cross-Enterprise User Assertion	None	None

Add the following section to the section 2.2

2.2.n Cross-Enterprise User Assertion (XUA)

Cross-Enterprise User Assertion (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 the receiver can 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.

Add the following section to Vol 1

13 Cross-Enterprise User Assertion (XUA) Integration Profile

The Cross-Enterprise User Assertion Profile (XUA) provides a means to communicate claims about 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 user in a way that the receiver can make access decisions and proper audit entries. The XUA Profile supports many solutions including enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, and others that have chosen to use a third party to perform the authentication.

There are transactions defined by IHE that cross enterprise boundaries. The first year development on XUA will focus on the XDS.b Document Consumer transactions with thought on how this solution would be applicable to other transactions. 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. Identity Federation supports:

• A Country that delegates the provisioning of all users into a single assigning authority domain (e.g., France) and provides a common service that handles all user authentication requests
• Support for centralized user directories
• A Region that knits together a network of cooperating hospitals and clinics where each hospital/clinic manages their own users.
• Support for distributed user directories
• A Patient that wishes to use an identity provider of their choosing (e.g. ISP, email provider).
• Support for non-healthcare specific user directories
• A Hospital that provisions users by issuing identity badges with picture and name printed, RFID for building access, and smart-card for strong authentication
• Support for claims about the method used to authenticate the user (e.g. strong authentication methods such as smart-cards)
• A Small clinic in a rural setting supports a dozen users.
• Support for small scale systems (e.g., user at a kiosk, system using simple passwords)
• A General practice doctor retrieving results of a test performed by an outpatient clinic, where the outpatient clinic wants to have an audit trail specific to the user requesting the information.
• Support for the service provider to get a user identity for audit log purposes
• An automated System, based on a scheduled procedure, that is capable of being a delegate for a doctor pre-fetches the available documents so that it can determine a relevant few documents to offer to the doctor when the patient arrives

The XUA Profile leverages Web-Services Security, SAML 2.0 Token Profile and the various profiles from W3C, OASIS, and WS-I to support identity federation. In this way we will be able to take advantage of the vast experience of the communities outside of healthcare standards. This profile leverages the experience of programs around the globe that have started work with SAML in healthcare.

13.1 Use Cases

The XUA profile supports complex environments, for example one where two different trust domains are operating under different technology, procedures, role-models, etc. They are cooperating in the XDS Affinity domain under an overarching trust relationship policy (See Vol 2, Appendix L) that indicates that these differences can be rationalized. The XDS transactions are transferring control from one entity to another. For example, when using XDS to exchange data between a single doctor practice and large multi-site hospital. It is not likely that they will all agree to the same access control model (organizational roles, functional roles, workflows, permissions, etc). It is not necessary to have the same access control across these entities, but it is reasonable that at the policy level they will agree to a set of processing rules. This illustrates an important fact that the XUA is useful for security audit logging, but is to a lesser extent useful for access controls.

The following is a list of use-cases that have been proposed for XUA. In the first year some of these use-cases will not be supported due to lack of standards or sufficient guidance on the proper solution.

1. Country that provisions users into a single assigning authority domain (e.g., Germany) and handles all user authentication requests
   • Support for centralized user directories
2. Region that knits together many competing hospitals and clinics where each hospital/clinic manages their own users.
   • Support for distributed user directories
3. Patient that wishes to use their email provider as their authentication authority uses a PHR like application to access their own information in an XDS Affinity Domain.
   • Support for non-healthcare specific user directories
4. Hospital issues identity badges with picture and name printed, RFID for building access, and smart-card for strong authentication
   • Support for claims about the method used to authenticate the user (e.g. strong authentication methods such as smart-cards)
5. Small clinic in a rural setting supports a dozen users.
   • Support for small scale systems (e.g., user at a kiosk, system using simple passwords)
6. General practice doctor retrieving results of a test performed by an outpatient clinic, where the outpatient clinic wants to have an audit trail specific to the user requesting.
   • Support for the service provider to get a user identity for audit log purposes
7. System, based on a scheduled procedure, pre-fetches the available documents so that it can determine a relevant few documents to offer to the doctor when the patient arrives.
   • Support for identifying the user as the system for tasks that are not initiated by a human user
8. User using Registry or Repository where the service provider wants to 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 requester 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.
9. Specialized XDS Affinity Domain 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 identity provider for First Responders. (See RSA Pilot)
   • In this case only a user identity with proper linkage to a trusted identity provider is needed. No specific attributes are needed.
10. User acting in an identified clinical role accesses the Registry where the Registry wants to know the user identity and the role they are acting in to record the identity and role in the audit log.
    • Support inclusion of functional roles as named vocabulary
    • The Role of the user as the data subject (patient)
11. Service provider wants to enforce some form of access controls based on the user identity and/or functional role.
    • Support for the service provider to augment access controls based on some non-specified rules that are applied to the user and/or functional role
12. Access to a document by an individual that can’t be identified because the Assertion Provider is not accessible

13.2 XUA Development

The vast majority of the use-cases (items 1-11) rely on claims about an authenticated identity, which a SAML 2.0 Identity Assertion can provide. This is a mature standard produced by OASIS. The first year of XUA Profile development is focused on the two Web-Services transactions of the XDS.b Document Consumer Actor. 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.

13.4 Actors/Transaction

Figure 13.4-1 shows the actors directly (Bold and Solid Boxes) involved in the XUA Integration Profile and the relevant transactions between them (Bold and Solid Line). The diagram also shows ancillary actors (Dashed and Grey Boxes) that are not profiled but include interactions (Dashed and Grey Lines). Actors grouped with are shown as the dashed line between the X-Service User and the X-Service Provider.

Figure 13.4-1 Cross-Enterprise User Assertion Actor Diagram

Table 13.4-1 lists the transactions for each actor directly involved in the XUA Profile. The ancillary actors and associated transactions may be supported by various technologies and system configurations varying from internal shared services to infrastructures for identity management.

In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed in Volume I, Section 13.5.

Table 13.4-1 Cross-Enterprise User Assertion Actors and Transactions

Actor	Transaction	Optionality	Section
X-Service User	Provide X-User Assertion	R	ITI-40
X-Service Provider	Provide X-User Assertion	R	ITI-40

13.5 Options

Options that may be selected for this Integration Profile are listed in the table 13.5-1 along with the Actors to which they apply. Dependencies between options when applicable are specified in notes.

Table 13.5-1 Cross-Enterprise User Assertion Options

Actor	Option	Section
X-Service User	None
X-Service Provider	None

13.6 Grouping

13.6.1 Audit Trail and Node Authentication (ATNA)

The X-Identity Assertion is valuable and must be protected against confidentiality risks. In XUA scope for this year (e.g. XDS), there is already an inherited requirement to group with IHE-ATNA Secure Node Actor. This grouping forces the network transactions to utilize mutually authenticated and encrypted TLS. This is leveraged by XUA to support the protection of the X-User Assertion to some risks to confidentiality and integrity. When ATNA Secure Node grouping is not required, there will need to be some other mechanism to protect the Provide X-User Assertion.

Volume 2 includes encoding rules for representing an X-User Assertion in an ATNA Audit Message.

13.6.2 Cross-Enterprise Document Sharing (XDS)

For the first year, XUA is scoped to specifically the XDS.b Registry Stored Query and Retrieve Document Set transactions. The XUA profile supports grouping with the XDS.b Document Consumer, XDS.b Document Registry, and XDS.b Document Repository.

When an XDS.b Document Consumer is grouped with X-Service User Actor, the XDS.b Document Consumer must conform to all the requirements in the Provide X-User Assertion Transaction. The Document Consumer will obtain a properly scoped XUA Assertion targeted for the XDS.b Document Registry or XDS.b Document Repository. The method used may be through internal means, SAML 2.0 Core protocols, WS-Trust, or any other means.

The XDS.b Document Registry and XDS.b Document Repository when grouped with the XUA X-Service User Actor must conform to all the requirements in the Provide X-User Assertion Transaction. The XUA Profile does not constrain how the Assertion can be used (e.g. ignored, access control, etc).

13.6.3 Enterprise User Authentication (EUA)

An application that groups EUA and XUA Actors may use WS-Trust to get the X-User Assertion from the Security Token Service (STS). This conversion from one security token format to another is documented in the WS-Trust standard, and not further profiled by IHE.

13.7 Process Flow

Figure 13.6-1 Cross-Enterprise User Assertion Process Flow

In the above flow we are showing more actors than are specified in this profile. This is a diagram showing a possible grouping with IHE-EUA (User Authentication Provider), IHE-PWP (User Directory Provider), and a SAML Identity Provider (X-Assertion Provider). The User Authentication Provider, User Directory Provider and X-Assertion Provider are not profiled here, but rather are shown to give a context to the XUA transactions.

In this figure the dark lines represent the X-User Assertion transaction. The dashed lines represent other standards based transactions that may be used. Web-Services session A and B show an example where one X-User Assertion is used to cover two Web-Services transactions. Where Web-Services Session C is using a different X-User Assertion. This may be due to a different user, timeout of the previous X-User Assertion, or some other reason.

13.8 Actor Definitions

Add the following Actor Summary Definitions in Appendix A 

X-Service User

System making a services request of an X-Service Provider.

X-Service Provider

System providing a service that needs a X-User Assertion.

13.9 Transaction Definitions

Add the following Transaction Summary Definitions in Appendix B 

Provide X-User Assertion

This transaction provides a trustable user assertion from the service user to the service provider

13.10 Security Considerations

The security risk assessment for XUA enumerates assets, threats, and mitigations. The security risk assessment for the Actors that are grouped (e.g. Registry Stored Query and Retrieve Document Set) with the XUA Actors are out of scope of the XUA profile, please look at those transactions for the Security Considerations. The complete risk data are stored and available from IHE. The purpose of this risk assessment is to notify vendors and healthcare providers of some of the risks that they are advised to consider in implementing XUA Actors. For general IHE risks and threats, please see Vol 1 appendix L. The vendor is also advised that many risks can not be mitigated by the IHE profile and instead responsibility for mitigation is transferred to the vendor, and occasionally to the affinity domains, individual enterprises and implementers. In these instances, IHE fulfills its responsibility to notify affected parties through the use of the following sections.

13.10.1 Recommendations

The current use of the XUA profile is only specified with XDS.b Registry Stored Query and Retrieve Document Set. These Actors already require the grouping with Actors from ATNA and CT. ATNA provides for channel protection against risks to confidentiality, integrity and authenticity. The applications implementing the X-Service User and X-Service Provider need to process and handle the XUA Identity Assertion carefully to protect the Identity Assertion against threats to confidentiality, integrity and authenticity.

Volume II

Add the following Transaction to Volume II 

3.40 Provide X-User Assertion

This section corresponds to Transaction ITI-40 of the IHE IT Infrastructure Technical Framework.

3.40.1 Scope

Transaction ITI-40 is used by the X-Service User to pass a claimed identity assertion to the X-Service Provider. The X-Service User and X-Service Provider use the 'X-Assertion Provider' as the third party issuer of the claimed identity assertion.

3.40.2 Use Case Roles

Actor

X-Service User

Role

User of a transaction that requires a Cross-Enterprise User Assertion

Actor

X-Service Provider

Role

Service provider on a transaction that requires a Cross-Enterprise User Assertion

3.40.3 Referenced Standards

3.40.3.1 Normative -- required to use this profile

• OASIS http://www.oasis-open.org/committees/security/.
  • SAMLCore SAML V2.0 Core standard
  • WS-Trust OASIS Committee Draft, "WS-Trust 1.3", September 2006
  • WS-SecureConversation OASIS Committee Draft, “WS-SecureConversation 1.3", September 2006
  • WSS10 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", March 2004.
  • WSS11 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006.
  • WSS:SAMLTokenProfile1.0 OASIS Standard, “Web Services Security: SAML Token Profile”, December 2004
  • WSS:SAMLTokenProfile1.1 OASIS Standard, “Web Services Security: SAML Token Profile 1.1”, February 2006

3.40.3.1 Informative -- assist with understanding or implementing this profile

• IHE Profiles
  • Personnel White Pages Profile
  • Enterprise User Authentication Profile
  • Basic Patient Privacy Consents Profile
• OASIS-OPEN
  • SAML V2.0 Standards http://www.oasis-open.org/committees/security/.
    • SAMLTechOvw SAML V2.0 Technical Overview (a work in progress currently at revision 10)
    • SAML Tutorial presentation by Eve Maler of Sun Microsystems
    • SAML Metadata Version 2.0
• WS-I
  • WS-I Conformance Claim
  • WS-I Basic Security Profile Version 1.1 (Doesn't use SAML 2.0)
  • WS-I Basic Profile Version 1.2 (Doesn't use SOAP 1.2)
• W3C
  • WS-Policy Version 1.2
  • SOAP Version 1.2
  • SOAP W3C Note, "SOAP: Simple Object Access Protocol 1.1", 08 May 2000.
  • SOAP 1.2 W3C Recommendation, "SOAP 1.2 Part 1: Messaging Framework", 24 June 2003.
  • SOAPNorm W3C Working Group Note, "SOAP Version 1.2 Message Normalization”, 8 October 2003.
• ISO
  • ISO/TS 21091 Health informatics — Directory services for security, communications and identification of professionals and patients
  • ISO 17090 Health informatics - Digital Certificates in Healthcare

3.40.4 Interaction Diagram

Figure 40.1-1 X-User Assertion Messages

3.40.4.1 Provide X-User Assertion

The Provide X-User Assertion is profiled to assure interoperability between an X-Service User and an X-Service Provider that need an Assertion about the entity requesting the service. There are many ways to provide an Assertion that are all acceptable and may be used by parties that have agreed to their use.

The Provide X-User Assertion transaction sets some minimal interoperability profiling for this use-case. The Provide X-User Assertion transaction shall be used when there is no other agreed upon policy that would assure User Assertion interoperability (e.g. WS-SecurityPolicy).

The X-User Assertion is specified for the IHE-XDS.b Registry Stored Query and IHE-XDS.b Retrieve Document Set transactions. Use beyond these two transactions is possible but not profiled.

3.40.4.1.1 Trigger

Configuration of the X-Service Provider and X-Service User indicates when the X-User Assertion transaction is necessary.

3.40.4.1.2 Message Semantics

The X-User Assertion must be protected at all times against confidentiality exposure, malicious modification, and trust relationship between those communicating it. The IHE-XDS.b Transactions that we are supporting in XUA already require IHE-ATNA and thus TLS Mutual-Authentication, Integrity, and Confidentiality.

The X-Service User shall include the OASIS Web Services Security (WSS) Header, and shall include a SAML 2.0 Assertion as the security token.

Any ATNA Audit Messages that the X-Service User records in relationship to a transaction protected by the XUA (i.e., XDS.b Registry Stored Query, and XDS.b Retrieve Document Set), shall have the user identity recorded according to the XUA specific ATNA encoding rules (See 3.40.4.2 ATNA Audit encoding). This assures that the X-Service User and X-Service Provider ATNA Audit messages can be correlated at the ATNA Audit Repository.

Any ATNA Audit Messages recorded by Actor grouped with the X-Service User Actor, shall have the user identity recorded according to the XUA specific ATNA encoding rules (See 3.40.4.2 ATNA Audit encoding). For example: The XDS.b Document Consumer Actor records the Query event, this event record will include the identity provided in the XUA Identity Assertion. This assures that the X-Service User and X-Service Provider ATNA Audit messages can be correlated at the ATNA Audit Repository.

The SAML 2.0 Assertion is profiled as follows (bold is used when SAML 2.0 terms are used):

• The Assertion shall contain a Subject. The Subject contains the logical identifier of the principal performing the original service request (person, application, etc.) and remains unchanged through operations acting on the assertion (e.g. proxying the Assertion).
  • The Subject shall contain a SubjectConfirmation element. The bearer confirmation method shall be supported; the holder-of-key method may be supported. These methods are defined in the SAML 2.0 Profile specification, section 3.
• The SAML Assertion Conditions are profiled as:
  • NotBefore shall be populated with the issue instant of the Assertion
  • NotOnOrAfter is not specified by XUA because reasonable time limits are not clear at the IHE Profile level. The Expiration is provided by the X-Assertion Provider and would be variable on an Affinity Domain and/or System level.
  • The assertion shall contain an AudienceRestriction containing an Audience whose value is a URI identifying the X-Service Provider (e.g. XDS Registry, XDS Repository). It may contain an Audience whose value is a URI identifying the Affinity Domain.
  • The Assertion may contain ProxyRestriction and OneTimeUse conditions but XUA actors may ignore these conditions.
• The Assertion shall contain an AuthnStatement specify the AuthnContextClassRef or AuthnContextDeclRef
• The Assertion may contain other statements (e.g. Attributes)
• The Assertion shall be signed by the X-Assertion Provider as defined in SAML Core.

The interface between the X-Service User and the X-Assertion Provider is not specified by XUA. This interface needs to be protected against risks (e.g. exposure of the SAML Token to interception for malicious use). Assertions need to be carefully managed in the X-Service User to ensure they are not exposed in the application code or any subsequent use of the Assertion.

3.40.4.1.3 Expected Actions

The X-Service Provider shall validate the Identity Assertion by processing the Web-Services Security header in accordance to the Web-Services Security Standard, and SAML 2.0 Standard processing rules (e.g., check the digital signature is valid and chains to an X-Identity Provider that is configured as trusted). If this validation fails, then the associated transaction shall behave as an authentication failure (e.g., Registry Stored Query will return zero results), and the ATNA Audit event for Authentication Failure shall be recorded according to ATNA rules.

Any ATNA Audit Messages recorded by Actor grouped with the X-Service Provider Actor, shall have the user identity recorded according to the XUA specific ATNA encoding rules (See 3.40.4.2 ATNA Audit encoding). For example: The XDS.b Registry Stored Query Actor records the Query event, this event record will include the identity provided in the XUA Identity Assertion. This assures that the X-Service User and X-Service Provider ATNA Audit messages can be correlated at the ATNA Audit Repository.

The X-Service Provider may use standards transactions to communicate with the X-Assertion Provider (e.g., WS-Trust, SAML 2.0 Protocol) to obtain information not included in the assertion provided (e.g. Attributes that might be related to structural roles).

The X-Service Provider may utilize the identity in access control decisions. Appropriate error messages, not defined here, shall be returned. The X-Service Provider may ignore any other statements (e.g. Attributes).

The X-Service Provider may use the authentication class references to determine the method that was used to authenticate the user. For example the X-Service Provider may have a configurable list of authentication class references that it is willing to recognize as authentication methods that are acceptable, thus treating other authentication class references as not authorized.

Assertions need to be carefully managed inside the X-Service Provider to ensure they are not exposed in the application code or any subsequent use of the Assertion.

3.40.4.2 ATNA Audit encoding

When an ATNA Audit message needs to be generated and the user is authenticated by way of an X-User Assertion, the ATNA Audit message UserName element shall record the X-User Assertion using the following encoding:

alias"<"user"@"issuer">"

where:

• alias is the optional string within the SAML Assertion's Subject element SPProvidedID attribute
• user is the required content of the SAML Assertion's Subject element
• issuer is the X-Assertion Provider entity ID contained with the content of SAML Assertion's Issuer element