Skip to main content

Federate a SAML IdP to a downstream SAML SP through SecureAuth

Connect your corporate identity provider (Microsoft Entra ID, Okta, or another SAML IdP) to any SAML application without configuring the application separately for every IdP you use. SecureAuth handles the SAML chain in the middle, so the downstream application trusts one stable identity provider even as your upstream IdP changes.

This pattern fits enterprise deployments where the customer's identity lives in an upstream IdP, the downstream applications expect SAML from a single, consistent IdP, and the team wants centralized policy and attribute control between the two. SecureAuth acts as a SAML SP to the upstream IdP and a SAML IdP to the downstream SP.

This guide walks through the configuration with Microsoft Entra ID as the upstream IdP (primary example) and Okta as an alternate. The downstream side is described generically as "your SAML SP" so the procedure applies whether you're federating into Salesforce, Workday, ServiceNow, or an internal SAML application.

What you gain​

  • One IdP from the application's perspective. Downstream applications trust SecureAuth and nothing else, even as your upstream IdP changes. Most SAML SPs accept only one IdP; SecureAuth normalizes that to one stable endpoint.
  • Single sign-on across SAML applications. Users authenticate once at the corporate IdP and reach every connected SAML application without re-entering credentials.
  • Centralized policy and attribute control. Apply group restrictions, MFA rules, or attribute transformations between the upstream identity and the downstream application. For example, restrict access by group or enrich the assertion with claims the SP expects.
  • Easier IdP migrations and incremental rollouts. Switching an application from a direct IdP integration to SecureAuth, or moving between upstream IdPs, doesn't require application-side reconfiguration each time.

How the flow works​

Prerequisites​

Before you begin, you need:

  • Administrator access to the upstream IdP (Microsoft Entra ID, Okta, or another SAML IdP).
  • Administrator access to your SecureAuth Connect workspace.
  • The downstream SP's SAML metadata: a metadata URL, downloadable XML, or the Entity ID, ACS URL, and signing certificate as separate values.
  • A list of user attributes the downstream SP expects in the assertion (commonly email, userPrincipalName, or a department code).

Step 1: Connect the upstream IdP to SecureAuth​

Register the upstream IdP in SecureAuth so it can accept assertions from that IdP. The single-page guides below cover both halves of the connection (the SecureAuth side at Authentication > Providers and the IdP-side configuration in Entra or Okta):

If the downstream SP needs attributes sourced from the upstream IdP (for example, a department or role from Entra), map them on the IdP connection now. See Adding SAML IdP assertion schema attributes.

Step 2: Add the downstream SP to SecureAuth​

Now register the downstream SP. SecureAuth becomes the IdP that issues the assertion this SP consumes.

  1. Follow Add a SAML service provider end-to-end. The page covers SP metadata import, NameID configuration, signing algorithm, and access policies.
  2. On the Overview tab of the new SP record, capture the SAML IdP Entity ID, Metadata URL, and Single Sign-On URL — you'll paste these into the downstream SP's SSO settings in Step 3.
  3. Download the SAML IdP Signing Certificate in PEM format.

If the downstream SP expects attributes beyond the defaults, override the assertion attributes per SP. See Adding outgoing SAML assertion attributes sent to service providers.

Step 3: Configure the downstream SP​

Paste the SecureAuth IdP values from Step 2 into the SAML SSO settings on the SP side. Field names vary by application, but every SAML SP needs the same three values:

SP field (typical names)What to pasteSource
Identity Provider Issuer or IdP Entity IDSAML IdP Entity IDSP detail page > Overview tab
SAML SSO URL or IdP Login URLSAML IdP Single Sign-On URLSP detail page > Overview tab
X.509 Certificate or Verification CertificateSAML IdP Signing Certificate (PEM)SP detail page > Overview tab > Download

If the SP accepts a metadata URL instead of individual fields, paste the SAML IdP Metadata URL. Metadata URLs let the SP re-fetch on certificate rotation, which is more resilient than uploading certificates manually.

For vendor-specific field-mapping guides (BambooHR, Citrix StoreFront, and others), see SSO integrations.

Step 4: Verify the federation​

Test the full chain end-to-end with a real user. Errors during sign-in usually point to the misconfigured leg of the chain:

  1. Open the downstream SP and start an SP-initiated sign-in.
  2. Confirm the browser redirects to SecureAuth, then to the upstream IdP.
  3. Sign in at the upstream IdP with a test user.
  4. Confirm the browser returns to SecureAuth, then to the downstream SP.
  5. Confirm the SP grants access to the test user.

If a step fails, capture the SAML response with a browser tool like SAML Tracer. The response shows the exact NameID, attributes, signing algorithm, and any error codes the SP returns.

Common issues​

IssueWhere it surfacesResolution
Browser redirects in a loop between the SP and SecureAuthStep 4The downstream SP's stored Entity ID or ACS URL doesn't match SecureAuth's. Re-import metadata on the SP record (Step 2) and re-paste IdP values into the SP (Step 3).
User authenticates at the upstream IdP but is rejected at the downstream SPStep 4The Subject NameID format doesn't match what the SP expects. On the SP record, override the Subject NameID to the format the SP requires (commonly urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress).
Sign-in succeeds but the SP can't resolve the userStep 4The assertion is missing an attribute the SP uses to match the user (often email or userPrincipalName). Override outgoing SAML assertion attributes on the SP record.
SP metadata refresh fails after the SP changes Entity IDBackground refreshRe-import the SP metadata to overwrite the stored Entity ID. See Resolve an SP metadata refresh error.
Signing algorithm rejected by the SPStep 4On the SP record, set the signing algorithm the SP accepts. SHA-256 is the safe default.

See also​