By setting up Single Sign-On (SSO), your team members will be able to sign in to their DMARCwise accounts using the account and credentials they already have on the Identity Provider of your company (e.g. Microsoft Entra ID, Okta, etc.).

You can use any Identity Provider that supports the SAML 2.0 protocol.

SSO in DMARCwise was tested with:

If you use another Identity Provider, consult the SAML requirements section below or reach out and we’ll prepare a specific setup guide.

Availability

  • SSO is included at no additional cost with the following subscription plans: Growth, Scale, MSP.

Permissions

  • Only users with a role of Admin can manage SSO settings.

Enabling SSO

To enable SSO for your organization:

  • Navigate to the SSO settings page.
  • Click Configure
  • Use the provided information (Entity ID and Assertion Consumer Service (ACS) URL) to configure a new SAML app in your Identity Provider and click Next.
  • If your Identity Provider supports configuration through a metadata URL, enter the URL of the metadata file and confirm with Enable SSO.
  • Otherwise, switch to the Manual tab and enter the Identity Provider Entity ID, SSO/Login URL and Certificate (PEM format). If you’re unsure how to proceed, please contact support.

Signing in with SSO

To sign in with SSO, your users will need to use a dedicated SSO login page:

  • If your team members already have an account on DMARCwise, they can click the Login with SSO button on the login page and enter their email address to get to the correct login page.

  • If your team members don’t have an account on DMARCwise yet, open the Members page in the settings and you’ll find a form to invite them by email.

    • After the first login, they’ll be able to sign in as in the previous point.
    • You can also provide them with the SSO login URL manually: the invitation form is just a shortcut to save you time.

Enforcing SSO

After enabling SSO, existing users in your DMARCwise organization will still be able to sign in with their password credentials, including you.

Make sure you log out and test the SSO login so that your administrator account is linked with an SSO user.

Check the Members page to see the SSO status of the users of the organization.

Once you activated SSO for your user, you can enforce SSO for all members by enabling the Require SSO for all members option. Users won’t then be able to sign in with a password anymore. Disable the option and users will be immediately able to sign in with their password again.

When enabling the option to require SSO for all members, all existing sessions, invitations and pending password resets will be invalidated.

Default role

When new users join your organization through SSO, they’ll be given a default role.

By default, the role is set to Member. Use the Default role for new members setting to change this behavior.

The default role is used only when creating a new account: if you then change the role of the user in the Members page it won’t be overridden.

Roles

If your Identity Provider allows it, you can set application roles in the Identity Provider and DMARCwise will automatically assign and synchronize the role when the user logs in to DMARCwise with SSO.

If you use Microsoft Entra ID, read the dedicated guide (scroll to the roles section).

For other Identity Providers, make sure the role value is passed in a custom SAML response attribute called urn:dmarcwise:role. If you pass multiple roles, the one with the highest level of permissions will be picked.

The allowed values for this attribute are the following (ordered from highest to lowest level of permissions):

  • Admin
  • Member
  • Billing
  • Viewer

Access control

After enabling SSO, all users authorized by your Identity Provider will be able to sign in and automatically join your organization, without the need of sending them invitations.

To limit who can use the DMARCwise application, prefer using the access control settings of your Identity Provider.

If your Identity Provider does not have this access control capability, you can choose to enforce the presence of a role in SAML responses. If the role is not present, the user won’t be able to log in to DMARCwise.

To enforce the presence of the role attribute enable the setting named Require valid role attribute in the DMARCwise SSO settings page.

User deactivation

If you disable access to the DMARCwise application in your Identity Provider, the user won’t be able to sign in with SSO to DMARCwise anymore.

Note that existing user sessions in DMARCwise won’t be logged out, so the user may still be able to access the data for a few days. SSO sessions in DMARCwise expire after 3 days.

To revoke access to the user immediately, go to the Members page and click the Remove button next to a specific team member.

Single Logout

Single Logout (SLO) is not supported. Please reach out if you require this feature.

IdP-initiated SSO

Currently, login flows initiated by the Identity Provider (also known as unsolicited SAML responses) are not supported for security reasons.

SAML requirements

SSO in DMARCwise should work with any SAML 2.0 Identity Provider, but some additional configuration may be needed for best results.

Specifically, the following claims are required and must be passed by the Identity Provider to DMARCwise:

  • Email address
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

We also recommend setting up:

  • Given name
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
  • Surname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

NameId recommendations and alternatives

If possible, you should also make sure that the NameID claims contains a persistent identifier such as a user ID or employee ID, and not an email address. This is because the email address may change with time and a NameID change would make it impossible to match the user in DMARCwise upon login.

If you’re unable to change the configuration of the NameID claim, you can also create a custom claim with type urn:dmarcwise:userId: if the NameID format is not declared as persistent and the urn:dmarcwise:userId is present, the urn:dmarcwise:userId will be used in place of the NameID.

If you’re unable to configure SAML with a persistent ID, keep in mind that if you change the primary email address of a user in your Identity Provider you should contact us to apply the change in our systems too.