Dashlane's single sign-on (SSO) feature allows your users to sign in to their Dashlane vault using their SSO credentials instead of a Master Password. Below are instructions to set it up using ADFS.
Please note that this feature is exclusive for the Dashlane Business customers.
Contents
Step by Step video walk through
Overview of single sign-on (SSO)
Today, the Master Password is used as one of the keys to encrypt/decrypt user data. Now, with SSO, your users can sign in to their Dashlane vault using their SSO credentials instead of a Master Password. Together with Dashlane's SSO Connector, users can sign in with their SSO credentials, all while Dashlane retains its zero-knowledge security architecture.
When a user attempts to sign in using SSO, they are redirected to the SSO Connector, which federates to the identity provider.
After the user successfully signs in, the SSO Connector sends a unique key to the client which then decrypts the user's data.
All user keys are managed by the SSO Connector. In order to maintain our patented zero-knowledge security architecture, the SSO Connector needs to be hosted in an environment controlled by your organization. The SSO Connector runs on Docker and can be hosted in any environment where Docker is present.
System requirements
Dashlane specific requirements
- Dashlane Business (Dashlane Team does not support SSO)
- Minimum version of the Dashlane app:
- Web: v6.2030.3
- iOS: v6.2029.0
- Android: v6.2030.1
- Desktop apps are not supported
Enabling SSO
Verify your domain
You will need to verify the domain that your organization owns. Once you enable SSO, all users that are using your organization's domain will be required to use SSO to sign in.
1. Visit the Dashlane Admin Console and navigate to the Settings tab.
2. Click the SAML SSO tab. In the Verify your company email domain field, enter your company's domain name and click the Verify button.
- If you have multiple e-mail domains configured for your SSO provider, add and verify all additional domains.
3. Copy the Hostname and TXT values and add them to a new DNS TXT record for your domain. Once added, click on the Verify domain button. Please note that it can take up to 24 hours to verify the domain.
4. Verify all the email domains your users will use to sign in using SSO. If you have more than 5, contact support.
SSO Connector configuration steps
1. Navigate back to the SAML SSO section of the Settings tab in the Admin Console.
2. Copy-paste the SAML metadata of ADFS in the Enter the identity provider metadata here field. If you need help finding the metadata, you can go to your ADFS metadata URL where 'ADFSName.Domain.com' is the URL of your ADFS server or farm.
https://ADFSName.Domain.com/FederationMetadata/2007-06/FederationMetadata.xml
You can also use Microsoft's tool to download your Federation Metadata Document.
7.Choose a single-sign on URL endpoint that you would like to use for your SSO connector.
There are three ways to deploy the SSO encryption connector, and how you choose to deploy will change your ACS & Entity ID URL's.
| SSO encryption service host | SSO Connector endpoint |
| Azure (recommended) | https://mycompanysso.azurewebsites.net |
| AWS | https://mycompanysso.mycompany.com |
| Linux VM (advanced) | https://mycompanysso.mycompany.com |
Enter the SSO connector endpoint in the Dashlane admin portal
4. Click on the Generate SSO Connector key button. This will generate a key that will be used to encrypt all the your company's data. Copy the generated key and save it somewhere secure (such as a secure note in Dashlane). We also recommend sharing it with any other admins as well. You will not be able to see this key again.
5. Click on the Download Config file button.
Complete the SSO Connector setup
The SSO Connector encryption service must be completed before moving forward. More information about the SSO encryption service can be found here.
ADFS configuration steps
1. In order to configure ADFS, you will need the SAML metadata from the SSO Connector service. To do so, navigate to https://<SSO Connector Endpoint>/saml/ from the ADFS server or a device that can reach the SSO Connector. This will download a local copy of the SAML metadata.
2. Transfer the SAML metadata file to the ADFS server.
3. Open the ADFS Management console, and click on Add Relying Party Trust...
4. In the menu, select Claims aware and then click on Start.
5. Select Import data about the relying part from a file, and click on the Browse... button to select your SSO Connector's metadata XML file that you saved from Step 2 above. Once selected, click on Next.
6. Enter "Dashlane SSO Connector" as the display name and then click Next.
7. Select your access control policy and click Next. This will vary based on each companies security policies. For this example, we're going to permit everyone.
8. Review the relying party trust that was configured. Once finished, click on Next and then Close. The new trust will be created.
9. Next, we need to allow the Dashlane SSO Connector to be able to retrieve the user's email address from ADFS. Select the newly created Relying Party Trust (if you don't see it, click on Relying Party Trusts in the left side-bar). Then click on Edit Claim Issuance Policy...
10. Click on the Add Rule... button in the bottom left corner of the window.
11. In the "Claim rule template" dropdown, select Transform an incoming claim and click Next.
12. Set the Claim rule name field to "Send Email as Name ID". Set the Incoming claim type to "UPN". Set the Outgoing claim type to "Name ID". Set the Outgoing name ID format to "Email". When done click on the Finish button.
Testing and enabling SSO
1. You can do a quick test to ensure that SSO Connector and ADFS are configured correctly. To do so, navigate back to the Dashlane admin console and click on Test Connection.
You can sign in using any user account registered in ADFS to test the account. Once you successfully sign in, you should see a Success message. If you don't, contact Dashlane Support for help.
2. You can now enable SSO for all your users! Remember, admins within Dashlane will not be impacted, and will continue to sign in using their Master Password. All other users will be forced to use SSO.