Start a conversation

Jive 13.0 SAML User Attribute Mapping Page Does Not Show IdP Attribute Name URL List (UI Change)

Overview

After upgrading from Jive 9.21 to Jive 13.0, the SAML User Attribute Mapping page may no longer display a selectable/reference list of IdP Attribute Name URLs after saving IdP metadata. The IdP metadata field may also appear as an unformatted block/blob instead of pretty-printed XML.

This behavior has been validated as different between Jive 9.x and Jive 12.x / 13.x and appears to be a UI/formatting/behavior change. It does not inherently prevent SSO from working as long as attribute mappings use the IdP’s SAML assertion Attribute Name values (not FriendlyName).

Solution

What matters functionally (key concept)

  • Jive SAML attribute mapping must match the IdP’s SAML assertion Attribute Name values.
  • Do not map to Attribute FriendlyName if it differs from Name.
  • Some IdPs (commonly ADFS) use URL-like claim URIs for Attribute Name values, for example:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email

Affected versions (validated)

  • Jive 9.21: saving IdP metadata can surface a reference list of IdP attribute Name URLs on the mapping page.
  • Jive 12.x / Jive 13.0: metadata may display as a block and the attribute URL reference list may not be shown.

Workaround: Discover Attribute Name values from the SAML response

If the UI does not provide an attribute reference list, use a controlled mapping failure to reveal which attributes your IdP is actually sending.

  1. Open SAML configuration
    • Admin Console → People → Settings → Single Sign-On → SAML → General
  2. Temporarily set an invalid Email mapping
    • Set the Email mapping value to something you are confident is not present in the SAML assertion (example: xxxxemail.).
    • Save changes.
  3. Attempt SSO login once
    • Run your normal SSO flow (IdP-initiated or SP-initiated).
  4. Capture the resulting SSO error output
    • The failed attempt should produce an SSO error that exposes which attributes were present in the SAML response.
    • Record the Attribute Name values shown/listed in that error output.
  5. Update mappings to the correct Attribute Name values
    • Return to the SAML mapping page and update:
      • Email mapping
      • First Name mapping
      • Last Name mapping
    • Use the recorded Attribute Name values (not FriendlyName).
    • Save changes.

Validation (confirm the fix)

  1. Perform another SSO login attempt.
  2. Confirm:
    • User authenticates successfully.
    • The correct user is matched/created (email).
    • Profile fields populate correctly (first name/last name).
  3. If login still fails, re-check that:
    • You used Attribute Name values (not FriendlyName).
    • The IdP is actually sending the attributes you are trying to map (the SAML response must contain them).

Notes / expectations

  • No specific SSO runtime error text is required to begin troubleshooting; the steps above intentionally generate a useful error to reveal the attributes being sent.
  • The missing “reference list” and the unformatted metadata “blob” in Jive 12.x / 13.0 are consistent with a UI/behavior change and do not necessarily indicate a broken SAML configuration.
  • No engineering fix or defect ID is documented for this UI behavior change.

Frequently Asked Questions

1. How do I know I’m experiencing the same issue?
You’ll see that after saving IdP metadata in Jive 13.0, the User Attribute Mapping page does not display a reference list of IdP Attribute Name URLs (even though Jive 9.21 did). The metadata field may also appear as an unformatted block.
2. What exact error message should I look for?
No exact error text is required. To generate a useful error, temporarily set the Email mapping to a value that won’t exist (for example xxxxemail.), attempt SSO once, and then use the resulting SSO error output to identify the attributes included in the SAML response.
3. Do I map “FriendlyName” or “Name” from the SAML assertion?
Map the SAML assertion Attribute Name values. Many IdPs include both Name and FriendlyName, and Jive expects the Name value.
4. Does the unformatted metadata “blob” mean my SAML configuration is broken?
Not necessarily. The metadata display formatting in Jive 12.x / 13.0 can appear as a block and may not affect SSO functionality. Validate by confirming the IdP metadata is correct and by mapping to the Attribute Name values actually sent in the SAML response.
5. What if SSO still fails after updating the mappings?
Re-run the controlled failure method to confirm which attributes are truly being sent, and verify the IdP is configured to include the required attributes (email/first name/last name). If the required attributes are absent from the SAML response, they must be added on the IdP side before Jive can map them.
Choose files or drag and drop files
Was this article helpful?
Yes
No
  1. Priyanka Bhotika

  2. Posted

Comments