SSO Configuration Issues with Okta + NERM Setup

kalyan_dev32 · May 20, 2025, 4:08am

Hi everyone,

I’ve been working on configuring SSO for a portal in NERM, using Okta as the Idp and I’ve hit a few roadblocks I could use some help with.

While setting up SSO, I’m getting a red error banner that says:

SAML Setting failed to save!

Unfortunately, there’s no detailed error message, so I’m not sure what exactly is going wrong.

Here’s what I’ve done so far:

Followed the SailPoint support article:
Collaboration Portal SSO Configuration Guide
Provided the required SAML metadata from Okta.
Set up the login URL and identifiers.

Still, it fails without clarity. I’m starting to think something might be misconfigured in my metadata or SSO attributes.

If anyone has successfully configured SSO with Okta, would you be open to sharing a sample export or screenshots of a working setup? That would be really helpful.

NERM Configuration Questions

As I was troubleshooting the SSO issue, I came across this Reddit post that raised a bunch of great questions around SailPoint configuration many of which I’ve also been wondering about.

Some of the questions I’ve never tried myself, while others I’ve tried and got working, but I’m still not 100% confident if they’re configured the right way. So if anyone knows the correct answers or best practices, please feel free to share!

Reddit Thread

A few of those questions apply directly to my current challenges in NERM:

Configuration Approach:
I’ve followed the SailPoint support blog, but not sure if that’s the current best practice. Is that article still valid?
Reverse Relationship with Profile Select Attributes:
When is it appropriate to use this? Any practical use cases?
Role-Based Permissions:
For roles like NEProfile, NEAccess, Defaults, what permissions should ideally be assigned to make NERM function smoothly?
Workflow Contributors Step:
I tried assigning contributors in the workflow, but only users with the NERM Admin role are visible.

No other users show up in the search (only None).
I can’t assign other roles either.
Is this a permission issue or something in the portal config?

Contributor and Owner Attributes:
How should the following fields be configured?

Contributor Search
Contributor Select
Owner Search
Owner Select

Contributor Eligibility:
Can contributors only be Portal/Collaborator users, or is there flexibility to assign others?
Portal User & Lifecycle Linkage:
Why do we need to link a Portal User with a Lifecycle User? Is there any situation where this isn’t required?
User Data Collection Flow:
If I want a new user to fill out a form during onboarding:

Can this be sent via NERM?
If the user isn’t a Portal user yet, can they still receive/access that form?

Any insights from those who’ve set these up would be super helpful.

Thanks in advance

pratik_s · May 20, 2025, 8:22am

Hi,

You can try to check below steps.

Check Metadata Format:

Ensure the Okta metadata XML is valid and complete.
Avoid using shortened or modified metadata URLs—use the full metadata XML file or URL directly from Okta.

Entity ID and ACS URL Consistency:

The Entity ID in Okta must exactly match what SailPoint NERM expects.
The Assertion Consumer Service (ACS) URL should be:

https://<your-nerm-instance>/saml/consume

or for specific portals:

https://<your-nerm-instance>/<portal-name>/saml/consume

SAML Attributes:

Ensure required attributes like NameID, email, firstName, and lastName are correctly mapped in Okta.
Use persistent or emailAddress format for NameID.

Certificate Issues:

If you’re uploading a certificate manually, ensure it’s in X.509 format and not expired.
Try re-downloading the certificate from Okta and re-uploading it.

Browser Console Logs:

Open Developer Tools (F12) and check the Network and Console tabs when saving the SAML settings.
Look for any failed API calls or JavaScript errors that might give more context.

Portal-Specific Configuration:

If you’re configuring SSO for a specific portal (like /vendor), ensure the portal is properly registered in NERM and the SAML endpoint reflects that.

coltonulmer · May 20, 2025, 1:17pm

Hi Pavankalyan,

I’ve setup up SSO with collaboration portals many of times with Okta. The process is actually much more simpler to utilize the Import File method. To do this , you need to retrieve the the SAML metadata from Okta and create a .XML file.

In Okta navigate to the application after clicking on the application you want to go to the “Sign On” tab. After you click the “Sign On” tab there is a “View SAML Setup instructions button” on the right hand side. Click it. This will open another tab with all of the SAML metadata (cert, issuer SSO URL) . I prefer to just copy all of the metadata in the last “Optional” section then paste it into notepad and save as a .XML file. From there you can upload on the NERM side via the Import File upload.

From there you need to determine if you want to enable JIT provisioning or not. However, regardless of your decision the user must have a Profile setup within NERM to login.

Let me know if you have any questions.

kalyan_dev32 · May 24, 2025, 4:37am

@coltonulmer @pratik_s I’ve followed the recommended steps to configure SSO between Okta and the NERM Collaboration Portal, but I’m running into issues where the configuration isn’t getting saved in the portal.

Here’s what I’ve done so far:

NERM Portal URL: https://partner11154.portal.mynonemployee.com/medical
Created a portal in NERM and configured the SSO settings:
- SSO Enabled
- SSO Name: Okta SSO
- Domain: https://partner11154.portal.mynonemployee.com
- SP Entity ID: NERM_Medical_Portal
- Attributes: name, email, groups
Configured the Okta SAML App with:
- Single Sign-On URL: https://partner11154.portal.mynonemployee.com/saml/consume?portal_url=medical
- Audience URI (SP Entity ID): NERM_Medical_Portal
- NameID Format: Persistent
- Attribute mappings for name, email, and groups

I’ve also imported the Okta SAML metadata XML into the portal (see attached).
However, the configuration isn’t saving in NERM, and no error message is shown.

I’ve attached:

Screenshots of the NERM SSO configuration screen.

The Okta SAML metadata XML used.

Config.xml (2.3 KB)

Is there something I might be missing in the NERM or Okta configuration?

kalyan_dev32 · May 24, 2025, 5:48am

I figured out the issue with the SSO config not saving. it turned out to be a browser problem (Blocked: Storage access requests from trackers), and the config is now saving properly.

Now, I’m encountering a new issue.

I’ve successfully mapped Okta SAML attributes (name, email, firstName, lastName) and configured JIT provisioning in NERM.
The SAML assertion shows these attributes are present:

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                 xmlns:xs="http://www.w3.org/2001/XMLSchema"
                 Destination="https://partner11154.portal.mynonemployee.com/saml/consume?portal_url=medical"
                 ID="id-12758705769503424381615898"
                 IssueInstant="2025-05-24T05:35:15.219Z"
                 Version="2.0"
                 >
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                  Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
                  >http://www.okta.com/exkovtmikzFfYT14u5d7</saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <ds:Reference URI="#id-12758705769503424381615898">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                        <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
                                                PrefixList="xs"
                                                />
                    </ds:Transform>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <ds:DigestValue>6c+BNwhfmylRbL8UOdgxCjWkQvjfClOcSXQMvSeb7oE=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>nwhBEWDLV1Gy8C5vx/cU29NAl7op8u2IYFMv/YKq9ucOx0ZjnL3bQ+TzD1mBkZdbBqD+x7B9YZmxEUs8UgkwbNrp4vQy7y12Wx881f1Vtk2YsqMC18yr5yjA1pK7QZG0/kBYXDOIPdWgbuoRESbe8wEgGNmS8ySbcW6mMa9WRxopl3sPX6s4c9g4UQJ+Db1AKTfT37ZjywO9/A4xtJNqM0A0+IDvQJ+wkaUgYeozNuutd0xEpUoqRtDJx44YTRuScAAeRq/vDEdLOpwm4vo6a8MeObSZpjMW3xlw1Go7ucFsSIUSvImAdDUSeL0bgotbe6E6cHMXTlnTEmv58WJaxQ==</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>MIIDqDCCApCgAwIBAgIGAZcAgtazMA0GCSqGSIb3DQEBCwUAMIGUMQswCQYDVQQGEwJVUzETMBEG
A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEU
MBIGA1UECwwLU1NPUHJvdmlkZXIxFTATBgNVBAMMDGRldi04NjMwMTA0MjEcMBoGCSqGSIb3DQEJ
ARYNaW5mb0Bva3RhLmNvbTAeFw0yNTA1MjQwNDE2NDRaFw0zNTA1MjQwNDE3NDNaMIGUMQswCQYD
VQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsG
A1UECgwET2t0YTEUMBIGA1UECwwLU1NPUHJvdmlkZXIxFTATBgNVBAMMDGRldi04NjMwMTA0MjEc
MBoGCSqGSIb3DQEJARYNaW5mb0Bva3RhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMjvh+mbRukaVCGyxXl1gulmCQUup9BXivqjYm3HfLSNsB55O/vq5Sz2DpA91iukL+uU/Rlc
KOnbP+SdiauHPrrzBxo+3VXnIEnUfPeRf//gMNR/KBwxXGFJ7rKhaoBCen2f4twIiM5oURtGgWO9
KUxZTXhDQCWMPIpAlH11eMelxV57NedWBJgRf5wnL9uGSYgWI1em/dFbnhelTh6i6PJfz78GG8wr
tPOzjzzpXpBmSuXPy2u0yeQAPgoHWDe9MLYunRnFeZQD4ILSlx1ZC3EE6M65DeLuIAeYd1lXXq2p
dvwXpjIjtGR86fhTRdz1l6PI3fZ+rOf7O67paYC/NhkCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEA
s+dXGHbDkWHflBTr0j48tX/9TsqrjaBBcOg0/LjjHAI1KjMROucKDGtEgVklHLxQOcU1PxzAXZnx
FxpP8D6vuoCmiKB1rOrflKX1s+Hhmvb38sP1RnhzMhEugaXkorquLy/JQldINPg/9gUcLGcdld3E
Eo49asqfjGAEkQm9LLn5T5XupxjjvjqoqnotJdjGhn6RXbkyR0YFXlMVQLCPpep92CyKwHiNJSFY
q69FcTpRAaBunLU4Fu5x8VmLHK8+CaZvkd+UNC+cTj5Tby1TP2WEpO2U+r7IhrsIKcpxPL0A7gSm
5NW/qJh3Lkru9gAeycnfXJxXixuBu/s35rdu2Q==</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </saml2p:Status>
    <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                     xmlns:xs="http://www.w3.org/2001/XMLSchema"
                     ID="id-12877550589486969581287271540"
                     IssueInstant="2025-05-24T05:35:15.219Z"
                     Version="2.0"
                     >
        <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
                      >http://www.okta.com/exkovtmikzFfYT14u5d7</saml2:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                <ds:Reference URI="#id-12877550589486969581287271540">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                            <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
                                                    PrefixList="xs"
                                                    />
                        </ds:Transform>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                    <ds:DigestValue>8jZ9djjf++8zJYo83u8WG4eK/5Kl7ClePtn1nYw6mkU=</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>jF9e+kdxF+WXQC5615Y95WWxfBMGl0Y4wghZMiYqFPVWieY7OaZu2nW6lDX4OZpFw50yUdHkB9/xwk3mKRXci2Uh6wKS6kupqr4OwAgjSkF3kMsrbnIB9Hz6FzuhjhWCbEUkeIkymilBa23xxdpPj42eEYq582oN2rD4j1pzx72x0xWjCF/p8IWdjzlmbw0m0Ap9Yrye17nGrGDdFL7AGaCn1++ygTIun00uXyCOvlI/JR+/W59niSI0Eno+Trr5Y0st2S0GsGhkh+vwH+LLXcNmxF7P9dqCfvLoe0gKBoH/1IEW5mS7emw95z+23F5YyB3qGOmrwiWD/EdCeVL5cg==</ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>MIIDqDCCApCgAwIBAgIGAZcAgtazMA0GCSqGSIb3DQEBCwUAMIGUMQswCQYDVQQGEwJVUzETMBEG
A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEU
MBIGA1UECwwLU1NPUHJvdmlkZXIxFTATBgNVBAMMDGRldi04NjMwMTA0MjEcMBoGCSqGSIb3DQEJ
ARYNaW5mb0Bva3RhLmNvbTAeFw0yNTA1MjQwNDE2NDRaFw0zNTA1MjQwNDE3NDNaMIGUMQswCQYD
VQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsG
A1UECgwET2t0YTEUMBIGA1UECwwLU1NPUHJvdmlkZXIxFTATBgNVBAMMDGRldi04NjMwMTA0MjEc
MBoGCSqGSIb3DQEJARYNaW5mb0Bva3RhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMjvh+mbRukaVCGyxXl1gulmCQUup9BXivqjYm3HfLSNsB55O/vq5Sz2DpA91iukL+uU/Rlc
KOnbP+SdiauHPrrzBxo+3VXnIEnUfPeRf//gMNR/KBwxXGFJ7rKhaoBCen2f4twIiM5oURtGgWO9
KUxZTXhDQCWMPIpAlH11eMelxV57NedWBJgRf5wnL9uGSYgWI1em/dFbnhelTh6i6PJfz78GG8wr
tPOzjzzpXpBmSuXPy2u0yeQAPgoHWDe9MLYunRnFeZQD4ILSlx1ZC3EE6M65DeLuIAeYd1lXXq2p
dvwXpjIjtGR86fhTRdz1l6PI3fZ+rOf7O67paYC/NhkCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEA
s+dXGHbDkWHflBTr0j48tX/9TsqrjaBBcOg0/LjjHAI1KjMROucKDGtEgVklHLxQOcU1PxzAXZnx
FxpP8D6vuoCmiKB1rOrflKX1s+Hhmvb38sP1RnhzMhEugaXkorquLy/JQldINPg/9gUcLGcdld3E
Eo49asqfjGAEkQm9LLn5T5XupxjjvjqoqnotJdjGhn6RXbkyR0YFXlMVQLCPpep92CyKwHiNJSFY
q69FcTpRAaBunLU4Fu5x8VmLHK8+CaZvkd+UNC+cTj5Tby1TP2WEpO2U+r7IhrsIKcpxPL0A7gSm
5NW/qJh3Lkru9gAeycnfXJxXixuBu/s35rdu2Q==</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">[email protected]</saml2:NameID>
            <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml2:SubjectConfirmationData NotOnOrAfter="2025-05-24T05:40:15.219Z"
                                               Recipient="https://partner11154.portal.mynonemployee.com/saml/consume?portal_url=medical"
                                               />
            </saml2:SubjectConfirmation>
        </saml2:Subject>
        <saml2:Conditions xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                          NotBefore="2025-05-24T05:30:15.219Z"
                          NotOnOrAfter="2025-05-24T05:40:15.219Z"
                          >
            <saml2:AudienceRestriction>
                <saml2:Audience>NERM_Medical_Portal</saml2:Audience>
            </saml2:AudienceRestriction>
        </saml2:Conditions>
        <saml2:AuthnStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                              AuthnInstant="2025-05-24T05:35:15.219Z"
                              SessionIndex="id1748064915217.1744086222"
                              >
            <saml2:AuthnContext>
                <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
            </saml2:AuthnContext>
        </saml2:AuthnStatement>
        <saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            <saml2:Attribute Name="name"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
                             >
                <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >[email protected]</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute Name="email"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
                             >
                <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >[email protected]</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute Name="firstName"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
                             >
                <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >Aron</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute Name="lastName"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
                             >
                <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >Finch</saml2:AttributeValue>
            </saml2:Attribute>
        </saml2:AttributeStatement>
    </saml2:Assertion>
</saml2p:Response>

However, only the NameID ([email protected]) is mapped during user creation in NERM. The other attributes (firstName, lastName, email, etc.) are not mapping to the user record.

Could there be a misconfiguration in NERM’s SSO mapping that’s causing it to ignore these attributes during JIT provisioning?

coltonulmer · May 25, 2025, 4:09pm

Could you try changing the attribute name formatting to Basic?

kalyan_dev32 · May 25, 2025, 5:33pm

Yes, I’ve updated the attributes, and it worked. However, not all attributes are being mapped, so I loaded users separately while creating profiles.

coltonulmer · May 26, 2025, 11:26pm

Thats a limitation of the platform to my knowledge. Outside of those basic attributes, I do not believe currently the platform supports mapping other attributes.