Exchange+Security+FAQ

=**Issue:** Nationwide Health Information Network Exchange Security Approach Guidance=

Implementers (such as CONNECT), technical leads, architects, software engineers Security Architects Testers (ONC test team)
 * Target Audiences:**


 * Frequently Asked Questions**

Topic Area: SAML Attribute Usage


 * Q**: 1. Regarding the SAML Assertion/Issuer – The Nationwide Health Information Network Auth Framework specification provides guidance that this would normally be the “system security officer”. The SAML specifications state that this is meant to be the issuers name. Is this attribute the security officer or the SAML Assertion Provider?


 * A**: The actor that creates the SAML assertions, normally called the SAML “asserting party”, should be specified in the  element of the SAML assertion. (An “identity provider” is one type of asserting party.) So the  element should be the identity of the asserting party and it should uniquely identify the asserting party. The asserting party identifier then would normally be found in a white list of trusted asserting parties at the relying party’s implementation. The x.509 digital signature would allow the relying party to confirm the authenticity (and integrity) of the message (that it indeed came from the trusted asserting party, and that the message was not modified).

Q: The Issuer element includes a NameID Format attribute which declares the format used to express the value contained in this element. Table 2 lists all SAML 2 NameID formats. [my read of SAML section 8.3 indicates this list does not apply to the Subject element by the way]. All of the Nationwide Health Information Network examples demonstrate the X509 format. Where does one find the specification for the x509 format? > SAML 2.0 section 8.3.3 points to XMLSig] > XMLSig section 4.4.4 states that "The X509SubjectName element, which contains an X.509 subject distinguished name that SHOULD be represented as a string that complies with section 3 of RFC4514 [[|LDAP-DN]], to be generated according to the [|Distinguished Name Encoding Rules] section below > RFC4514 Section 3 lists strings and attribute types A review of this chain of references does very little to provide any context as to the use of this name format, or to it requirements.


 * Q**: 2. Must the SAML Assertion/Subject be a human, or can it also be a computer or automated process?


 * A**: From a non-normative OASIS document: http://www.oasis-open.org/committees/download.php/14361/sstc-saml-tech-overview-2.0-draft-08.pdf

“What are the entities involved in a SAML interaction? At the heart of most SAML assertions is a subject (a principal – an entity that can be authenticated – within the context of a particular security domain) about which something is being asserted. The subject could be a human but could also be some other kind of entity, such as a company or a computer. (The terms “subject” and “principal” tend to be used interchangeably in this document.)”

So the subject element specified in Section 3.3, #5 is intended to indicate an actor, and that the actor can be a human or a computer system. It is essential that the actor be identifiable with a certain degree of confidence and granularity otherwise the SAML subject attribute has limited value. [Can this same guidance be applied to the SubjectID attribute in the Attribute Statement? ]

Closing this as it is a duplicate of the Google Docs spreadsheet issue #1. Please reference that document for the resolution of this issue (which, as of this writing, is updated text clarifying that the  should be a system, not a person, in most cases).

Eric Heflin, Nationwide Health Information Network Spec Factory, Security and Privacy Workgroup Chair
 * Contributors To This Page:**