Multiple logins in a day are disruptive to employees. Fortes Change Cloud supports Single Sign-On. With Single Sign-On (SSO), employees log in once to access the systems they need. This increases security and ease of use.
You can also use automatic user synchronization within Fortes Change Cloud to facilitate the management of extensive and/or complex processes.
Assigning permissions in Fortes Change Cloud continue to be controlled in the application so that the correct permissions can be granted.
How does Single Sign-On (SSO) work?
SSO is based on the concept of federated identity. This means that attributes are shared with trusted systems.
If a user is trusted by one system, he or she is also automatically granted access to all other systems that have a trusted relationship with the first system. This concept is the basis for modern SSO solutions supported by protocols such as OpenID Connect and SAML 2.0.
When a user logs in, an authentication token is created and stored in the user’s browser or on the SSO solution’s server. Any app or website subsequently opened by the user consults the SSO service which then transmits the user’s token to establish identity and grant access. There are two types of providers: service providers (SP) and identity providers (IdP).
- Service providers (SP) are the systems and applications that users use throughout the day.
- An identity provider (IdP) is the system that performs user authentication. This is the central location where login credentials are actually stored and validated.
The benefits:
An organization that follows SSO best practices can improve security with a reliable SSO solution. The following are the important benefits of Single Sign-On:
- Reduced attack opportunities: SSO eliminates poor password hygiene, immediately making your organization less vulnerable to phishing attacks. With SSO, users only need to remember one strong, unique password, and there are far fewer time-consuming and expensive password resets to perform.
- Seamless and secure user access: SSO provides real-time visibility into which users are using applications at what time and from what location. This allows organizations to best protect the integrity of their systems. SSO solutions also take into account other security risks, such as an employee losing the organization’s device. IT teams can immediately disable the device’s access to accounts and critical data in such a case.
- Easier control of user access: it can be difficult to provide the right people with the right level of access to sensitive data and resources in a business environment that is constantly changing. SSO solutions can be used to configure a user’s access rights based on job title, department or seniority. In this way, transparency and understanding of different access levels is always ensured.
- Independent and productive users: users are increasingly demanding fast and seamless access to the applications they need to do their jobs. Manually managing these types of requests is a time-consuming process that only creates frustration. SSO authentication eliminates the need for manual oversight and provides instant access to thousands of apps with a simple click of a mouse.
- Future-proof: SSO is the first step in securing your organization and your users. With SSO as a foundation, organizations can also implement other security best practices, such as Two Factor Authentication (2FA).
Risk:
The risk of Single Sign-On is that once you are logged in you can access anything. It is therefore strongly recommended that any SSO solution be combined with an additional level of authentication (Two Factor Authentication).
SSO and Two Factor Authentication:
One-time access should of course be secure. For logging into Fortes Change Cloud, Two-Factor Authentication (2FA) is recommended, thereby each linked application is also protected with 2FA. The identity provider makes this functionality available to users. This way 2FA will add additional security layer in your landscape.
Setting up Single Sign On for Fortes Change Cloud
To use Single Sign On, it is important that the identity provider can communicate with Fortes Change Cloud. Setting up an identity provider should be done in Fortes Change Cloud as well as at the identity provider itself.
By adding a ”trusted application” to the system of the identity provider, the identity provider knows that this application may be used by employees within the organization. Fortes Change Cloud therefore first needs to be registered with the relevant identity provider. Fortes Change Cloud supports the following protocols:
- Security Assertion Markup Language (SAML):
SAML stands for Security Assertion Markup Language and is one of the most widely used standards for exchanging authentication data. All products that use SAML can be used to interface with Fortes Change Cloud. Examples are: ADFS, OKTA, Azure, SURFconext, Shibboleth, OpenAM/OpenSSO, GlobalSign, etc.. - Shibboleth (also called SP):
The Shibboleth project is an implementation of SAML. Shibboleth is an identity provider that uses OpenSAML to provide SAML functionality.
Examples of SSO documentation (identity provider):
- ADFS: https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services
- OKTA: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Overview_of_Managing_Apps_and_SSO.htm
- Azure: https://docs.microsoft.com/nl-nl/azure/active-directory/saas-apps/fortes-change-cloud-tutorial
- SURFconext: https://wiki.surfnet.nl/display/surfconextdev/SAML+Basics
After registering, the identity provider often asks for a number of details.
- Name: the name of the application in question
- Domain: the (sub) domain on which the application runs
- Redirect URI: the location within Fortes Change Cloud where the user is sent when logged in to the identity provider. Example: https: //mycompany.fortes-online.com
Note! The service provider needs a metadata file or the federation URL from the identity provider. Please contact support@fortes.nl for this.
Creating and migrating (existing) users:
In Fortes Change Cloud, the option is given to set the creation of new users and the migration of existing users.
Two settings exist for this purpose:
- Manually create/update users:
When Single Sign-On is used, the match is done on a unique identifier.
On the side of the identity provider and the service provider the user should be identical. You can choose to enter the user data manually in the user manager or import it once in a while as resources and then upgrade it in Fortes to resources with a user name. To do this, use an import task
- Automatically create/update new users:
It is also possible to automatically create new users or update existing users. If this setting is on, the administrator at the identity provider can mark users to use Single Sign On in conjunction with automatic user synchronization. This is done via the SCIM protocol.
What is SCIM?
SCIM, or System for Cross-domain Identity Management, is an open standard for automated user synchronization of users.
SCIM communicates user data between identity providers and service providers that require user identity information.
The client is usually an identity provider (IdP), such as Okta or Azure that contains an active directory of user data. A service provider (SP) is typically a SaaS app such as Fortes Change Cloud.
Why use SCIM?
In a nutshell, SCIM makes user data more secure and simplifies the user experience by automating an existing process.
As organizations grow, the number of users usually increases exponentially. All the requests to add and remove users, change permissions and add new types of accounts consume valuable IT time.
With SCIM, user data can be created directly at an identity provider (OKTA, Azure, etc..) or imported from external systems such as HR software or Active Directory. In addition, the potential for errors is dramatically reduced.
IT departments no longer need to develop and constantly update custom integrations to connect directories to various external tools and apps.
Because it is a standard, it has the added benefit of storing user data in a consistent manner. This allows IT departments to automate the existing process while also managing permissions and groups from one system.
This is how SCIM implementation works.
Both on the identity provider side (Okta, Azure, etc..) and on the service provider side (Fortes Change Cloud), things need to be configured.
- Enable SCIM (SP):
as of version 12.1 of Fortes Change Cloud, it is possible (on request) to use SCIM for user synchronization. For this, Fortes must enable a specific module. There are no further costs associated with this. Please contact support@fortes.nl for more information. When SCIM is enabled you will find the setting under the configuration menu in Fortes Change Cloud. On this page you will find the tokens you can use to establish the link.
The primary and secondary token is an automated unique token that is different for each customer. If you are using the primary token or decide to use another system with SCIM the secondary token can be used. If you want to renew both tokens you can use the button “Refresh token”.
- Create a test setup (IDP):
Make sure you first test the link in a test setup. For example, you can choose to use a test identity provider or test with one user. This way you reduce the risk of something going wrong in production. - Configure SCIM (IDP) (Okta, Azure, etc..):
Because each provider’s operations are different, the following is documentation of the most commonly used identity providers:- Azure: https://docs.microsoft.com/nl-nl/azure/active-directory/saas-apps/fortes-change-cloud-provisioning-tutorial
- OKTA: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard_SCIM.htm
- Amazon AWS: https://docs.aws.amazon.com/singlesignon/latest/userguide/scim-profile-saml.html
- OneLogin: https://developers.onelogin.com/scim
- Synchronize user data to Fortes:
When data is changed on the identity provider side, such as first name, mail address or username, this data is automatically synchronized with Fortes.
The identity provider can also read data from Fortes and correct incorrect values. It is therefore important to check which unique field will be used for this purpose. Usually this is the username or e-mail address.
When employees enter and leave the company, the user in Fortes is also affected. When an employee enters the company, a user is created or activated in Fortes and when he or she leaves the company, the user is archived. It is good to know that data is not lost when leaving the company and that employees who return can be made active again in Fortes without losing historical data.
