If You're Reading This, You Probably Know About SSO
SSO has become the de facto standard for large organizations managing vendor access for their employees. It's a single set of credentials that your employees can use to log into several different applications, and you can absolutely set this up with Ethnio, but only on our Enterprise plans.
Does Ethnio Support SSO? Yep.
Ethnio supports SSO via SAML 2.0 and acts as a service provider (SP) for SSO. You must have a federation service that acts as an identity provider (IdP), but you almost definitely have that if you're interested in this whole setup. Ethnio supports all the most common IdPs:
- ADFS 2.0/3.0
- Google SAML 2.0
There may be additional functionality as part of an SSO integration, like account provisioning upon addition to the IdP (pre-provisioning), automatic account de-provisioning upon removal from the IdP. Please reach out to us to see about different levels of functionality.
How Does SSO Work With Ethnio?
- User goes to ethn.io/login and clicks "Single Sign On", or in some cases the user goes to your custom subdomain like mycompany.ethn.io
- Either way, Ethnio forwards the request to the IdP. The user will be redirected to the IdP login page.
- User logs in using your company credentials
- User is validated against your user directory
- SAML assertion is sent back to Ethnio. At a minimum, the SAML assertion response from the identity provider must contain the user’s email address. The email address must correspond to a team license within that Ethnio account. First and last name attributes are typically sent as parameters as well, but they are not required to enable SSO.
- The user’s session is authenticated and logged into their Ethnio account
Getting Started with Ethnio SSO
- Get the Ethnio Metadata.xml file
- Make sure your IdP supports SAML 2.0 and SP initiated SSO
- Send us your Metadata.xml file
Auto-Provisioning Seat Licenses via SSO
The first time a user from your organization logs in to Ethnio via SSO, the IdP is communicating to Ethnio that this user should be allowed to have an account. If a user should not have an account, the SAML assertion should not be sent to Ethnio by imposing restrictions through the IdP. The basic idea here is you're responsible for deciding who should have access to Ethnio at your organization.
Optional (Automatic Notifications by Domain)
If anyone using their work email at your organization tries to create a free Ethnio account, we'll alert them that you have a company-wide SSO license and ask them to continue logging in with their company credentials. Then the same account provisioning rules from above will apply.