Assertion ID within SAML2 assertion not adhering to core spec uniqueness description

  • 7012148
  • 16-Apr-2013
  • 20-May-2013

Environment

NetIQ Access Manager 3.2
NetIQ Access Manager 3.2 Identity Server acting as SAML2 Identity Provider
3rd party OpenSSO SAML2 Service Provider in trust relationship with NAM SAML2 Identity Provider

Situation

Federated relationship setup between NAM Identity Server and OpenSSO Service Provider using SAML2. Users access the Identity (IDP) Server intersite transfer URL, authenticate successfully and then get single signed on to the SAML2 Service Provider (SP) without problems.

However, if the User then logs out of SAML2 SP (without logging out of the IDP server) before hitting the IDP intersite transfer URL again, the SP returns a 500 error. After looking at the SP logs, it became clear that it was rejecting the new assertion because it is using the same ID as the previous one yet included different information. The second assertion generated by the IDP server (after the user accesses the intersite transfer URL again) showed a new response ID in the message header, but the assertion ID was the same as the previous one. The assertion contents (including the signature) had changed.

Resolution

Apply NAM 3.2 SP1. With each assertion response issued using an intersite transfer URL , either in the same session or in a different session , the "saml:Assertion ID" changes for uniqueness.

Additional Information

The core specs are somewhat confusing, but does reference the need to include a unique identifier.

1.3.4 ID and ID Reference Values
The xs:ID simple type is used to declare SAML identifiers for assertions,
requests, and responses. Values
declared to be of type xs:ID in this specification MUST satisfy the following
properties in addition to those
imposed by the definition of the xs:ID type itself:
• Any party that assigns an identifier MUST ensure that there is negligible
probability that that party or
any other party will accidentally assign the same identifier to a different
data object.
• Where a data object declares that it has a particular identifier, there MUST
be exactly one such
declaration.
The mechanism by which a SAML system entity ensures that the identifier is
unique is left to the
implementation. In the case that a random or pseudorandom technique is
employed, the probability of two
randomly chosen identifiers being identical MUST be less than or equal to 2-128
and SHOULD be less than
or equal to 2-160. This requirement MAY be met by encoding a randomly chosen
value between 128 and 160 bits in length. The encoding must conform to the
rules defining the xs:ID datatype. A pseudorandom
generator MUST be seeded with unique material in order to ensure the desired
uniqueness properties
between different systems.
The xs:NCName simple type is used in SAML to reference identifiers of type
xs:ID since xs:IDREF
cannot be used for this purpose. In SAML, the element referred to by a SAML
identifier reference might
actually be defined in a document separate from that in which the identifier
reference is used. Using
xs:IDREF would violate the requirement that its value match the value of an ID
attribute on some element
in the same XML document.
Note: It is anticipated that the World Wide Web Consortium will standardize a
global
attribute for holding ID-typed values, called xml:id [XML-ID]. The Security
Services
Technical Committee plans to move away from SAML-specific ID attributes to this
style of
assigning unique identifiers as soon as practicable after the xml:id attribute
is
standardized.