Single sign-on, also known as SSO, is a user authentication process that connects Visma Severa with your Active Directory.
Connecting Visma Severa with your central directory will automate user authentication and provide increased control for the system administrator when adding, changing or deleting users.
- Single sign-on is an add-on only available with the Enterprise Edition of Visma Severa, and it must be activated in order to view and use the features described below.
- Our solution is based on Microsoft’s Active Directory Federation Services 2.0 (ADFS 2.0). The instructions below are made using Microsoft's Active Directory product.
- Severa mobile app cannot be used when AD is used.
Single sign-on add-on cannot be purchased directly from Visma Severa's Upgrades-section. Contact us!
- External DNS name is needed. If it doesn't exist create new Host (A record) in DNS Manager.
- Setup ADFS
- If there are more than 1 domain controller, ADFS role has to be installed to all the domains.
- If there is a firewall, allow sync.severa.com.
- Add trust relationship
- Use the Visma Severa Federation metadata URL that is provided in Visma Severa > Tools > Settings > Single sign-on > Federation metadata URLs.
- Map the LDAP attributes "given name", "surname", "email" and "group" to outgoing claim type correctly in Relying party trust > sync.severa.com > edit claim rules.
- Claim Rule Template: Send LDAP Attributes as Claims. Add Claim Rules one by one:
- Given-Name = Given Name
- Surname = Surname
- E-Mail-Addresses = E-Mail Address
- Is-Member-Of-DL = Group
- Download the Visma Severa certificate bundle from Visma Severa > Tools > Settings > Single sign-on > Root certicates and install VismaSevera-Public-CA certificate to trusted root cert authorities.
- Download your root certificate from ADFS and upload it to Visma Severa > Tools > Settings > Single sign-on > Root certicates. Make sure the token signing and encryption certificates are domain certificates issued by the root CA/intermediate CA (certificate chain). The certificates should use external domain name (check certificate properties ex: SAN name, Subject). The certificate revocation list should be accessible to outside world (ex: http://<crl.custorg.fi>/crld/<rootcert>.crl)
WARNING: Settings for Single sign-on are accessible to all employees with Administrative access rights, but should not be changed without explicit instruction from the system administrator.
In Visma Severa, click on Tools > Settings in the top menu, and then click to open Single sign-on.
In the access rights mapping table, enter the group definition for each access rights profile by clicking the pen icon in front of the row. Save each group definition, and select a default profile to be automatically assigned to users who don’t have a matching group definition.
The group definition consists of a string of coded names that form a policy. Policies are described in the central directory and are used to specify security, privileges and other administrative rules.
The access rights mapping table prioritizes profiles from the top down. The priority indicates the order in which group definitions are processed, and it’s extremely important to maintain the correct priority.
Group definitions with a high priority (at the top of the list) are processed first, and then they are no longer considered for access at another level. For this reason, the Administrator policy is processed first and everyone meeting that policy criteria is given access with the appropriate credentials.
If for example, the priority is changed so that the Employee policy is at top and processed first, users with the administrator access rights might be granted with Employee credentials and then not be considered when the Administrator policy is processed. The end result would be administrators without proper credentials or access.
When a new user account is created in Visma Severa, it will automatically get the default business unit and supervisor selected in the Tools > Settings > Single Sign-on settings.
Visma Severa administrator or supervisor can change the default values to correct ones in user's details via Tools > User management.
Add the domains used in the organization. Users can login using only the email addresses that end with the domains added here.
in the section called "Companies" it is possible to limit a login for a certain part or unit of the organization. Only those users who have the same value in Active Directory's Company -field as is written in the Visma Severa settings are allowed to login.
Federation metadata URLs: Federation metadata url can be found in ADFS 2.0 > Service > End points > metadata (at the end). Federation metadata XML should be accessible from outside. URL example : https://<your_federation_service_name>/FederationMetadata/2007-06/ FederationMetadata.xml. Copy the URL into "Your URL" field and Save. Visma Severa's URL is needed when adding a trust relationship in ADFS.
Claim provider identification URLs: Copy from ADFS your URL and Save. Visma Severa's URL is needed when adding a trust relationship in ADFS.
Certificates: Download Visma Severa's certificate bundle and use them when creating a trust relationship in ADFS. Bundle includes VismaSevera-public-CA and VIsmaSevera-intermediate-CA certificates. After you have completed the trust in ADFS export your organizations certificates and upload them to Visma Severa.
When connection settings are done, contact Visma Severa customer support so that we can finish the configuration by creating the trust in our end.
Note! Verify that your metadata url is working using web browser. The web site should return the metadata when the url is working. Common reasons why url is not working is for example firewall or your certificate is missing the private key.
Users will continue to login to Visma Severa from the regular login page. From the Version drop-down menu, user selects Visma Severa Single sign-on. Then, user should enter his/her email address and click Login. Visma Severa will authenticate the user according to their group policy in the central directory. When organization is using Single sign-on, login with email and password will not work.
If you are unable to login to Visma Severa, please contact your system administrator to verify that your information is correct in the central directory and that there are User seats available.
Users are managed in Active Directory. New users cannot be added in Severa manually anymore and existing ones cannot be inactivated. When new user logs into Severa, he will get the default supervisor, business unit and access rights profile defined in the SSO settings. Administrators should check user's details in Severa and change those to be correct. At the same time other settings, such as work contract and work hour balance should be set correctly.
Changing email, password and access rights is performed in the active directory. If users name changes note that you have to update users name and email first in Severa and then in Active Directory (if information are only updated in Active Directory it creates new user in Severa). As default users will get access rights from Active Directory but this setting can be overruled per person in user's access rights. When Active directory access rights are overruled, user uses Severa's access rights while working in Severa.
It is possible that users added to the central directory cannot access Visma Severa if the number of user seats in Severa has been exceeded.
If a user who previously logged into Visma Severa is inactive for over two months the account will be deactivated in Visma Severa. The account will be automatically reactivated when they login again as long as their information in the central directory hasn’t changed and there are user seats still available.