Dotcom-Monitor supports SSO (Single Sign On) login using SAML 2.0. SAML provides the transfer of authentication data between the clients’ Identity Provider and Dotcom-Monitor service. All user login information is stored on the Identity Provider side and not by Dotcom-Monitor which guarantees a high level of security and a better user experience.
Once you have set up the permission groups in your system, Dotcom-Monitor maps these groups to our user roles and grants access to the Dotcom-Monitor system accordingly. To set up SSO with Dotcom-Monitor, please use the following names to configure SSO roles in your directory service:
| AD Group Name (SSO Role) | User Role in Dotcom-Monitor |
| Dotcom-Monitor_Administrators | Admin |
| Dotcom-Monitor_Users | User |
| Dotcom-Monitor_Accounting_Users | Accounting |
| Dotcom-Monitor_ReadOnly_Users | Viewer |
| Dotcom-Monitor_Power_Users | Power User |
| Dotcom-Monitor_Operators | Operator |
Dotcom-Monitor local users and SSO users are managed separately. Once you have an SSO login set up, you can use both login methods simultaneously or delete local user accounts (excluding the account administrator), as needed.
SSO manages access rights within your system based on the user roles sent to Dotcom-Monitor. You will not see SSO users in the Dotcom-Monitor account’s user list. While SSO user names will appear in the account audit, roles will not be displayed there. Essentially, SSO user management is entirely local within your Active Directory, and Dotcom-Monitor system does not have access to that data.
SSO Login Setup
Further in this article, we provide the steps required to enable SSO with Active Directory FS (ADFS) and AZURE Active Directory (Azure AD) as the Identity Providers. Also, step-by-step guides for OKTA SAML integration are provided.
Generally, it is not advisable to set up a Dotcom-Monitor user in multiple groups with varying permission levels within your Active Directory. However, if a user belongs to two or more permission levels in Dotcom-Monitor, the lowest permission level will take precedence over the levels with higher permissions. For example, if a user has been simultaneously assigned the Viewer (Read-only) and Power User roles within the Dotcom-Monitor platform, it is the Viewer role permissions that will be applied during SSO login.
Before you start, please download a Dotcom-Monitor metadata file from here: https://userauth.dotcom-monitor.com/metadata.ashx.
-
SSO with Active Directory FS
-
SSO with AZURE
-
SSO with OKTA
Configuring SSO for Departments
If you have a Department created for the Dotcom-Monitor account, you can configure SSO users to log in to it.
To enable SSO for Departments, add the department name as a suffix to the name of the group or role reserved for Dotcom-Monitor purposes in AD. Find the Group Name convention of Dotcom-Monitor here. Use a double hyphen as a separator:
<AD Group Name>--<Department Name>
For example, to allow a user to log in to the “AlphaDep” department with permissions of the Power User role, add the following suffix to the Dotcom-Monitor_Power_Users AD Group:
«Dotcom-Monitor_Power_Users--AlphaDep»
To change an ADFS Group name, right-click the group and select Rename. Once renamed, change the pre-Windows 2000 name as well in the pop-up box or from Properties > General > Group Name (pre Windows 2000).
You can also add several departments’ names one by one using the same format. For example:
«Dotcom-Monitor_Accounting_Users--AlphaDep--BetaDep--Department3»
To allow users to log in to the root account, specify a relevant AD Group without a department suffix as was described above:
«Dotcom-Monitor_ReadOnly_Users»
If a user is included in several «Dotcom-Monitor_» AD Groups with configured SSO for Departments, logging in to all corresponding Departments will be enabled (if the Departments exist in the Dotcom-Monitor account).
See also: Signing in with SSO