We Are Here To Help


Using single sign-on (SSO) with Socrata



Socrata supports single sign-on with ADFS and custom SAML 2.0 integrations.

What is Single Sign-On?

Single Sign-On (SSO) allows you to use your own organization's enterprise user account system in place of the default Socrata login page. When a user within your organization signs into your Socrata instance, you have the option of allowing or requiring that user to login with their intranet/organization credentials. This can be used instead of creating Socrata user accounts from the Admin Users page, though it does not yet replace the process for assigning user roles and permissions on the Socrata platform.

If you are interested in enabling single sign-on for your domain, please first contact your Customer Success Manager and/or Account Manager, or Project Manager, if you are currently in an active project. After that, the next steps will be to follow the steps under ‘Setting up single sign-on’ (to set up a trust relationship with Socrata) and email support (with the Subject line: Single sign-on setup) to initiate setup.

Why is this valuable?

SSO gives admins significantly more flexibility when managing their program and the users that have access to it. For example, when an employee leaves the organization, they no longer need to worry about remembering to cancel their Socrata account to prevent them from accessing not-yet-public data, they no longer need to worry that Socrata passwords aren’t compatible with their enterprise password policies, they’re able to take advantage of extra security measures like two-factor authentication, etc.

SSO enables an admin to manage their program across a large and complex enterprise organization.

Is SSO compatible with all Socrata products?

SSO is currently available for customers in the United States and Canada. SSO is compatible with the following Socrata products: Open Data, Open Performance and Perspectives. It is not yet available for Public Finance or Public Safety products. Stay tuned to our Product News for updates. 

Setting up single sign-on

Before we can set things up on the Socrata side for Single Sign-On, you will need to set up a trust relationship with Socrata. (Active Directory provides security across multiple domains through interdomain trust relationships). To do this, follow one of these two sets of instructions depending on your identity provider and file a support ticket with the requested information to complete the setup.


Please provide this information for Support or your Project Manager:

  • The domain(s) of any Socrata-powered site(s) that should have SSO enabled.
  • Email domain(s) that will be using SSO to sign into your site.
  • ADFS URL or Federation metadata file.


Please provide this information for Support or your Project Manager:

  • The domain(s) of any Socrata-powered site(s) that should have SSO enabled.
  • E-mail domain(s) that will be using SSO to sign into your site.
  • Sign-in URL.
  • X509 Signing Certificate in PEM or CER format.
  • Sign-out URL (Optional).
  • User ID Attribute (Optional). 

Authenticating tools with SSO enabled

Users may wish to use tools such as the API or OData to read data, as well as the API, FME, and DataSync to publish data. They will need to ensure that they can authenticate properly with these tools with SSO enabled.

When a customer turns on SSO,

  • Existing user accounts in the system that were created before SSO was turned on can continue to authenticate via basic authentication using command line tools.
  • New users created in the system after SSO is turned on cannot authenticate via basic authentication because they do not have a password. If they want a password, they can go to their profile page and click Create Password.

Frequently Asked Questions

Does my Socrata application password need to be the same as my SSO password?

No. These passwords can be different.

Can I use a different email address for Socrata user account than my SSO email address?

No. Your SSO email address is tied to a specific site role and dataset permissions and a different email address would imply a different user account.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Powered by Zendesk