Revision as of 08:54, 26 February 2010

History

Profile Supplement Drafts

XUA++ Profile Supplement February 24, 2010

Detailed proposal

XUA Extension detailed proposal November 20, 2009

Use Cases

Role-Based-Access Control: Need to specify a fuller vocabulary of attributes needed for access control decisions.
Consent/Authorization: Need to carry an indicator of BPPC document that is relevant to the transaction
Level Of Assurance for (a) the authentication event, and/or (b) the provisioning of the account
Extended Audit Logging: Support descriptive identifiers to support environments where post-processing doesn’t have access to directory for id translation into description.
Purpose-of-Use: Carry in the assertion purpose-of-use, including support for Break-Glass / Emergency-Mode-Access
Relationship-to-Patient: Carry the indicator of the patient, relationship to patient, location of patient

Detailed Development

Role

XSPA

Structural Role

This is the value of the principal’s structural role Structural roles are described in ASTM E2595-07, Standard Guide for Privilege Management Infrastructure.

Structural roles provide authorizations on objects at a global level without regard to internal details. Examples include authorization to participate in a session, connect authorization to a database, authorization to participate in an order workflow, or connection to a protected uniform resource locator (URL). The structural role is the role name referenced by the patient’s consent directive.

This profile specifies ASTM 1986-98 (2005) Standard Guide for Information Access Privileges to Health Information persons for whom role based access control is warranted as the defined default structural roles to be used in this profile. ASTM E1986 NOTE: At the time of this writing, ASTM E31 is still in the process of completing the formal enumeration ASTM 1986 roles.

Structural roles are specified by reference to an OID. Roles will be typed as strings and an OID will be assigned to each unique structural role authority. The enumerated ASTM E1986 role will be passed with the assertion. Enumerated roles under the OID will be identified through the use of the element

<urn:oasis:names:tc:SAML:2.0:profiles:attribute:XPSA: structural_role> within the assertion.

NHIN

Uses XACML role

3.3.2.5 Role Attribute

This <Attribute> element shall have the Name attribute set to “urn:oasis:names:tc:xacml:1.0:subject:role”. The value of the <AttributeValue> element is a child element, “Role”, in the namespace “urn:hl7-org:v3”, whose content is defined by the “CE” (coded element) data type from the HL7 version 3 specification.

The codeSystem is defined to be “2.16.840.1.113883.6.96" and the codeSystemName is defined to be "SNOMED_CT". The Role Element shall contain the SNOMED CT value representing the role that the NHIN Authorization Framework Specification v 2.0 user is playing when making the request. The value set to be used is “User Role” and the OID 2.16.840.1.113883.3.18.6.1.15

An example of the syntax of this element is as follows: as defined in HITSP C80.

<saml:Attribute Name="urn:oasis:names:tc:xacml:2.0:subject:role">
 <saml:AttributeValue>
  <Role xmlns="urn:hl7-org:v3" xsi:type="CE" code="46255001"
   codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED_CT"
   displayName="Pharmacist"/>
 </saml:AttributeValue>
</saml:Attribute>

The NHIN Trial Implementation “UserRole” attribute has been replaced by the Subject Role attribute defined in this section.

Not sure if this is the same as the XACML and/or SAML RBAC profiles

epSOS

uses XSPA method

Urn:oasis:names:tc:xspa:1.0:subject:role

Also seems to endorse the XSPA permissions mechanism. Should we endorse permissions based methods?

LOA

NHIN uses the native SAML AuthnContext
epSOS - I couldn't find any mention of LoA
XSPA - I couldn't find any mention of LoA
OASIS - sstc-saml-assurance-profile-draft-01.pdf

Security Assessment

Plan

Evaluate the content of the Resources for how well they address the above Use-Cases
Discover new vocabulary that may be used for the above Use-Cases
Further develop the Use-Cases that can be resolved in the next few months, drop the use-cases that do not have mature standards available.
Write up likely use-cases for review at First T-Con (Feb 26, 2010)
Evaluate the use-cases and create logical groupings into Options
Write up logical grouping Options with pointers to likely standards solutions
Review at Second T-Con (March 19, 2010)
Take action items from Second T-Con for Third T-Con (April 9, 2010)

Resources

XUA Predicate Profile that this Extension modifies

OASIS XSPA - SAML

OASIS SAML Assurance Profile Draft

epSOS Experience with XSPA

NHIN Messaging Framework, Authorization Framework

Notes

FTP site for this project

Current NHIN specifications Return to ITI Technical Committee

Difference between revisions of "ITI XUA Extension"