Nexonia
Nexonia offers both IdP-initiated SAML SSO (for SSO access through the Idaptive User Portal) and SP-initiated SAML SSO (for SSO access directly through the Nexonia web application). The following is an overview of the steps required to configure the Nexonia Web application for single sign-on (SSO) via SAML.
-
Prepare for Nexonia single sign-on (see Nexonia requirements for SSO).
-
In the Idaptive Admin Portal, add the application and configure application settings.
Once the application settings are configured, complete the user account mapping and assign the application to one or more roles. For details, see Configuring Nexonia in Admin Portal.
-
Configure the Nexonia application for single sign-on.
To configure Nexonia for SSO, access the Nexonia website and configure SSO settings. For details, see Configuring Nexonia on its web site.
After you are done configuring the application settings in the Admin Portal and the Nexonia application, users are ready to launch the application from the Idaptive User Portal.
Nexonia requirements for SSO
Before you configure the Nexonia web application for SSO, you need the following:
-
An active Nexonia account with administrator rights for your organization.
-
A signed certificate.
-
You can either download one from Admin Portal or use your organization’s trusted certificate.
Setting up the certificates for SSO
To establish a trusted connection between the web application and the Idaptive Identity Service, you need to have the same signing certificate in both the application and the application settings in Admin Portal.
If you use your own certificate, you upload the signing certificate and its private key in a .pfx or .p12 file to the application settings in Admin Portal. You also upload the public key certificate in a .cer or .pem file to the web application.
What you need to know about Nexonia
Each SAML application is different. The following table lists features and functionality specific to Nexonia.
Capability |
Supported? |
Support details |
Web browser client |
Yes |
|
Mobile client |
No |
Nexonia mobile applications do not support SSO. Users in a role with the SSO setting SSO logins only are prompted to configure a Mobile Password when launching the application on a mobile device. |
SAML 2.0 |
Yes |
|
SP-initiated SSO |
Yes |
|
IdP-initiated SSO |
Yes |
|
Force user login via SSO only |
See Support details. |
Users in a role with SSO set to SSO logins only are forced to log in to the application via SSO only. Users in a role with SSO set to Both regular logins and SSO logins, are not forced to log in to the application via SSO only. These users can also log in to the application using their user name and password credentials. |
Separate administrator login |
No |
|
User or Administrator account lockout risk |
Yes |
Since there is no backdoor URL, it is a good idea to create an administrator account to allow administrator access to the account using a password if needed. |
Automatic user provisioning |
No |
|
Multiple User types |
Yes |
The following SSO access can be set for Admin/User roles: Regular logins only SSO logins only Both regular logins and SSO logins |
Self-service password |
Yes |
|
Access restriction using a corporate IP range |
Yes |
You can specify an IP Range in the Admin Portal Policy page to restrict access to the application. |
Configuring Nexonia in Admin Portal
-
In Admin Portal, click Apps, then click Add Web Apps.
The Add Web Apps screen appears.
-
On the Search tab, enter the partial or full application name in the Search field and click the search icon.
-
Next to the application, click Add.
-
In the Add Web App screen, click Yes to confirm.
Admin Portal adds the application.
-
Click Close to exit the Application Catalog.
The application that you just added opens to the Application Settings page.
The description of how to choose and download a signing certificate in this document might differ slightly from your experience. See Choose a certificate file for the latest information. -
Configure the following:
Field
Required or optional
Set it to
What you do
Your Nexonia Org Code
Required
Your Nexonia organization code assigned by Nexonia.
Enter your Nexonia organization code here. This is the number given to you by Nexonia or the number in your Nexonia SAML login URL.
For example, if your SAML login URL is:
https://system.nexonia.com/assistant/saml.do?orgCode=1234
, enter1234
here.SAML IdP URL
Required
The Idaptive Identity Service automatically generates the content for this field.
Copy the URL and paste it directly into the SAML IdP URL field in
> Company > Features > Edit > Single Sign-On on the Nexonia website. See Step 3 in Configuring Nexonia on its web site.
Download Signing Certificate
Required
The Idaptive Identity Service automatically generates the content.
Click the link to download the default Signing Certificate.
Open it in a text editor and copy the content.
Paste the content directly into the SAML Certificate field in
> Company > Features > Edit Single Sign-On > on the Nexonia website.
Be sure to include the BEGIN CERTIFCATE and END CERTIFICATE lines of the certificate.
To use a certificate with a private key (pfx file) from your local storage, see below.
-
(Optional) On the Application Settings page, click Enable Derived Credentials for this app on enrolled devices (opens in built-in browser) to use derived credentials on enrolled mobile devices to authenticate with this application.
-
On the Application Settings page, expand the Additional Options section and specify the following settings:
Option
Description
Application ID
Configure this field if you are deploying a mobile application that uses the Idaptive mobile SDK, for example mobile applications that are deployed into a Samsung KNOX version 1 container. The Idaptive Identity Service uses the Application ID to provide single sign-on to mobile applications. Note the following:
The Application ID has to be the same as the text string that is specified as the target in the code of the mobile application written using the mobile SDK. If you change the name of the web application that corresponds to the mobile application, you need to enter the original application name in the Application ID field.
There can only be one SAML application deployed with the name used by the mobile application.
The Application ID is case-sensitive and can be any combination of letters, numbers, spaces, and special characters up to 256 characters.
Show in User app list
Select Show in User app list so that this web application displays in the user portal. (By default, this option is selected.)
If this web application is only needed in order to provide SAML for a corresponding mobile application, deselect this option. This web application won’t display for users in the user portal.
-
(Optional) On the Description page, you can change the name, description, and logo for the application. For some applications, the name cannot be modified.
The Category field specifies the default grouping for the application in the user portal. Users have the option to create a tag that overrides the default grouping in the user portal.
-
On the User Access page, select the role(s) that represent the users and groups that have access to the application.
When assigning an application to a role, select either Automatic Install or Optional Install:
-
Select Automatic Install for applications that you want to appear automatically for users.
-
If you select Optional Install, the application doesn’t automatically appear in the user portal and users have the option to add the application.
-
-
(Optional) On the Policy page, specify additional authentication controls for this application.
-
Click Add Rule.
The Authentication Rule window displays.
-
Click Add Filter on the Authentication Rule window.
-
Define the filter and condition using the drop-down boxes.
For example, you can create a rule that requires a specific authentication method when users access the Idaptive Identity Service from an IP address that is outside of your corporate IP range. Supported filters are:Filter
Description
IP Address
The authentication factor is the computer’s IP address when the user logs in. This option requires that you have configured the IP address range in Settings, Network, Corporate IP Range.
The authentication factor is the cookie that is embedded in the current browser by the Identity Service after the user has successfully logged in.
Day of Week
The authentication factor is the specific days of the week (Sunday through Saturday) when the user logs in.
Date
The authentication factor is a date before or after which the user logs in that triggers the specified authentication requirement.
Date Range
The authentication factor is a specific date range.
Time Range
The authentication factor is a specific time range in hours and minutes.
Device OS
The authentication factor is the device operating system.
Browser
The authentication factor is the browser used for opening the Idaptive Identity Services user portal.
Country
The authentication factor is the country based on the IP address of the user computer.
Risk Level
The authentication factor is the risk level of the user logging on to user portal. For example, a user attempting to log in to Idaptive Identity Services from an unfamiliar location can be prompted to enter a password and text message (SMS) confirmation code because the external firewall condition correlates with a medium risk level. This Risk Level filter, requires additional licenses. If you do not see this filter, contact Idaptive Identity Services support. The supported risk levels are:
Non Detected -- No abnormal activities are detected.
Low -- Some aspects of the requested identity activity are abnormal. Remediation action or simple warning notification can be raised depending on the policy setup.
Medium -- Many aspects of the requested identity activity are abnormal. Remediation action or simple warning notification can be raised depending on the policy setup.
High -- Strong indicators that the requested identity activity is anomaly and the user's identity has been compromised. Immediate remediation action, such as MFA, should be enforced.
Unknown -- Not enough user behavior activities (frequency of system use by the user and length of time user has been in the system) have been collected.
Managed Devices
The authentication factor is the designation of the device as “managed” or not. A device is considered “managed” if it is managed by Idaptive Identity Services, or if it has a trusted certificate authority (CA has been uploaded to tenant).
For the Day/Date/Time related conditions, you can choose between the user’s local time and Universal Time Coordinated (UTC) time.
-
Click the Add button associated with the filter and condition.
-
Select the profile you want applied if all filters/conditions are met in the Authentication Profile drop-down.
The authentication profile is where you define the authentication methods. If you have not created the necessary authentication profile, select the Add New Profile option. See Create authentication profiles.
-
Click OK.
-
-
(Optional) In the Default Profile (used if no conditions matched) drop-down, you can select a default profile to be applied if a user does not match any of the configured conditions.
If you have no authentication rules configured and you select Not Allowed in the Default Profile dropdown, users will not be able to log in to the service.
-
Click Save.
If you have more than one authentication rule, you can prioritize them on the Policy page. You can also include JavaScript code to identify specific circumstances when you want to block an application or you want to require additional authentication methods. For details, see Application access policies with JavaScript.
If you left the Apps section of Admin Portal to specify additional authentication control, you will need to return to the Apps section before continuing by clicking Apps at the top of the page in Admin Portal. -
On the Account Mapping page, configure how the login information is mapped to the application’s user accounts.
The options are as follows:
-
Use the following Directory Service field to supply the user name: Use this option if the user accounts are based on user attributes. For example, specify an Active Directory field such as mail or userPrincipalName or a similar field from the Idaptive Directory.
-
Everybody shares a single user name: Use this option if you want to share access to an account but not share the user name and password. For example, some people share an application developer account.
-
Use Account Mapping Script: You can customize the user account mapping here by supplying a custom JavaScript script. For example, you could use the following line as a script:
LoginUser.Username = LoginUser.Get('mail')+'.ad';
The above script instructs the Idaptive Identity Service to set the login user name to the user’s mail attribute value in Active Directory and add ‘.ad’ to the end. So, if the user’s mail attribute value is Adele.Darwin@acme.com then the Idaptive Identity Service uses Adele.Darwin@acme.com.ad. For more information about writing a script to map user accounts, see the SAML application scripting.
-
-
(Optional) On the Advanced page, you can edit the script that generates the SAML assertion, if needed. In most cases, you don’t need to edit this script. For more information, see the SAML application scripting.
-
(Optional) On the Changelog page, you can see recent changes that have been made to the application settings, by date, user, and the type of change that was made.
-
(Optional) Click Workflow to set up a request and approval work flow for this application.
See Manage application access requests for more information.
-
Click Save.
See Idaptive Identity Services issued derived credentials for more information.
Configuring Nexonia on its web site
-
In your web browser, go to your Nexonia login URL and sign in with your administrator account credentials.
-
Click
> Company > Features > Edit to access Single Sign-On configuration settings.
-
Configure the following settings:
Field
What you do
Use Single Sign-On (SSO)
Select Yes.
SSO Administrator Emails
(Optional) Enter SSO Administrator email addresses delimited by a comma, to receive an email notification in case of an SSO failure.
SSO Protocol
Select SAML 2.0.
SAML IdP URL
Paste the URL you copied from the Admin Portal > Application Settings > SAML IdP URL field here.
SAML Flavor
Select Standard.
SAML Certificate
If you haven’t done so already, download the Signing Certificate from the Application Settings page in IdaptiveAdmin Portal and paste it here. Be sure to include the BEGIN CERTIFCATE and END CERTIFICATE lines of the certificate.
If you use your own certificate be sure to upload it in the Application Settings page in IdaptiveAdmin Portal. For more information, see Step 6 in Configuring Nexonia in Admin Portal.
-
Click Apply to save the configuration and enable single sign-on.
Nexonia provisioning
SCIM (System for Cross-domain Identity Management) is an open standard for automating the exchange of user identity information between identity domains, or IT systems. It can be used to automatically provision and deprovision accounts for users in external systems such as your custom SAML app. For more information about SCIM, see www.simplecloud.info.
If your Nexonia application supports SCIM, you can set it up to enable provisioning by entering the Access Token and SCIM URL.
For more information about provisioning your app, see Provision accounts with SCIM.
For more information about Nexonia
For more information about configuring Nexonia for SSO, contact Nexonia Customer Support.