SSOGEN / SSO Applications / Salesforce SSO: Sign In to Salesforce Through SSOGEN
Integration
Salesforce SSO: Sign In to Salesforce Through SSOGEN
Salesforce SSO with SSOGEN is a SAML 2.0 exchange: the application hands SSOGEN two addresses, and SSOGEN hands back an entity ID, a sign-in URL and a certificate. You can see the assertion before you switch it on.
Salesforce SSO with SSOGEN signs users in to Salesforce under your sign-in policy, with MFA. Salesforce is the service provider (SAML) or the client (OpenID Connect), and SSOGEN is the identity provider. No catalog entry is needed: SSOGEN connects any application that speaks SAML 2.0 or OpenID Connect.
SSOGEN shows you the exact assertion it will send before anyone signs in. Below are the values to copy between the two screens. Salesforce’s admin screen uses its own labels, so match fields by meaning with the table.
Values to copy for Salesforce
| SSOGEN field or value | Vendor-neutral name in the application | Direction |
|---|---|---|
| Service provider entity ID | Entity ID, identifier, audience | From Salesforce into SSOGEN |
| Assertion consumer service URL | ACS URL, reply URL | From Salesforce into SSOGEN |
| Single logout URL (optional) | Logout URL | From Salesforce into SSOGEN, if it has one |
| IdP entity ID | Identity provider entity ID, issuer | From SSOGEN into Salesforce |
| Single sign-on URL | Sign-in URL, login URL | From SSOGEN into Salesforce |
| Signing certificate | Identity provider certificate | From SSOGEN into Salesforce |
| Name ID | User matching attribute | Choose in SSOGEN, set the same format in Salesforce |
- Salesforce metadata file. Upload it in the Connection step. The first three rows fill themselves.
- SSOGEN metadata address. Import it, and the last four rows, certificate included, are set at once.
Read the assertion before you activate
The wizard’s Test step picks a person and shows a SAML assertion card. It lists the NameID, authentication context, audience, recipient and each attribute with its value. Nobody signs in. Nothing goes to the application.
Check two things:
- NameID. It is the value the application matches on.
- Attributes. Any extra attributes are there.
The application is not active yet, so the availability line reads as failed, as expected. It clears when you activate.
Register, assign, test and activate
- In the Admin Console open Applications, then SAML (or OpenID Connect) and start the registration wizard.
- Fill in General and Connection with the values above, choose a Sign-in policy, and set Identify the person by.
- Enter the Launch URL, the address that starts the application’s own SSO sign-in. Selecting Next here saves the application, still unavailable.
- Assign a person or group, run Test for a named person, and read the result.
- Select Activate application. The application then appears in My Apps for the people assigned to it.
The full screens and every message are in Register a SAML application and Register an OpenID Connect application. The test and activation details are in Assign people, set the sign-in policy, test and activate.
Questions people ask
How do I set up Salesforce SSO with SSOGEN?
Register it as a SAML application, exchange the entity ID, assertion consumer service URL and certificate, assign people, test and activate.
Do signed requests have to be turned on?
No. SSOGEN does not require signed requests. You need a signing certificate only if the application signs them.
Where do I find SSOGEN’s values?
On the application’s Integration tab, which shows the metadata address, entity ID, single sign-on URL, single logout URL and signing certificate.
Where to go next
SSOGEN has run single sign-on in production since 2016.
- Hub. Go back to the SSO applications hub for the protocol comparison and other guides.
- Choosing a protocol. If you are not sure whether Salesforce belongs under SAML or OpenID Connect, read Choose how to connect an application.