SSO - Single Sign On
When using Single Sign-On or a custom URL, it is essential to ensure that Umantis be informed well in advance of any certificates that are about to expire. To avoid unnecessary disruptions to your day-to-day business, the new certificate should be received by Umantis-umantis Support at least 45 days before expiry.
Umantis Cloud SSO (ADFS)
The Umantis Cloud SSO (Single Sign On) component provides direct access from your internal company ADFS (Active Directory Federation Services). For users, this means that they do not have to log in again separately to the Umantis solution. The ADFS connection is based on SAML 2.0 claims authentication (Security Assertion Markup Language). At minimum, this requires a server configured for ADFS 2.0. The service can be used after adding Umantis to a trusted site and after successful validation.
All IdPs that can create a SAML2 token are supported, including:
- Microsoft® Active Directory Federation Services 2.0 to 4.0
- Microsoft® Azure
- Shibboleth® Identity Provider
Details on configuration are provided below, and are available for download in the following document:
ADFS version compatibility: 2.0 to 4.0
- German: Umantis Cloud SSO configuration (as of September 2023)
- English: Umantis Cloud SSO configuration (as of September 2023)
Tips for customers who are just starting to work with SSO:
- The login data for existing users works until the first login via SSO
- In the context of SSO, a new feature in Applicant Management is that users like HR and managers can log in with their existing user account
Activation and deactivation
- Parameter to activate SSO for a request: ?v4login=sso
- Parameter to deactivate SSO for a request: ?v4login=1
“Single Sign On via browser certificate (PKI)”
Since the end of 2018, PKI is no longer supported
To enable authentication via PKI (Public Key Infrastructure), Umantis requires the following files/information:
- The valid CA (certificate authority), as appropriate for the client certificates you are using
- Ideally, an appropriate client certificate (for support during setup)
Cannot switch users via PKI
When authentication via PKI is in use, it is not possible to truly switch users, because the user is identified by means of the browser certificate, and a certificate can only be assigned to one user.
This reinforces the security of this approach.
Note on authentication with the Safari browser (error message: 400 Bad Request)
- Authentication is normally limited to IPs within the company. In the Safari browser, however, the user may sometimes be asked whether the certificate should also be used for authentication with access from other (outside) IPs — as with all applicants. If the applicant clicks “Yes” here, authentication cannot take place, and the 400 error message is displayed. If the applicant clicks “No”, everything works as normal and the application process can continue.
“Settings in the Umantis system”
Check the box to “Use PKI” in the Security settings under SSO to enable certificate verification for your system. Then select the fields that should be used for identification. For instance, you might choose to skip the validity check for the date by leaving the fields for NotBefore and NotAfter unchecked. For the Issuer and Subject fields, you can also use regular expressions to add restrictions to your check on the text from the certificate.
For the next step, you can then go to Settings for each employee, or to the user profile for each user, then to “PKI settings”, and enter the individual data from their personalized certificate.
The fields are named: Issuer, Subject, NotBefore, NotAfter.
The data for these fields are found in the user certificate. Make sure that the data conform to the following pattern:
Issuer = C=CH, ST=SG, L=St. Gallen, O=umantis AG test, OU=IT, CN=ege, emailAddress=admantis@umantis.com
Subject = C=CH, ST=SG, L=St. Gallen, O=umantis AG, OU=Development, CN=John Doe, emailAddress=john.doe@umantis.com
NotBefore = 01/05/2010
NotAfter = 31/31/2010
You can also read the information into the solution with an import. You must also ensure that the validity dates are each one day less than the date indicated in the certificate.
Ex.: NotBefore in certificate = 02/05/2010 corresponds to NotBefore for employee: 01/05/2010
“Importing the certificate into the browser”
Firefox: Extras => Settings => Advanced => View Certificates => Import
Internet Explorer: Extras => Internet Options => Certificates => Import
| Variable | Applicant Management | Employee management |
| Issuer | [User.PKIIssuer] | [Person.PKIIssuer] |
| Subject | [User.PKISubject] | [Person.PKISubject] |
| NotBefore | [User.PKINotBefore] | [Person.PKINotBefore] |
| NotAfter | [User.PKINotAfter] | [Person.PKINotAfter] |
Authentication via URL parameters
Umantis offers a simple method of Single Sign On integration via URL parameters. Users should be able to use Umantis simply by clicking on a link, without having to log in a second time. To do this, you can set up a link in your intranet that takes people with existing Umantis user accounts directly to the Umantis home page without having to log in. With this approach, your employees only need to log in to get access to your intranet (which is attached for instance to an LDAP).
Please be sure to log out of public computers after using this function. Otherwise, you will stay logged in, making it easier for outsiders to gain unauthorized access.
Setting up the link in Umantis
(Employee Management example)
You integrate the following link with various parameters: https://[CustomerSolution]/?loginparam=[logintoken]
| [CustomerSolution] | URL for your Umantis solution | employeeapp-0000.umantis.com or recruitingapp-0000-umantis.com |
| [MetaAlias] | Your Umantis MetaAlias. Request your MetaAlias from your Umantis contact person or by emailing our Customer Service team. | http://sso.umantis.com/sp-acme |
| [login] | The person’s login name | John.Doe@acme.com |
| [timestamp] | Current time in epoch milliseconds (converter: http://currentmillis.com/) | 1496747313104 |
| [SigAlg] | Signature algorithm | rsa-sha1 or rsa-sha256 |
| [Signature] | RSA signature with private key, Base64-encoded with the following values: Base64 (RSASign (user=[login]×tamp=[timestamp]&metaAlias=[MetaAlias]&SigAlg=[SigAlg])) | |
| [logintoken] | Base64 (user=[login]×tamp=[timestamp]&metaAlias=[MetaAlias]&SigAlg=[SigAlg]&sig=[Signature]) |
Notes:
- The timestamp must be 13-digit and be shown in milliseconds (cf. above table)
- The RSA signature must be created with the private key you generate yourself.
- Please send the (appropriate) public certificate you have generated to your Umantis contact person so that they can store the certificate correctly (under Settings for company/organization profile > Security settings).
Use of special characters is allowed.
Examples
user=John.Doe@acme.com×tamp=1496747313104&metaAlias=http://sso.umantis.com/url-acme&SigAlg=rsa-sha1&
sig=O3YDy9RN8xK8RDcSg+y7rHMzwYRp9nbkluFg0EX82enUifKZVsHrfxNqXAfPulcOlmt13Tm1HveAN/POmTXmOlmN9z7kPSE2
/mJC9LeA3F4yNR5e63ARk2SmyjEZVXMBOqKlJZGZXHZ+GojpiqR9Ebwpr+HbH8NvSHA1HCgAu3EmCCXyctMehjjFz2cAA1NZkDYXxdtW5Qt2uzNi7i46i+lLWhr28kqLIfLLFF9f223lGXhIY0
QSEX+SZHNLwZmILqlsoh4Uf0C4eHp6wgEhXDs/PbbOsnfYIFA25ho5/sUhT7dXU7KQeTIMge/rBKVYh7QkSGiXRCn8ZQZHoxLPBQ==
https://employeeapp-0000.umantis.com/SelfService/?loginparam=dXNlcj1Kb2huLkRvZUBhY21lLmNvbSZ0aW1lc3RhbXA9MTQ5Njc0NzMxMzEwNCZtZXRhQWxpYXM9aHR0cDovL3Nzby51bWFudGlzLmNvbS91cmwtYWNtZSZTaWdBb
Gc9aHR0cCUzQSUyRiUyRnd3dy53My5vcmclMkYyMDAwJTJGMDklMkZ4bWxkc2lnJTIzcnNhLXNoYTEmc2lnPU8zWUR5OVJOOHhLOFJEY1NnK3k3ckhNendZUnA5bmJrbHVGZzBF
WDgyZW5VaWZLWlZzSHJmeE5xWEFmUHVsY09sbXQxM1RtMUh2ZUFOL1BPbVRYbU9sbU45ejdrUFNFMi9tSkM5TGVBM0Y0eU5SNWU2M0FSazJTbXlqRVpWWE1CT3FLbEpaR1
pYSForR29qcGlxUjlFYndwcitIYkg4TnZTSEExSENnQXUzRW1DQ1h5Y3RNZWhqag0KRnoyY0FBMU5aa0RZWHhkdFc1UXQydXpOaTdpNDZpK2xMV2hyMjhrcUxJZkxMRkY5ZjIyM2x
HWGhJWTBRU0VYK1NaSE5Md1ptSUxxbHNvaDRVZjBDNGVIcDZ3DQpnRWhYRHMvUGJiT3NuZllJRkEyNWhvNS9zVWhUN2RYVTdLUWVUSU1nZS9yQktWWWg3UWtTR2lYUkNu
OFpRWkhveExQQlE9PQ==
Online tool for Base64 encoding
Important notes
- Case sensitivity: You must ensure that all data is written in the same way (upper/lower case) in both systems (customer intranet and umantis) whenever it is stored or transferred. This also applies to master data imports.
- Login name for every employee using SSO: Every employee who wants to be authenticated via SSO must have a login name.
- Active job: Employees who want to be authenticated via SSO must have an active job in the system. (This differs from authentication via login name and password, for which it doesn’t matter whether an active job is present.)
- Note that the appropriate link target must also be provided for each different role. For example, for the manager view in Applicant Management, it is compulsory that the suffix “/SelfServiceLine” be included in the URL.
Logging out of Umantis with SSO
If you are trying to log out with SSO and keep getting automatically logged back into SSO, we recommend the following solution:
- Configure the “Logout” button/link as follows in configuration mode: /?Logout=6&redirectAfterLogout=/Password/LoggedOut
SSO FAQ
User administration
Question: Once SSO has been completely implemented, is it sufficient to administer user roles and permissions in Active Directory, or do they also need to be administered in the user administration area in Umantis? To take a specific example: If a manager joins the company, is checking the box for “Manager in Umantis Applicant Management” sufficient to allow the manager to log in at the corresponding Umantis URL, with no need for the system administrator to take additional steps in Umantis (e.g. creating a user)?
Answer: Umantis uses SSO only for authentication and not for authorization. Therefore, you must still perform a user import with the relevant role assignment. Only after a user has been imported into Umantis with the “correct” login name (which is imported from the previous system and compared with AD) will the user be able to log in.
Password guidelines
Question: What impact do password guidelines configured in Umantis have on SSO? For example: Password guidelines are configured more strictly in Umantis than in Active Directory — do these guidelines actually still apply when data are delivered via SSO, or do administrators need to make sure that the guidelines are consistent?
Answer: The password guideline applies for all users that sign in with a login name and password. Once a user signs in with SSO for the first time, they are then identified accordingly. From this point on, the password guidelines from Umantis no longer apply to this SSO user, and the Active Directory (AD) guidelines apply instead.
SSO as Iframe
Question: Does SSO function in conjunction with Iframe?
Answer: No, this is not possible. Authentication in Iframe is prevented by MS ADFS (cf.: ADFS Forum).