Error: "SAML Subject NameIdentifier missing required NameIdentifier value"

  • 7013221
  • 09-Sep-2013
  • 09-Sep-2013

Environment

NetIQ Access Manager 3.2
NetIQ Access Manager 3.2 Support Pack 2 applied
NetIQ Access Manager 3.2 Identity Server acting as a SAML2 Identity Provider
GoogleApps acting as a SAML2 Service Provider

Situation

Customer was running an older AM 3.1.5 setup doing SAML2 SSO to test a Google apps instance. Everything worked fine with this old AM 3.1 config ie. users could authenticate to the NAM Identity Server and SSO to the GoogleApps server.

The administrator then built a new NAM 3.2 appliance and changed everything over to use my new appliance.  As soon as the config was applied, the administrator could not get SSO to work.  The logs showed the incoming Authentication request generated by the GoogleApps SP, but never saw  the corresponding SAML assertion POSTed from the IdP. The browser reported the following error instead:

"SAML Subject NameIdentifier missing required NameIdentifier value"

The catalina reported the following output in debug mode from the NAM IDP server after processing the incoming AuthnRequest and after validating the users credentials.

Warning: Invalid resource key:          SAML Subject NameIdentifier missing required NameIdentifier value       . No prefix!
Warning: Invalid resource key:          SAML Subject NameIdentifier missing required NameIdentifier value       . No prefix!

<amLogEntry> 2013-09-09T02:12:31Z INFO NIDS Application: AM#500105039: AMDEVICEID#B07E389BB23ACF4B: AMAUTHID#CE4F2451C
30B9F4B44687BA3D442C8ED:  Error on session id CE4F2451C30B9F4B44687BA3D442C8ED, error             SAML Subject NameIdentifier missing required NameIdentifier value       -B07E389BB23ACF4B, Unable to complete request at this time.             SAML Subject NameIdentifier missing required NameIdentifier value        </amLogEntry>

Resolution

Make sure that the user store used during the authentication process includes a value for the NameIdentifier field.

In customers case, they had two different User Stores configured in the old setup - an AD based one and an eDir based one.  The AD was set as the DEFAULT on the old setup.  What we failed to realize was that in the Secure-Name/Password Method, they had CHANGED the user store just for that method to eDir!