Auth.+Framework-+Incorrect+Issuer

Eric Heflin: This issue is a duplicate with issue #1 in the FAQ issue tracker Google spreadsheet. Closing the issue here. See issue #1 in the spreadsheet for more details including the resolution.

Issue: In the header of request messages, the Issuer element is not being set; instead it is using default values (e.g. CN=SAML User). As described in Section 3.3 of the Authorization Framework, the Issuer element is required to identify the individual responsible for issuing the Assertions carried in the message. This is normally the system security officer for the sending NHIO.
 * [[image:http://www.wikispaces.com/i/user_none_lg.jpg width="48" height="48" caption="JoeLamy" link="http://www.wikispaces.com/user/view/JoeLamy"]] || [|JoeLamy]

After discussing with candidates, some said there was no such person they could identify, and suggested using a role or an email address not assigned to a specific person, or the "unspecified" format, which they took to mean (incorrectly I believe) that the identity was unspecified, rather than the format.

What's the impact? Is this just informational? Required for auditing? Are any of the suggested workarounds acceptable?

Example:  CN=SAML User,OU=SU,O=SAML User,L=Los Angeles,ST=CA,C=US 

Tentative severity level: 2-High [|[delete]] ||


 * Discussion / Response to Testing Team Issue:**

The NHIN Auth Framework specification provides guidance that this would normally be the “system security officer”. The SAML spec just states that this is meant to be the issuers name. I don’t agree with the Auth Framework statement that this is going to be the security officer. I believe this is meant to be the name or a unique identifier of the Identity Provider that issued the assertion (and this may not necessarily be a person’s name) instead of this being the security officer.
 * SAML Assertion/Issuer**
 * Agreed. 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).
 * So the NHIN Spec statement, I think, is incorrect and was the result of a misunderstanding of the intended purpose of the  element.
 * Is there any disagreement on this point?
 * Agree: This is the identity of the identity-provider, not necessarily a human. At best this might be an organization or arm-of-an-organization. I would say that the concept of “less is more” be applied to the verbiage in the AF.

 The NHIN Auth Framework specification indicates that this is the ‘person’ initiating the requesting, while the SAML spec uses the term principal to represent the subject of the assertion. The reason why I am drawing the distinction is that for SSA, this is not an individual person but a back office application that is initiating this request. Currently the Subject of the assertion is the application which is making the request and not an individual.
 * SAML Assertion/Subject**
 * From a non-normative OASIS document: [] “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 it’s clear to me that the subject is intended to indicate an actor, and that the actor can be a human or a computer system. I believe, though, that it is essential that the actor be identifiable with a certain degree of confidence and granularity.
 * For esMD, for example, the CMS is essentially stating that they don’t have any interest in the subject. They only want to know about and trust the gateway. In that case, I’m currently leaning towards suggesting that SAML not be a required element of the SOAP header for their purposes since making a SAML assertion about an unidentifiable actor is of little to no value. Or, that the  be the HIH identifier.
 * Correct. We should see the statement about a person as only informative to a case where the entity is a human. But an entity can be a service or system or… Again, less is more. The underlying standards and profiles have made this clear.
 * I very much agree that some SYSTEMS, as authenticated at the TLS level, can be authorized as a whole-system. Meaning that it is enough to have identified that specific system, and that the SAML assertion would be unnecessary (might actually be seen as a reason to reject the request if it included a SAML assertion). In fact I suspect you will find more and more of these cases. As I expect the uses of a nationWIDE health information network or even a regional HIE will be used more by automated processes than ever directly by a HUMAN. This does NOT detract from the responsibility to trust-but-verify that the SYSTEM is indeed enforcing the appropriate access control rules and is recording the appropriate level of audit events. Those that have been involved with IHE long enough will recognize this as being the complete list of requirements found in ATNA. YES it does require that the node that is authenticated have access controls in addition to the audit logging defined.