SAML Integration With Any SAML 2.0 Identity Provider

A SAML integration with SSOGEN needs three values from SSOGEN and three things from your identity provider: signed assertions, a stable NameID and an email attribute.

Start a guided trial

A SAML integration between your identity provider and SSOGEN takes about 20 minutes. Your provider keeps checking passwords and second factors, and SSOGEN turns that sign-in into single sign-on for every application it protects, including Oracle E-Business Suite, PeopleSoft and JD Edwards behind the Web Agent.

SSOGEN is the service provider and your system is the identity provider. The setup has three parts:

Copy three values out of SSOGEN.
Create a SAML application at the provider.
Give SSOGEN the provider’s metadata.

Any provider that follows SAML 2.0 and meets the checklist below works, including Okta, AD FS, Shibboleth and PingFederate.

This page is the provider-neutral checklist. Wizard screens and every field are in the SAML guide. For a named provider, start at the hub or jump to Microsoft Entra ID or Keycloak.

The three values SSOGEN gives you

When you add a SAML provider and the connection ID is valid, the General step shows three values with copy buttons. They come from your deployment’s canonical origin, the one public address set at install time.

That is not always the address in your browser.

Value	What the provider calls it	What it does
SP entity ID	Identifier, Audience or Entity ID	SSOGEN’s name in this federation
ACS URL	Reply URL, Assertion Consumer Service or Recipient	Where the provider sends the person back with a signed assertion
SP metadata URL	Service provider metadata	A file version of the two values above, for providers that can read one

Most providers ask for the first two. The ACS should use the HTTP-POST binding. Copy them exactly. The provider’s identifier must equal SSOGEN’s SP entity ID, and its reply address must equal the ACS URL.

What your identity provider must do

Check these five things in the provider before you start. They cause nearly every failed test.

Sign the assertion. SSOGEN always requires a signed assertion and verifies it against the certificates in the provider’s metadata. This check is always on. Signing only the response is not enough.
Send a NameID that never changes for a person. SSOGEN builds the username from the NameID and uses it to spot the same person next time. A user principal name or an email address works. If the value changes, SSOGEN creates a second account.
Send an email attribute. Without it, the account has no email address.
Publish metadata for one application. SSOGEN refuses a document that describes more than one entity or identity provider, so skip the federation-wide file.
Publish an HTTP-Redirect sign-in endpoint over https. The metadata also needs at least one signing certificate. SSOGEN verifies assertions with it, so activation requires one.

Pick the metadata source

SSOGEN accepts four sources on the Metadata source step.

Source	Use it when	Watch for
Metadata URL	The provider publishes metadata at an https address	The SSOGEN server must reach the address. Private and reserved addresses are refused
Metadata file upload	You downloaded the XML	You must upload again when the provider rotates its certificate
Paste metadata XML	You copied it from the provider	Same as upload
Manual configuration	You have no metadata	Not recommended: there are no certificates, so activation fails

A Metadata URL is best for the long run. SSOGEN keeps it, so it can read the same address again when the certificate changes.

Mapping attributes and the NameID

The Mapping step tells SSOGEN which assertion attribute holds the email address and which holds the display name.

The defaults suit Entra ID and AD FS. They are the long Microsoft claim URIs ending in emailaddress and name.
Other providers use their own names. Type exactly what yours sends.
An empty field still works. SSOGEN recognizes common names like mail and email.

You can keep up to 32 more attributes, either as the person’s mobile phone or as a custom attribute defined under Identity > Attributes.

The NameID format defaults to urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. Leave it unless the provider’s team asks for another. Three more switches are off by default. Use one only if the provider requires it:

Signing SSOGEN’s requests.
Sending requests by HTTP-POST.
Forcing re-authentication.

New providers start as drafts.

Validate checks the settings.
Test reads the provider’s metadata and confirms the metadata.
Try signing in with a real person in one browser confirms the sign-in.
Activate puts the provider on the sign-in page.

The result page creates no account. It shows the NameID, the attributes received and the sign-in strength.

Message	Fix
The assertion was addressed to a different service provider	Set the provider’s identifier to the SP entity ID exactly
The response came back to a different ACS URL	Set the reply address to the ACS URL exactly
The assertion’s signature did not verify	Import the provider’s metadata again
The assertion is outside its validity window	Correct the clock on SSOGEN or the provider; a few minutes of difference are allowed
The assertion carried no subject (NameID)	Add a NameID at the provider
That document describes more than one entity	Use the metadata of your one application

Questions people ask

What is the difference between an IdP and an SP?

The identity provider checks the password and says who the person is. The service provider relies on that answer. Here, your system is the IdP and SSOGEN is the SP.

Can SSOGEN be the identity provider instead?

Yes. SSOGEN is a full identity provider too, with local users, a directory, SAML and OpenID Connect. A third-party provider is optional.

Should I use SAML or OpenID Connect?

If the provider supports both, either works. See SAML vs OIDC. OpenID Connect is simpler to set up. SAML is more common in older enterprise products.

Where to go next

Each screen. The SAML guide covers each screen.
Other providers. The hub lists other providers.
Choosing between providers. Read how the sign-in page chooses between providers.

SSOGEN has run in production since 2016 and is listed in the Microsoft Entra gallery. Get trial access to see a SAML integration with your own provider.