Configure a SAML connector

This guide configures an external corporate identity provider as a SAML 2.0 federation connector. Sudomimus is the service provider (SP): it sends an AuthnRequest to your IdP, validates the signed assertion posted to its ACS, and then runs the same Layer 1, Layer 2, and issuance pipeline used by OIDC federation.

Before you begin

You need:

• an organization in the With portal;
• permission to create a SAML application at your IdP;
• the IdP’s entity ID and SP-initiated SSO URL; and
• the public X.509 certificate for the key the IdP uses to sign assertions.

Sudomimus supports SP-initiated SAML browser SSO only. The initial AuthnRequest is sent with HTTP-Redirect binding and the response must return with HTTP-POST binding.

1. Create the SAML application at your IdP

Create a custom SAML 2.0 application and register these production SP values:

IdP setting	Value
SP Entity ID / Audience	urn:sudomimus:production:federation-sp
ACS / Reply URL	https://federation.sudomimus.com/saml/acs
Initiation mode	SP-initiated
Response binding	HTTP-POST
Assertion signing	Required

The ACS must match exactly. The audience in the assertion must be the SP Entity ID above. If you are configuring a non-production environment, use the read-only SP Entity ID and ACS displayed for that environment instead.

Sign the assertion

Sudomimus requires a signed Assertion. Signing only the outer SAML Response is insufficient. Do not enable encrypted assertions; they are not supported.

2. Configure subject and profile attributes

The stable external identity normally comes from SAML NameID. Configure NameID to be stable for the lifetime of the user and unique within this IdP application. Do not use a mutable display name.

You may also release profile values as SAML attributes. Record the exact attribute names, including URI-style names if your IdP uses them:

Suggested purpose	Example attribute name
Email	mail
Given name	given_name
Family name	family_name

The names are examples, not required literals. The values entered in With must exactly match the attribute names emitted in the assertion.

An IdP-provided email is not automatically trusted by Sudomimus. It becomes usable for email ownership and account matching only when the connector’s organization has a current verified claim for that email domain.

3. Collect the IdP values

From the IdP, copy:

• the exact IdP Entity ID used as the assertion issuer;
• the HTTPS IdP SSO URL that accepts AuthnRequests; and
• the active assertion-signing certificate.

Export the certificate as PEM-encoded X.509 public certificate data, including the delimiters:

-----BEGIN CERTIFICATE-----
MIIC...
-----END CERTIFICATE-----

Do not paste a private key. During certificate rollover, keep both the old and new public certificates configured for the overlap window before removing the retired certificate.

4. Create the connector in With

In the With portal:

1. Open your organization.
2. Open Federation connectors and choose New connector.
3. Select SAML 2.0.
4. Enter a display name, IdP Entity ID, IdP SSO URL, and signing certificate.
5. Optionally enter the exact email, given-name, and family-name attribute names.
6. Create the connector.

The With portal creates new SAML connectors with NameID as the stable subject source. The protocol, IdP Entity ID, and subject source define the credential namespace and cannot be changed later; create a new connector if one of them must change.

The connector detail page shows the authoritative SP Entity ID and ACS again. Compare them with the values registered at the IdP before testing.

5. Put the connector to work

Choose one or both modes:

Application-managed sign-inAdd an ENTERPRISE_FEDERATION_APPLICATION_MANAGED Layer 1 rule that names this connector.

Domain-managed SSOVerify a domain, bind this connector to SSO_ONLY, and allow ENTERPRISE_FEDERATION_DOMAIN_MANAGED on participating applications.

The protocol is already fixed by the connector. Neither Layer 1 rule needs a separate OIDC/SAML switch.

6. Test the login

Use a non-administrator test user and start the appropriate application-managed or domain-managed flow.

Verify that:

• the browser receives an SP-initiated AuthnRequest at the configured IdP;
• the IdP posts the response to the exact ACS;
• the assertion issuer, audience, recipient, and InResponseTo match the flow;
• the assertion contains one AuthnStatement and is within its validity window;
• the assertion, not only the response, is signed by a configured certificate; and
• Layer 2 admits the resulting identity.

For an initial protocol smoke test, use an EVERYONE Layer 2 rule. If you use an EMAIL rule, ensure the mapped email attribute is present and its domain is verified by the connector’s organization.

Sudomimus rejects replayed requests and assertions. Browser-facing failures are intentionally generic, so configuration troubleshooting should start with the IdP’s SAML response inspector and the checklist above.

Unsupported settings

Do not enable IdP-initiated SSO, encrypted assertions, Single Logout, artifact binding, metadata import, requested authentication context policy, or signed AuthnRequests. These profiles are not currently accepted.

Related

Federation connector referenceField semantics, lifecycle rules, validation, and certificate rollover.

Configure an OIDC connectorUse OpenID Connect instead of SAML for the same enterprise-federation modes.