How does Socrata implement SSO from a technical standpoint?
Socrata implements SSO following industry standards and best practices for SSO implementations. Socrata’s SSO implementation is utilized and trusted by local, state, and federal entities as their robust SSO solution for daily SSO authentication into their cloud hosted open data solution.
Socrata leverages Auth0, a third-party single-sign-on provider, as one part of its SSO authentication process. This affords many benefits including:
- The ability to configure authentication workflows using dozens of different identity providers, without Socrata needing to implement custom integrations for each provider.
- The protection of Auth0’s robust, secure platform, which is trusted by Fortune 500 companies and government agencies to serve over a billion secure sign-ons per year.
- The ability to set up custom workflows that include extensions like multi-factor authentication.
When using single-sign-on with Socrata, Auth0 acts as a secure authentication proxy when users log on. However, the secure architecture of SAML and Auth0 makes sure the authentication process is actually more secure than signing into Socrata directly. Specifically:
- User access credentials (passwords) are never entered into any system other than your Identity Provider. Neither Socrata nor Auth0 come into contact with access credentials, so there is no chance they could be stored, logged, or leaked.
- Auth0 never stores details of a user’s authentication with your Identity Provider, and acts merely as a proxy between your Identity Provider and Socrata, authenticating users and providing identifying details (email and a unique ID) to Socrata.
Socrata’s SSO implementation has been designed with the security of our most critical customers in mind, and with SSO in scope, Socrata is one of the few SaaS companies of its size to be granted a FedRAMP Medium authorization.
How long does it take to set up SSO with Socrata?
From the time we receive the initial connection information, SSO can be enabled in as short as a week for straightforward connections. For more complex configurations, we expect additional communications and a longer implementation period.
How will this impact existing user accounts?
Existing user assets will not be impacted by the introduction of SSO. Users who have existing Socrata accounts will go through the new SSO login workflow once it has been enabled, but they will retain ownership and access rights for any datasets or other assets already associated with their user account. However, the display name on their account will be overridden by the display name provided to Socrata by their identity provider.
How will this impact new users?
Users who do not have an existing Socrata account can log in to the Socrata domain if they have an account with the Identity Provider. The user will be authenticated with the SSO flow and will receive a default role as specified by the site administrator. For most SSO configurations, the default role for new users is Viewer. For more information on user roles, please see this article.
Is SSO compatible with all Socrata products?
SSO is compatible with the following Socrata products: Open Data, Open Performance and Perspectives. It is not yet available for Public Finance, Citizen Connect, or Public Safety products. Stay tuned to our Product News for updates.
How do I authenticate using external tools such as the API with SSO enabled?
Users may wish to use tools such as the SODA API or OData to read data, as well as 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 you want a password, click on the Forgot Password? link to receive a reset link via email.
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.
What happens if a user leaves my organization and I delete their account from my Identity Provider?
Since SSO is used for authentication and not account management, the user’s associated Socrata account and any assets owned by that account would still exist. Since the user no longer has an account with the Identity Provider, s/he would not be able to log in and access the assets, though. An administrator on the domain could transfer ownership of these assets. It is also considered best practice to remove the user’s role on the Socrata domain. If you have additional questions regarding this issue, please reach out to email@example.com with specifics.