Personal tools

SSO - Single Sign On

From Onlinehelp

Jump to: navigation, search

umantis Cloud SSO (ADFS)

The Haufe-umantis Cloud SSO (Single Sign-On) component provides direct access from your company-internal 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.

Details on the configuration are provided below, and are available for download in the following document:

Info.gif ADFS version compatibility: 2.0 to 4.0

Info.gifTips for customers who are just starting to work with SSO:

  • Login data for existing users work 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)

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)

Info.gifCannot 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.

Attention.gif 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 example, you might choose to skip the validity check for the date by leaving the boxes 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,
Subject = C=CH, ST=SG, L=St. Gallen, O=umantis AG, OU=Development, CN=John Doe,
NotBefore = 05/01/2010
NotAfter = 12/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 below the date indicated in the certificate.
Ex.: NotBefore in certificate = 05/02/2010 corresponds to NotBefore for employee: 05/01/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 e.g. to an LDAP).

Attention.gif 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)
Integrate the following link with its various parameters:https://[CustomerSolution]/?loginparam=[logintoken]

[CustomerSolution] The URL for your umantis solution
[MetaAlias] Your umantis MetaAlias. Request your MetaAlias from your Haufe-umantis contact person or by emailing our Customer Service team.
[login] The person’s login name
[timestamp] Current time in epoch milliseconds 1496747313104
[SigAlg] Signature algorithm rsa-sha1
[Signature] RSA signature with private key, Base64-encoded with the following values: Base64 (RSASign (user=[login]&timestamp=[timestamp]&metaAlias=[MetaAlias]))
[logintoken] Base64 (user=[login]&timestamp=[timestamp]&metaAlias=[MetaAlias]&SigAlg=urlencode([SigAlg])&sig=[Signature])


  • The RSA signature must be created with the private key you generate yourself.
  • Please send the (appropriate) public certificate you have generated to your Haufe-umantis contact person so that they can store the certificate correctly (under Settings for company/Organizational profile > Security settings).
    Info.gif Use of special characters is allowed.


> [logintoken] with no Base64 encoding

> Example URL

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, the suffix “/SelfServiceLine” must be included in the URL.

Archive (MD5 variant — no longer supported as of September 2018!)

Info.gif Information about the (obsolete) variant with MD5 key
(click on “Expand”)

Setting up the link in Employee Management and Applicant Management Employee Management example
Integrate the following link with its various parameters:

[CustomerID] Your umantis CustomerID 1
[PersKey] The unique key for the person 100
[SourceSystemKey] The unique key for the source system; use only if you work with multiple third-party systems 14
[Digest] md5 encryption over the following values:
md5( [CustomerID] & [PersKey] & [SourceSystemKey] & [AuthenticationKey])

If the SSO (Single Sign On) with timestamp option is activated under Settings for company / organizational profile, then the digest must be set up as follows:

[Digest] md5 encryption over the following values:
md5( [CustomerID] & [PersKey] & [SourceSystemKey] & [AuthenticationKey] & [Timestamp])
In the timestamp, the current date (UTC) must be entered in YYYYMMDD format.

The people and the source system key are found in the employee file under Settings.

The authentication key is defined under Settings for company / organizational profile > Authentication key for Single Sign On (SSO). Use of special characters is allowed.

Example for MD5 key The authentication key used in the example is um@nti$. To test the calculation of the digest (md5 key), enter the data here and select md5: Test calculation

Calculation with the example produces the following digest: cf5864612b8d01fda183ed97b73f9c15


  • Info.gif From an IT security perspective, umantis recommends that all of its customers implement the authentication CGI parameter only through an HTTP POST request, and only with a timestamp. The recommended Cloud SSO (ADFS) variant is even safer.

The advantages and disadvantages of GET and POST requests are explained briefly below.

Advantages Disadvantages
GET Can be integrated into your intranet as a simple link. - URL can be “saved” by the user and accessed from anywhere.
- Parameters can be read as cleartext on any router between the user and umantis -> security issue!
POST - Safer, because the parameters cannot be read by the user or any router “in between”.
- Link on the intranet can be directed to a “hidden” page that provides/calculates the parameters and completes the HTTP POST request.
Somewhat more effort to integrate in the intranet.

  • Info.gif Case sensitivity: You must ensure that all data (PersKey and SourceSystemKey) is written in the same way in terms of upper/lower case in both systems (customer intranet and umantis) whenever it is stored or transferred. This also applies to master data imports.
  • Info.gif Login name for every employee using SSO: Every employee who wants to be authenticated via SSO must have a login name.
  • Info.gif 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.)
  • Info.gif Please note that the appropriate link target for different roles must also be included; for example, in Applicant Management, the “/SelfServiceLine” path segment must be included in the URL for the manager cockpit.
  • Info.gif Please note that for a standalone solution, the customer ID is always “STANDARD”.
  • Info.gif A link target can also be included with a “&NextTarget=” parameter. An example of this would be linking to a public page while logged in. This can only be done by redirecting through a non-public page. For example: https://employeeapp-['''CustomerID''']['''PersKey''']&sourcekey=[SourceSystemKey]&digest=['''Digest''']&NextTarget=/Public/Courses&customer=['''CustomerID''']

Logging out of umantis with SSO

Info.gif 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

Using SSO (v4-login) with the Hiring Manager application

Info.gif This section is only relevant if you are using the Hiring Manager application.

Hiring Manager notifies the user (hiring manager) of certain events via system e-mails, such as the receipt of a new application or an outstanding decision to approve a job (or not). The user receives a URL link to the relevant application or job profile in the umantis solution. By clicking on this link, the user is sent directly to the relevant job, and is not redirected to the Hiring Manager home page.
To ensure that this redirection to the target URL will also work when using an SSO v4 login, a separate link/button for SSO users must be configured on the login page (/SelfServiceLine).

User example:
If a separate link/button has been correctly configured on the login page (see below under Configuration), a user example could look like this:

  1. The user clicks on the Hiring Manager link sent by e-mail:
  2. The user is forwarded to the login page:
  3. The user clicks on the SSO button (e.g. LOGIN THROUGH FANGERY ACCOUNT (SSO)):

  4. The user is logged in via SSO and automatically redirected to the Hiring Manager link originally sent via e-mail:

To configure a separate link/button for SSO users on the login page:

  1. As an administrator, navigate to the login page in the SelfServiceLine area:
  2. Use configuration mode to configure the SSO link/button with the following redirection URL:
    <a href="/SelfServiceLine?v4login=sso&redirectAfterLogin=/HiringManager/"><b>Login with SSO</b></a></a>


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.