I’m looking for anyone who has integrated their NERM Collaboration Portal with Shibboleth for SSO authentication before.
I have done dozens of integrations with Okta and Azure, even a few ADFS, but I’ve encountered what seems like a complete roadblock with Shibboleth. Since NERM requests the Persistent format for NameID, the value is being hashed, so instead of getting the Employee Number we get an encrypted value, which is breaking the authentication.
Any insights on how to get Shibboleth or NERM to play nicely with the other would be appreciated.
I have researched your use case with NERM against Shibboleth’s; below are my findings.
Why this happens
Options to try
Conclusion
Why this happens
NERM requirement: NERM expects a stable identifier (often Email or EmployeeNumber) as the SAML NameID.
Shibboleth persistent NameID: By design, Shibboleth generates opaque, pairwise values for urn:oasis:names:tc:SAML:2.0:nameid-format:persistent. These are not human‑readable and differ per service provider.
Result: NERM receives a hashed value instead of the employee number, breaking correlation
Options to try
Change NameID format
Configure Shibboleth to send urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or emailAddress.
Map the NameID to employeeNumber or mail in attribute-resolver.xml.
This ensures NERM receives a usable identifier.
Use Attribute Mapping in NERM
Keep Shibboleth’s persistent NameID but configure NERM to use another attribute (like employeeNumber) for identity mapping.
This requires NERM’s SAML configuration to accept attributes beyond NameID.
Conclusion
Shibboleth’s persistent NameID is intentionally opaque and will not work as an employee number. The supported solution is to configure Shibboleth to release a usable attribute (email or employeeNumber) as NameID or adjust NERM to map another attribute instead.
Note: Persistent NameIDs are designed to protect privacy. Switching to employeeNumber or email may expose identifiers across SPs.