Single Sign On (SSO) Set Up

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.

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.

SSO with Active Directory FS
1. Install ADFS 2.0 (help can be found at http://www.microsoft.com/en-us/download/details.aspx?id=10909).

2. Download metadata.xml.

3. In the ADFS 2.0 Management console, add an SSL certificate to sign Dotcom-Monitor responses/requests:
- Launch the ADFS 2.0 Management console and open Server Configuration Wizard.
- Click Create new FS and select Standalone FS.
- Select SSL certificate (if there are no certificates, you can create a self-signed cert using INETMGR > Server certificates > Create self-signed cert).
4. In the ADFS 2.0 Management console, add IDR to the ADFS Relying Party Trusts:
- Click Relying Party Trusts and select Add Relying Party Trust.
- In the wizard window, click Start and select Import data about the relying party from a file.
- Choose metadata.xml.
- Choose any meaningful name (dotcom-monitor.com).
- Click Next and follow the prompts.
- On the Issuance Authorization Rules step, select Permit all users to access this relying party
- On the final step click to deselect the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes checkbox.
- Close the wizard.
5. Set SHA-1 as a secure hash algorithm:
- After creating relying party trust right-click it in the list and select Properties.
- Go to the Advanced tab and change the hashing algorithm to SHA-1.
6. Add claim rule to send LDAP attributes as claims:
- Right-click the relying party, select Edit Claim Rules.
- Click Add Rule and make sure the Claim rule template has Send LDAP Attributes as Claims selected.
- Give the Claim rule name.
- Select the Attribute store to be Active Directory.
- Add two attribute mappings: for User-Principal-Name set UPN, for Token-Groups – Unqualified Names set Role.
7. Add custom rule:
- Right-click the relying party, select Edit Claim Rules.
- Click Add Rule and set the Claim rule template to Send claims using custom rule.
- Give the Claim rule name.
- Insert the following script:
```
 c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer,
 OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, 
 Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient",
 Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://www.example.com/adfs/services/trust", 
 Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "https://userauth.dotcom-monitor.com/")
```
- Replace “http://www.example.com/adfs/services/trust” with the proper Identity Provider (IdP) entityID (“http://idpsite.com/adfs/services/trust“).
8. Open the URL in the browser from the IdP machine: https://localhost/federationmetadata/2007-06/federationmetadata.xml

9. Save the XML content as a file and send it to Dotcom-Monitor support using the ticket system.

When SSO is enabled you can add Dotcom-Monitor website users by creating new users in AD or adding existing users to one of the following groups: “Dotcom-Monitor_Administrators“, “Dotcom-Monitor_Users“, “Dotcom-Monitor_Power_Users“, “Dotcom-Monitor_Accounting_Users“, “Dotcom-Monitor_ReadOnly_Users“, “Dotcom-Monitor_Operators“. Each of these groups must have the “global” or “universal” scope and the “security” type.
SSO with AZURE
1. Log in to the Azure portal as a Global Administrator or Co-admin.

2. In the portal, open Enterprise Applications and add Dotcom-Monitor application.
- Under the Manage section, select Single sign-on.
- Select SAML to configure single sign-on. On the Set up Single Sign-On with SAML page, in the Basic SAML section, add the Sign-on URL which you received from Dotcom-Monitor support.
- In the Reply URL (Assertion Consumer Service URL) field provide:
```
 https://userauth.dotcom-monitor.com/login.ashx
```
- In the User Attributes and Claims section, check that the following claims are present:
```
 Unique User Identifier (Name ID): SAML user.userprincipalname [nameid-format:emailAddress]
 Roles: SAML user.assignedroles
```
- In the SAML Signing Certificate section, setup a SAML certificate.
- Download Metadata XML and save it to the disk. This file must be sent to dotcom-monitor.com support via ticket.
4. Every SSO login user is required to have an assigned Dotcom-Monitor role. You can follow the steps below to assign roles:
- Navigate to App registration.
- Select the Dotcom-Monitor application and configure App roles.
- Click Create App role and create roles using the following names: “Dotcom-Monitor_Administrators“, “Dotcom-Monitor_Users“, “Dotcom-Monitor_Power_Users“, “Dotcom-Monitor_Accounting_Users“, “Dotcom-Monitor_ReadOnly_Users“, “Dotcom-Monitor_Operators“.
5. Navigate to Enterprise Applications, select Dotcom-Monitor and add users with corresponding Dotcom-Monitor roles.
SSO with OKTA

Check the following materials to configure OKTA integration with Dotcom-Monitor and enable SSO:

OKTA – Dotcom-Monitor Integration PDF Guide

OKTA SAML Integration with Dotcom-Monitor Walkthrough Video

SAML Login Video

See also the following alternative guides:

Okta to Dotcom-Monitor Alternative Guide

Okta to Dotcom-Monitor SAML Configuration Video

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. Use a double hyphen as a separator:

<AD Group Name>--<Department Name>

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

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).

SSO with Active Directory FS

SSO with AZURE

SSO with OKTA

Configuring SSO for Departments