Configure Okta SAML for a Supportbench customer portal and verify customer access

Okta SAML lets a customer authenticate through an approved corporate identity provider before entering a Supportbench customer portal. Supportbench still decides which Contact, Company, cases and knowledge the customer may access. A successful Okta login is therefore only one part of the setup: the portal must validate the assertion, resolve the correct customer identity and apply the intended visibility rules.

Prepare the portal, identity and customer-access plan  ·  Use the portal’s actual ACS and audience values  ·  Create and assign the Okta application  ·  Configure the Supportbench portal  ·  Map identities, companies and customer fields deliberately  ·  Run a complete customer workflow test  ·  Example: support a customer with several operating companies  ·  Troubleshoot the stage that failed

Prepare the portal, identity and customer-access plan

1. Confirm the exact portal hostname customers will actually use, including any configured custom domain. Keep production and preview hostnames distinct.
2. Arrange an Okta administrator and a Supportbench administrator with Administer communities or the applicable authorized portal-edit access.
3. Choose an existing active test Contact with known Company membership, portal access and customer role. Agree which case/article that Contact should see and a representative item they should not see.
4. Agree which controlled identity value Okta will send as NameID and email. Do not use an editable or ambiguous organization display name as a substitute for a deliberate identity plan.
5. Decide whether company lookup or customer-field mapping is necessary. Start with the smallest verified mapping and document who maintains each value.
6. Keep a working administrative recovery path while testing. Enable automatic SAML redirection only after the normal entry and failure paths have been checked.

This procedure is for customer-portal SAML. Agent Microsoft sign-in and agent authentication settings have their own identity and authorization paths. Do not use a customer portal integration as an assumed replacement for agent access setup.

Use the portal’s actual ACS and audience values

The certificate establishes signature verification trust. Do not infer that pasting it enables encrypted assertions or any separate encryption feature. A login URL is not a safe substitute for a missing logout URL.

Create and assign the Okta application

In the current Okta Identity Engine documentation, open Applications and Resources → Applications, choose Create App Integration → Classic experience, select SAML 2.0 and continue. Name the app for the intended portal. Supply the values in the preceding table, complete the integration and assign the intended test users. The Sign On area exposes the signing-certificate configuration. Follow Okta’s current SAML integration procedure if your organization’s console differs.

Use Okta’s SAML field reference for its field definitions. Set the application identity to the controlled value agreed for this portal, and add only the attribute statements needed by the Supportbench identity/mapping plan. Do not add seven generic attributes just because an old example listed them.

Obtain this application’s identity-provider login URL and public signing certificate. If a logout URL is provided and your planned flow uses it, record that separately. Check which signing certificate is active and who owns renewal. Keep the test assignment narrow until the complete portal workflow has been verified.

Configure the Supportbench portal

1. Open Settings → Customer portal and select the exact portal being connected.
2. Open Security and sign-in and find SAML. Check the portal name and host before changing settings.
3. Enable Enable SAML. Enter the Okta application’s SAML login URL and public SAML certificate. Supply a verified SAML logout URL only where appropriate.
4. Leave Auto redirect to SAML off for the initial verification so you can diagnose the intended entry path before making redirection the normal experience.
5. If required, enable Enable attribute mapping, configure the approved Company lookup fields, and add the exact SAML attribute → Customer field mappings described below.
6. Choose Save Changes and confirm the portal save succeeded.
7. Use the intended portal host to test the existing Contact. Verify identity, Company and allowed/denied content, not just a successful redirect.
8. When the normal and recovery paths work, enable Auto redirect to SAML if that is the intended experience, save again, and retest entry and sign-out.

The screen also contains Username field and Allowed IP ranges. Do not treat these stored values as proof that they override the current identity-matching flow or enforce an IP access boundary. The verified current admission path does not use them that way. Build the supported identity and access plan around the actual validated assertion and customer permissions.

Map identities, companies and customer fields deliberately

Core resolves the asserted identity using its validated NameID/email matching rules. A valid signed email can also be used to provision a Contact when no matching Contact exists. Prefer a known existing Contact for the first test, so a failed setup does not generate a succession of unintended customer records.

Optional Company lookup requires attribute mapping to be enabled, a non-empty Company lookup attribute, and an appropriate selected Company lookup field. The configured claim is matched against that Company custom-field value, and exactly one active, undeleted Company must match. This is not an automatic comparison against any similarly named Company display label. Use a stable organization identifier maintained by the identity administrator and customer-data owner.

Run a complete customer workflow test

1. Start at the actual customer portal and use the intended SAML entry. Authenticate as the approved test identity.
2. Confirm the displayed customer identity and Company association. Check mapped fields where applicable.
3. Open a known permitted case and knowledge article. Test a representative forbidden item using the authorized verification process; success means both positive and negative access behave correctly.
4. Verify that the customer can perform their intended task, such as reading their case update or finding the relevant product procedure. Do not change a real case merely to prove sign-in.
5. Sign out and test the next sign-in. Check the configured logout behavior separately from authentication.
6. If automatic redirection is planned, enable it only after those checks and repeat the actual portal entry.
7. Record the portal host, Okta app, claim mapping, certificate expiry, test identities and results without storing tokens, assertions or private keys in the public guide.

Example: support a customer with several operating companies

A corporate customer may have separate operating companies whose contacts must not automatically see one another’s cases. The sign-in integration should identify the person and map the intended operating Company using an agreed identifier. A shared email domain alone is not a sufficient operational model for those relationships.

Agree the Company identifier with the customer-data owner, populate the intended Company custom field, and test one existing Contact from each relevant audience. Confirm both the permitted account history and the records that must remain unavailable. The value of this setup is a familiar corporate sign-in combined with deliberate Supportbench customer context, not an assumption that SAML grants company-wide access.

Troubleshoot the stage that failed

Continue learning

• Plan and maintain customer-portal SAML
• Maintain Company and Contact relationships
• Use the separate Microsoft sign-in flow
• Understand Supportbench two-factor authentication