Supplier portal SSO stuck in redirect loop after Azure AD integration in supplier collaboration

PLM ENOVIA
, , , , , , , ,
1

We’ve configured Azure AD SSO for our supplier portal in R2021x, but suppliers are hitting an infinite redirect loop when trying to log in. The authentication flow starts, redirects to Azure AD login page, they authenticate successfully, but then get bounced back to the login screen again.

I’ve verified the SAML ACS URL configuration in Azure AD matches our ENOVIA portal URL. The attribute mapping looks correct - we’re mapping email to username and groups to roles. Browser session troubleshooting shows the SAML response is being received, but something in the assertion processing is failing. No clear errors in the portal logs, just repeated authentication attempts. Internal users with direct ENOVIA login work fine - this only affects SSO users. Has anyone successfully set up Azure AD SAML for supplier portal access?

2

I suspect your attribute mapping issue. In Azure AD, the claim names need to match exactly what ENOVIA expects. We had the same loop - turned out we were sending ‘emailAddress’ but ENOVIA wanted ‘email’. Check the SAML response XML to see what attributes Azure is actually sending versus what your portal is configured to receive.

3

For SAML debugging, add this to your portal’s log4j configuration: ‘log4j.logger.com.matrixone.apps.domain.util.SAMLUtil=DEBUG’. That will dump the entire SAML response. Also check if you have certificate validation enabled - if Azure’s signing cert isn’t trusted by ENOVIA, the assertion gets rejected silently and causes re-authentication loops.

4

Good points all around. I checked the NameID format and it’s set to emailAddress on both sides. The RelayState looks consistent in the browser network trace. Alex, how do I enable SAML debugging specifically? I’ve got general portal logging on but not seeing the full SAML response details.

5

I’ve implemented Azure AD SSO for supplier portals across multiple ENOVIA instances. Your redirect loop is almost certainly caused by one of three issues in the SAML configuration.

SAML ACS URL Configuration: The Assertion Consumer Service URL must be EXACTLY what ENOVIA expects. In R2021x supplier portal, this should be https://your-portal.com/enovia/common/emxNavigator.jsp. Many people mistakenly use the base portal URL or include query parameters. In Azure AD Enterprise Application, go to Single sign-on > Basic SAML Configuration and verify:

  • Reply URL (ACS URL): Must match your portal’s SSO endpoint exactly
  • Sign on URL: Your portal landing page
  • Identifier (Entity ID): Typically your portal base URL

Also critical: Check the ‘Relay State’ field. If it’s set, make sure it points to a valid portal page, not a redirect URL.

Attribute Mapping in Azure AD: This is where most loops originate. ENOVIA supplier portal expects specific claim names. In Azure AD, go to Single sign-on > Attributes & Claims:

  • Required claim: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name mapped to `user.mail
  • Additional claim: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress mapped to `user.mail
  • Role claim (if using): http://schemas.microsoft.com/ws/2008/06/identity/claims/role mapped to `user.assignedroles The namespace URIs matter - don’t use short names. ENOVIA parses the full claim URI.

Browser Session Troubleshooting: Use browser dev tools to capture the full authentication flow:

  1. Clear all cookies for your portal domain
  2. Open Network tab and enable ‘Preserve log’
  3. Attempt login and watch for the SAML POST to ACS URL
  4. Check the POST payload - decode the SAMLResponse parameter (it’s base64)
  5. Look for StatusCode in the decoded XML - should be ‘urn:oasis:names:tc:SAML:2.0:status:Success’

Common session issues:

  • Cookie domain mismatch: If your Azure Reply URL uses www.domain.com but portal is domain.com, session cookies won’t work
  • HTTPS/HTTP mismatch: All URLs must be HTTPS in production
  • SameSite cookie attribute: Modern browsers require SameSite=None for cross-domain SAML, but ENOVIA R2021x doesn’t set this by default

For the SameSite issue, you may need to add a reverse proxy rule or update your web server configuration to inject the proper cookie attributes. Check if your suppliers are using Chrome/Edge 90+ which enforces strict SameSite policies.

One more thing: Verify the SAML signing certificate from Azure AD is imported into ENOVIA’s trusted certificates. The supplier portal validates the signature on every SAML response, and if validation fails, it redirects back to login without logging an obvious error.

6

Redirect loops in SAML usually mean the assertion isn’t being validated properly. Check your RelayState parameter - if Azure AD is sending back a different RelayState than what ENOVIA expects, it can cause loops. Also verify the NameID format matches between Azure and ENOVIA configuration.