Add a SAML application in SSOGEN

• An administrator role that can save SAML settings. Super admin can do every step. An Application admin also needs the Authentication admin role to save the SAML part, and a role that reads the directory (Directory admin, Read-only admin) to assign people and run the test.
• A sign-in policy. At least one policy under SSO policies > Policies, and either a default under SSO policies > Defaults or a policy you pick in the wizard. An application without a policy cannot be activated.
• From the application: its entity ID and its assertion consumer service (ACS) URL, or its SAML metadata as an https:// address or an XML file. The application page says where the application shows them.
• The address where the application starts a sign-in. It becomes the launch URL of the tile in My Apps.
• The people and groups who will use the application, already in SSOGEN.

Select Next.

Give SSOGEN the application’s values in one of three ways.

• Read its metadata from an address. Paste the address in Metadata URL and select Read metadata. The address must use https:// and be reachable on the internet; an address on a private network is refused. Use the file upload for those.
• Upload its metadata file. Use Or upload the metadata file (optional). The file can be up to 256 KiB.
• Type the values.

After reading metadata, the card Review what the metadata declares lists the entity ID, the ACS addresses, the logout address and the certificates. Where there are several ACS addresses, choose the one to use; only HTTP-POST addresses can be chosen. Select Use these values.

Select Next.

Identify the person by decides what SSOGEN puts in the name ID of the assertion. Choose the value the application matches its accounts on; the application page says which.

If an application asks in its sign-in request for a name ID format that the choice cannot give (for example it asks for emailAddress while the person is identified by the permanent SSOGEN user ID), SSOGEN answers with a SAML error instead of an assertion. Set the application to the format in the table, or to “unspecified”.

Extra attributes. Where the application reads attributes beside the name ID, select Add an attribute, type the attribute name exactly as the application expects it, and choose the SSOGEN value to send: email, display_name, username, given_name, family_name, groups, subject, or a source value. Leave the third control as it is. Attribute names use letters, digits, dots, hyphens and underscores, start with a letter or digit, and are up to 128 characters long. Attributes can also be added later on the application’s Identity sent to app tab.

Select Next.

Open the application’s Integration tab. The section SSOGEN as your identity provider holds everything the application asks for. Each row has a Copy button.

The NameID format row always shows persistent. Give the application the format that follows from your choice in step 6.

These identity provider values are the same for every application on your SSOGEN address. Settings > Certificates shows the metadata address before any application exists, for an application that wants SSOGEN’s values first.

Certificate fingerprint and expiry date. Some applications ask for the fingerprint of the signing certificate instead of the certificate. Print it, and the expiry date, from the downloaded file:

openssl x509 -in ssogen-idp-signing-certificate.pem -noout -enddate -fingerprint -sha256

Note the expiry date. An application that stored the certificate or its fingerprint needs the new one before the old one ends; an application that reads the metadata address picks it up when it refreshes.

What every application can rely on:

• SSOGEN signs every assertion with RSA-SHA256 and a SHA-256 digest, and puts its certificate in the signature. The outer response is not signed separately; where an application asks which part is signed, choose the assertion.
• Requests from the application need not be signed. SSOGEN reads requests sent by HTTP-Redirect (deflated, as the standard describes) and by HTTP-POST.
• The issuer of every assertion is the IdP entity ID. The audience is the application’s entity ID. The answer is posted only to the registered ACS URL, with the relay state the application sent, unchanged.
• An assertion is valid for five minutes.
• The sign-in starts at the application. SSOGEN answers the application’s sign-in request; it does not post an assertion that nobody asked for.

Select Test, choose a person and select Run test. The result says “{person} can open {application}.”, “{person} would be asked for a second factor.” or “{person} cannot open {application}.”, with every check. Compare NameID in the SAML assertion card with the value the application holds for that person.

The Overview tab shows the status: