In MyValidity, you have the option to turn on single sign-on (SSO) for your organization. This will allow your users to log directly into Validity applications, such as DemandTools, from a service like Okta or Microsoft MyApps.
To turn on SSO, you’ll need to configure a Security Assertion Markup Language (SAML) integration. For this process, you’ll need to engage your IT department or the technical resource who handles your SSO service.
The basics of SAML SSO
SAML is a protocol that shares security credentials across a network, such as your company’s internal network. SAML is primarily used for SSO, which allows users to sign in without having to remember a username and password for each app they access. Instead, these functions are sent to a service—in the case of MyValidity, that service is Auth0—that authenticates identity and confirms authorization.
There are multiple protocols that can be used for SSO, including SAML and OAuth. But SAML is commonly used by enterprise companies to manage users’ access to apps because SAML handles both authentication (you are who you say you are) and authorization (you are allowed access to this app). Other protocols may handle only one or the other.
How it works
If you’re a user, you may access the apps at your company through a service like MyApps or Okta. You’ll know this service as a series of icons for apps like Jira, Slack, Zoom, etc. When you select an app, you are logged in automatically.
What’s taking place behind the scenes? Let’s take Okta and DemandTools V as an example.
When you select the MyValidity icon, Okta sends your identity to MyValidity. Okta is functioning as an identity provider, or IdP.
MyValidity uses the Auth0 service to confirm the identity Okta sent (authentication) and confirm you have access to MyValidity (authorization).
The Auth0 service is functioning as the service provider, or SP, because it gives you access to the MyValidity service.
How does your IdP establish your identity with the SP? That’s where SAML comes in. The IdP sends a security token to the SP. For MyValidity, this token comes in the form of a SAML assertion document—it’s asserting your identity, using your email address in MyValidity as the identity marker in the assertion document.
Because MyValidity uses SAML, and SAML works with a wide variety of configurations, your IdP must be set up to pass this assertion document in the proper configuration for the IdP you use.
Note: MyValidity does not support IdP-initiated login.
We recommend creating one Admin user in MyValidity with an email address not on the same domain you are enabling SSO for. For example, if you are setting up SSO for acme.com, one Admin user should be created with an email address on a different domain, like gmail.com or outlook.com. Please test that you can log into Validity applications with this user before proceeding with SSO setup.
Set up your SAML integration
Select your IdP from the list below to find your setup process, then give this link to your IT resource for implementation:
If your IdP is not listed, please use the generic setup document and work with your IdP if you have questions: