Single sign-on
Sign your team in through Okta, Microsoft Entra ID, Google Workspace or any SAML 2.0 or OpenID Connect provider, and let people on your domain join on their own.
Updated
On this page
What this is
Single sign-on lets the people on your team sign in to Dardaris through the identity provider your organisation already uses, such as Okta, Microsoft Entra ID, Google Workspace, OneLogin or JumpCloud. It comes with every plan, and only an owner of the team can set it up, under Settings, then Single sign-on.
Everything here sits under Settings, alongside the rest described in the settings page, and it decides who can open the team your company details belong to.
Two things work together: the provider, which says who someone is, and your domains, which say whose addresses the provider may speak for. A provider can only ever sign in an address on a domain your team has verified.
Verifying a domain
Add the domain your team's addresses end in, such as example.com. Dardaris gives you a TXT record to publish at your DNS host:
- Name:
_dardaris-verification.example.com - Value:
dardaris-verify=followed by a code that is yours alone
Publish it, then press Check DNS record. A record can take a few minutes to be seen everywhere, so a first check that finds nothing is worth trying again shortly. A domain another team has already verified cannot be claimed.
Each domain then does one of two things:
- Auto-join. Anyone who signs in with an address there is put on your team as a member, whether they use a password, a passkey or the provider. Nobody already on the team is changed.
- Restricted. The same, and while single sign-on is on, people with an address there can only sign in through your provider. A password or a passkey is refused, which is what makes switching someone off at the provider switch them off here too.
Removing a domain stops it doing either, and takes nobody off the team.
Connecting a SAML provider
Add Dardaris to your provider as a SAML application, and give it the two addresses shown in Settings: the entity ID, which is also the metadata URL, and the assertion consumer service URL. Ask the provider to send the address as the NameID, or as an email attribute.
Then paste the provider's metadata URL into Dardaris and save: the sign-in URL, its entity ID and its signing certificate are read from it. You can also fill the three in by hand. A response that is not signed with that certificate is refused, and so is one meant for another application, one that has expired, and one Dardaris did not ask for. Sign-ins have to start from Dardaris, so a tile in your provider's own dashboard will not sign anyone in. Encrypted assertions are not supported, so leave assertion encryption off.
Connecting an OpenID Connect provider
Register Dardaris with your provider as a web application, with the redirect URI shown in Settings. Then paste the issuer, the client ID and the client secret it gives you. The issuer is the address its discovery document sits under, without /.well-known/openid-configuration.
The client secret is stored sealed and never shown again. Leave the field empty when you save to keep the one on file.
Switching it on
Test connection checks what can be checked without signing anyone in. Then switch on Sign people in through this provider. It needs a complete configuration and at least one verified domain.
From then on, people sign in from the usual page by typing their address and choosing Continue with single sign-on. Someone signing in this way for the first time gets an account on the spot, and is put on your team. Someone who already had an account with that address keeps it: the provider is linked to it rather than a second one being made.
When something goes wrong
The sign-in page says why a sign-in through the provider stopped. The usual causes are a certificate that was rotated at the provider and not here, a clock that has drifted, an address on a domain you have not verified, or a sign-in started from the provider's dashboard rather than from Dardaris.
If the provider itself is unavailable, an owner can switch single sign-on off in Settings, and people on a restricted domain can then sign in with a password again. If every owner is on a restricted domain and none of you can get in, write to support, who can switch it off for you.