Configuring SAML-based SSO with another Identity Provider

What Softadmin® needs

A stored procedure to receive assertions

Set the system setting SingleSignOnLoginProcedure to the name of the stored procedure responsible for extracting user attributes from the SAML Assertion. The structure of this assertion may vary depending on the Identity Provider (IdP).

If the IdP administrator cannot provide a sample, it's advisable to begin with a procedure that logs the received assertion. Configure a SAML integration to capture an assertion, and then complete the procedure by analyzing the logged XML.

Register the Identity Provider

Go to Admin > SAML 2.0 Single Sign-on > SAML Identity Providers > New SAML Identity Provider.

Metadata Url

The Softadmin® system gets all the information about the Identity Provider that it needs by reading a SAML metadata file that Identity Provider publishes.

If the IdP does not publish metadata then you can trick Softadmin® by creating your own metadata file by hand and serving it from any location. This will, however, require you to update the metadata file each time the IdP rotates its signing certificates.

Name ID format

The format the Softadmin® system wants to receive usernames in. You can usually leave this as unspecified, but if the Identity Provider demands that another format is used then you can specify it.

You can configure SAML 2.0-based Single Sign-on with a Softadmin® system as Service Provider and many SAML 2.0 compatible servers as Identity Provider.

What the Identity Provider needs

The Identity Provider will require some subset of the following information.

Service Provider metadata URL

The Softadmin® system publishes metadata describing it at /saml/sp (for example https://softadmin.example.com/saml/sp).

Service Provider identity

The value assigned to the system setting SingleSignOnSamldentity.

Assertion consumer service

The location the Softadmin® system receives SAML assertions at. It is located at /LoginPostback.aspx (for example https://softadmin.example.com/LoginPostback.aspx).

Binding used to receive assertions

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Name ID format

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified unless you specified something else when registering the Identity Provider with Softadmin® (see above).

Does Softadmin® sign its SAML Requests?

Not by default, but it can be configured to sign Authn requests if necessary.

Does Softadmin® support encrypted assertions

Not by default, but it can be configured to decrypt assertions if necessary.

Only encryption of the whole assertion is supported, not individual attributes or ID values.