2 Replies Latest reply on Oct 10, 2013 3:56 PM by bandersen

    SSO error: NameID element must be present as part of the Subject in the Response message


      Has anyone else experienced this exception when attempting to authenticate by means of SSO through a SAML 2 IdP?


      org.opensaml.common.SAMLException: NameID element must be present as part of the Subject in the Response message, please enable it in the IDP configuration


      The scenario I am experiencing is similar to that documented here:




      However, rather than using ADFS as an IdP, I am using Shibboleth (version 2.4.0).  Both Jive (version and Shibboleth are hosted on systems running CentOS 6.4.  They reside on the same physical hardware, although the Shibboleth instance is operating in a virtual machine.


      I have attempted nearly everything suggested in the abovementioned case (which, btw, appears to have had no resolution) and have yet to have success.  Even overriding the use of the subject NameID value for use as the external identifier and username -- both in favor of attributes I explicitly define, expose and submit within the Shibboleth IdP's attribute-resolver.xml and attribute-filter.xml configuration files -- does not resolve the problem.


      As a workaround in my development, I am setting a breakpoint in my debugger and explicitly specifying a value for the NameID element (which consistently is null) before it is checked for a value.  This is fine (albeit inconvenient) for development purposes, but isn't a workable solution in a production environment.


      I've attached the debug output I am receiving when attempting to authenticate, with the "NameID element must be present ..." exception message toward the very bottom.  If anyone can shed light on this error and help me find a resolution, it would be greatly appreciated.

        • Re: SSO error: NameID element must be present as part of the Subject in the Response message

          Brad, I have Shibboleth working well with Jive.


          Here is the NameID attribute definition from my attribute-resolver.xml file:

          employeeNumber is a user attribute pulled from ActiveDirectory. The attribute could just as easily be samaccountname


          You can see the employeeNumber value is mapped to NameId in the AttributeEncoder element...


              <!-- Schema: Core schema attributes-->

              <resolver:AttributeDefinition xsi:type="ad:Simple" id="employeeNumber" sourceAttributeID="employeeNumber">

                  <resolver:Dependency ref="myLDAP" />

                  <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"  />


          Also, you must make the underlying attribute (employeeNumber in this case) available for use in the AttributeFilterPolicy in your attribute-filter.xml file:


          <afp:AttributeFilterPolicy id="releaseCustomIdToPartner">

          <afp:PolicyRequirementRule xsi:type="basic:ANY"  />

          <afp:AttributeRule attributeID="employeeNumber">

              <afp:PermitValueRule xsi:type="basic:ANY" />


          <afp:AttributeRule attributeID="mail">

              <afp:PermitValueRule xsi:type="basic:ANY" />


          <afp:AttributeRule attributeID="first_name">

              <afp:PermitValueRule xsi:type="basic:ANY" />


          <afp:AttributeRule attributeID="last_name">

              <afp:PermitValueRule xsi:type="basic:ANY" />



          Please let me know if any of this helps you.

            • Re: SSO error: NameID element must be present as part of the Subject in the Response message

              Unfortunately I'm no closer to a resolution, John.  Thanks, though, for taking the time to share your configuration.


              My configuration associated with the NameID attribute is strikingly similar to yours, with the primary difference being the source of the attribute's value.  You retrieve yours from a directory service, while I hard code a value (for testing purposes) directly in the attribute-resolver.xml file:

              <resolver:DataConnector id="dcnameid" xsi:type="dc:Static">

                  <dc:Attribute id="nameid">




              The attribute definitions are seemingly the same; both use SAML2StringNameID as the attribute encoding type:

              <resolver:AttributeDefinition xsi:type="ad:Simple" id="adnameid" sourceAttributeID="nameid">

                  <resolver:Dependency ref="dcnameid" />

                  <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"



              The policy associated with the attribute filter is about as relaxed and accommodating as possible:

              <afp:AttributeFilterPolicy id="afpnameid">

                  <afp:PolicyRequirementRule xsi:type="basic:ANY"/>

                  <afp:AttributeRule attributeID="nameid">

                      <afp:PermitValueRule xsi:type="basic:ANY" />



              As many configuration scenarios as I've tried -- both in the Shibboleth IdP configuration files as well as the Jive SP SSO user interface -- I'm beginning to suspect that this is not a case of user error, but something more rooted in Jive.