SSO/SAML
SSO/SAML requires the Enterprise plan. If you’re on the Scaleup plan you might want to consider GitHub SSO instead.
SSO/SAML (Single-Sign On with Security Assertion Markup Language) allows you to use your existing identity provider like Google Workspace or OKTA to authenticate your team members in emulator.wtf. In the context of the general SAML flow emulator.wtf acts as a Service Provider (SP) and the Identity Provider (IdP) is your SSO/SAML provider.
Our current SSO/SAML implementation supports the following features:
- SP-initiated single sign-on
- Just-in-time user provisioning with minimum permissions role (triage)
- Username/password based accounts are still allowed, we recommend to have at least one owner account configured this way to restore access if something happens with your IdP configuration
We don’t support the following:
- IdP-initiated single sign-on
- SP-initiated logout (SLO)
- SAML attribute-based role mapping (coming soon)
- Custom session expiry (coming soon, SSO/SAML sessions currently expire in 24h)
Prerequisites
To configure SAML/SSO your organization must be on the Enterprise plan and you should have a validated work email domain configured - contact support to get that sorted. To kick off configuration you need to be logged in to emulator.wtf with owner-level access. You’ll also need administrator level access to your IdP provider. In many companies this is handled by some sort of internal IT team.
Configuring SSO/SAML
Follow one of the following guides to set up SSO/SAML depending on your corporate identity provider (IdP):
Other identity providers should work as well, but we haven’t tested them yet. If you have any issues or questions, let us know at support@emulator.wtf.
Signing in with SSO/SAML
In emulator.wtf signin page click the Sign In with SSO button,
fill in your work email address and click Sign In. If the user does not exist yet in emulator.wtf
then it will be provisioned with the triage
role (can see test results, cannot configure or modify
anything).