Punchout authentication fails for supplier procurement portal using SSO (SAML assertion error blocks access to catalog)

SCM Infor SCM
, , , , , , , ,
1

We’re experiencing authentication failures when users try to access our supplier punchout catalogs through Infor SCM procurement portal. The SAML assertion appears to be generated correctly, but suppliers are receiving authentication errors.

Our SAML configuration includes:

<saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:Attribute Name="userId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

The ACS URL is configured as: https://supplier.example.com/saml/consume

Users see “Authentication failed - invalid assertion” when attempting catalog access. The IdP certificate was recently renewed (30 days ago), which might be related. Has anyone dealt with SAML attribute mapping issues or ACS URL configuration problems in IS 2022.2?

2

I worked through this exact scenario last month with IS 2022.2. Let me address all three key areas systematically:

SAML Attribute Mapping: Your attribute mapping needs to align with supplier expectations. Update your SAML configuration:

<saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
  <saml:AttributeValue>${user.email.toLowerCase()}</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="userId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
  <saml:AttributeValue>${user.supplierUserId}</saml:AttributeValue>
</saml:Attribute>

Note the NameFormat change to ‘basic’ and mapping to supplierUserId field.

ACS URL Configuration: Verify your RelayState parameter is being passed correctly. In Infor SCM procurement configuration, ensure the punchout setup includes:


acs.url=https://supplier.example.com/saml/consume
acs.binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

The binding method matters - most suppliers use HTTP-POST.

IdP Certificate Validation: After certificate renewal, you must:

  1. Export new IdP metadata from Infor SCM (Admin > SSO Configuration > Export Metadata)
  2. Send metadata XML to supplier (not just the certificate)
  3. Request supplier to reimport full metadata, not just update certificate
  4. Test with SAML tracer tool to verify signature validation

The certificate validation often fails because suppliers only update the signing certificate without refreshing the entire metadata, which includes algorithm specifications and key descriptors. Request your supplier to perform a complete metadata refresh and test with a single user first before rolling out broadly.

3

Good point on the certificate. I verified with our supplier and they claim they have the updated metadata. However, I’m wondering if the attribute mapping is correct. Should the NameFormat for userId be ‘uri’ or ‘basic’? Our previous configuration used ‘basic’ for all attributes before the upgrade.

4

The NameFormat depends on your supplier’s requirements, but ‘basic’ is more commonly supported. I’d also check if your ACS URL matches exactly what the supplier expects - including protocol (https), trailing slashes, and case sensitivity. Some SPs are very strict about URL matching. Can you capture the SAML response in your browser dev tools to see what’s actually being sent?

5

I captured the SAML response and found the issue - our userId attribute was sending the internal user ID instead of the supplier-expected identifier. After examining our old config, we were mapping to a different user attribute. Still working on the exact fix though.

6

I encountered similar issues last quarter. Beyond the certificate and URL validation, check your attribute value formats. Some suppliers expect specific formats for email (lowercase only) or userId (numeric vs alphanumeric). Also verify that your SAML assertion lifetime isn’t too short - we had cases where network latency caused valid assertions to expire before reaching the SP.

7

First thing to check - did you update the IdP certificate metadata in your supplier’s SP configuration after the renewal? Most punchout authentication failures I’ve seen stem from certificate mismatches. The supplier’s service provider needs the new public certificate to validate your assertions. Export your current IdP metadata and send it to the supplier’s technical team.