Single sign-on (SSO)

What is it? 

Single sign-on (SSO) allows users to sign in automatically without having to input their username and password each time they log in. 

Our professional services team will guide and instruct your IT department on the one-time configuration that is necessary to configure the standard SSO protocol SAML 2.0.

With SSO, the organizational details of each user, coming from your organization's active directory, are synchronized with your ITONICS application. This allows mapping user roles and groups so that users are signed in to the appropriate roles, groups, and permissions.

How does it work?

Login with SSO

• Use the ITONICS system URL from any web browser
• When you land on the ITONICS Login Page, click on the button Login for <client> employees. You will be redirected to your SAML Identity Provider (e.g. Active Directory Federation Services, Azure ADFS or OneLogin. Most SAML Identity Providers are compatible). An automated redirection when hitting the URL is also configurable.
• You will be asked to authenticate with your credentials at the Identity Provider.
• The defined SAML token is sent back to ITONICS.
• The SAML data is verified by ITONICS and if successful, you are authenticated.
• When you complete this process for the first time, the system assigns a defined standard user role, creates a user account in the ITONICS user management, and imports the data defined in SAML claims. This includes attributes like User ID, Username, E-Mail, Firstname, Surname, Location, etc.

The above described the ITONICS standard procedure for setting up SSO, but you can also assign user roles in these two ways:

• User role is assigned by the Application Owner manually.
• User role is assigned via SSO claims based on pre-defined Active Directory Groups on the client-side.

Integrate SSO

Integrating SSO is a little more technical. We recommend getting your IT department to work with ITONICS to set this up. Please get in touch with your Customer Innovation Success Manager to initiate the integration.

For a smooth integration, the following prerequisites are required: 

• Clarify if you need/have a custom URL
• Get a Test User for ITONICS to test the SAML Integration (optional, recommended)

The following steps describe the ITONICS Standard Integration of SAML: 

• ITONICS sends out the SAML metadata for the production system
• The Customer IT Team imports the metadata in their ADFS
• The Customer sends the metadata back to ITONICS
• ITONICS integrates the metadata of the customer
• After the metadata Exchange is done, the Login has to be tested
• If the Login works fine, the default Login of the system will be changed to SAML

Maintain SSO

The initial SSO Setup might be subject to change occasionally. Therefore, ITONICS offers an SSO Configuration accessible for Administrators. 

Go to Settings > System Administration > SSO Configuration and click on the edit icon to adjust the respective Configuration. 

The configuration is clustered in three parts: 

Basic Configuration:

• Client Title: Name of the configured clients in SSO.
• Enable SSO: Checkbox, which enables the Authentication via SAML for the configured client.
• Enable email notification for new SSO users: Checkbox which sends an e-mail notification to the Application Owner when a new SSO users logs in.
• Force SAML Login: Enabling this option will automatically redirect the user to the SAML Page.
• SAML Session Timeout: Enabling this option will automatically redirect the user to the SAML Page.

SSO Configuration:

• Button Label: Label of the button to be shown on Login Page.
• IDP: SAML identity provider URL where we query for the identity.
• Entity ID: Domain name of the service provider.
• Metadata Entity ID: Link that represents Identity Provider.
• SSO Service Binding: Text Field accepting the protocols while signing on SAML.
• SLO Service Binding: Text Field accepting the protocols while signing out SAML.
• SLO Location: Single log-out location URI which validates the log-out.
• Signing Certification Data: Certificate which is used for encryption at the IDP side. Note: If there is only a single certificate, the certificate is used for both encryption and signing.
• Encryption certificate required?: Checkbox, which when applied uses different certificate for encryption and signing.
• Encryption certification data: Text field accepting the second encryption certificate data.
• Enabled Signed Request: Checkbox to enable second certification, which is used for signing.
• Sign Logout Request: Logout request is to be signed. This will only work when a single certificate is enabled. For double certificates, the logout request is automatically signed and can't be disabled.
• Encrypt SAML Assertion: Checkbox to set the flag if the assertion is enabled at the IDP side. It works only when a double certificate is enabled and used.

Attribute Mapping:

• Which attribute from simpleSAMLphp should be used as user's name?: Accepts a string value which is the key from the SAML response, whose value is used as the user's name. 
• Which attribute from simpleSAMLphp should be used as unique identifier for the user?: Accepts a string value which is the key from the SAML response, whose value is used as the user’s unique identifier.
• Which attribute from simpleSAMLphp should be used as user's mail address?: Accepts a string value which is the key from the SAML response whose value is used as the user's mail address. 
• Which attribute from simpleSAMLphp should be used as user's first name?: Accepts a string value which is the key from the SAML response, whose value is used as the user’s first name.
• Which attribute from simpleSAMLphp should be used as user's last name?: Accepts a string value which is the key from the SAML response, whose value is used as the user’s last name.
• Which roles should be provided to the SAML user?: Default role that will be assigned to the SAML user.