SSOGEN / Identity providers / Shibboleth SSO With SSOGEN
Integration
Shibboleth SSO With SSOGEN
Shibboleth SSO works with SSOGEN through SAML 2.0. SSOGEN is the service provider, your Shibboleth identity provider authenticates, and three details decide whether it works.
Shibboleth SSO with SSOGEN means your Shibboleth identity provider signs the person in, and SSOGEN accepts the SAML assertion. You register SSOGEN with the Shibboleth IdP as a service provider.
Universities, research bodies and partner organizations that run Shibboleth then use their own accounts. They reach every application that SSOGEN protects.
That includes Oracle E-Business Suite and PeopleSoft behind the SSOGEN Web Agent.
Three details make the connection work:
- Metadata. Metadata for one entity.
- NameID. A NameID that stays the same for a person.
- Attributes. Attribute names typed exactly as Shibboleth sends them.
The wizard is described in the SAML guide.
Give SSOGEN metadata for one entity
Shibboleth deployments often sit inside a federation whose metadata file lists hundreds of entities. SSOGEN refuses such a file: “That document describes more than one entity” or “more than one identity provider.”
Use the metadata of your own identity provider only. It must publish:
- An entity ID.
- A single sign-on endpoint. An https HTTP-Redirect endpoint.
- A signing certificate. At least one. SSOGEN verifies every assertion against it, and activation requires it.
What to set on the Shibboleth side
- Start the Add SAML Provider wizard in SSOGEN and copy the SP entity ID, ACS URL and SP metadata URL.
- Register SSOGEN with your IdP as a service provider. The easiest route is to give the IdP team SSOGEN’s metadata. You can download it as
sp-metadata.xmlfrom the provider’s page. - Make sure assertions are signed. If your IdP also encrypts assertions, that works too, because SSOGEN can decrypt encrypted assertions.
- Release an email attribute to SSOGEN, and a display name if you want one.
- Release a NameID that is the same every time for the same person.
Keep the NameID stable
SSOGEN never maps the username. It builds the username from the NameID and uses it to recognize the person next time.
- Avoid per-session identifiers. If your IdP can issue identifiers that differ per session, do not use one here, because every sign-in would look like a new person.
- Check with Try signing in. The result page shows “Signed in as” and says whether this would be an existing account or a new one.
Map attributes by exact name
SSOGEN’s default mapping uses the long Microsoft claim URIs for email and name. A Shibboleth IdP releases attributes under its own names, so check what arrives.
- Run the test sign-in.
- Read What the provider sent.
- Type those names in the Mapping step.
A field left empty still matches common names such as mail and email. If none match, the account has no email address instead of a wrong one.
Partner sign-in and routing
When partner organizations bring their own Shibboleth IdP, add each as a separate provider and assign it sign-in domains, such as partner.example.
The sign-in page then asks for an email address first and sends the person to the right provider by the domain.
- One provider per domain. Each domain belongs to one provider.
- Up to 20 domains. Each provider can have up to 20.
- Sign-in restriction. A provider can carry a required claim with the values you allow.
| Message | Fix |
|---|---|
| Another provider already uses the domain | Remove it from the other provider first |
| That metadata does not publish an entity ID | The file is not IdP metadata |
| The assertion carried no subject (NameID) | Release a NameID to SSOGEN |
| The provider did not send an attribute this connection requires | Release the attribute or fix the Mapping |
When the Shibboleth certificate rolls over
A Shibboleth IdP changes its signing certificate from time to time. With a Metadata URL:
- Edit the provider, choose Metadata URL again, select Fetch metadata and save a revision.
- Validate, Test and Activate it.
Sign-in continues on the old configuration until the new revision is active, so schedule the activation before the old certificate expires.
- Uploaded a file? Upload the new one the same way.
- Test fails? If a test fails with “A signing certificate in the provider’s metadata has expired”, renew the certificate at the IdP first.
Questions people ask
Can SSOGEN fetch my IdP’s metadata automatically?
Yes, from an https Metadata URL, if SSOGEN’s server can reach it. Private addresses are refused, so upload the file instead.
Does Shibboleth need to know SSOGEN’s certificate?
Only if you turn on signing of SSOGEN’s requests. Import the certificate from SSOGEN’s metadata first.
Where to go next
- Checklist. Use the SAML checklist.
- Providers. Compare providers on the hub.
- Routing. Read how the sign-in page routes by domain.
SSOGEN has run in production since 2016. Get trial access to see Shibboleth SSO with your own applications.