Single Sign-On FAQs

Data & Insights implements SSO following industry standards and best practices for SSO implementations. SSO implementation on the Data & Insight platform 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.

Data & Insights leverages Okta, 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 Data & Insights needing to implement custom integrations for each provider.
       - The ability to set up custom workflows that include extensions like multi-factor authentication.

When using single-sign-on with Data & Insights, Okta acts as a secure authentication proxy when users log on. However, the secure architecture of SAML and Okta makes sure the authentication process is actually more secure than signing into Data & Insights directly. Specifically:

    - User access credentials (passwords) are never entered into any system other than your Identity Provider. Neither Data & Insights nor Okta comes into contact with access credentials, so there is no chance they could be stored, logged, or leaked.
    - Okta never stores details of a user’s authentication with your Identity Provider, and acts merely as a proxy between your Identity Provider and Data & Insights, authenticating users and providing identifying details (email and a unique ID) to Data & Insights.

Data & Insights' SSO implementation has been designed with the security of our most critical customers in mind, and with SSO in scope, Data & Insights is one of the few SaaS companies of its size to be granted a FedRAMP Medium authorization.

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.

Existing user assets will not be impacted by the introduction of SSO.     Users who have existing Data & Insights 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 Data & Insights by their identity provider.

Users who do not have an existing Data & Insights account can log in to the Data & Insights 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.

SSO is compatible with the following Data & Insights products: Open Data, Performance Insights, and Perspectives. It is not yet available for Public Finance, Citizen Connect, or Public Safety products. Stay tuned to our Product News for updates.

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.
    - Users can also leverage an API key and secret for basic authentication where the API key is the username and the API secret is the password.
    - 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.

No. These passwords can be different.

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.

Since SSO is used for authentication and not account management, the user’s associated Data & Insights 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 Data & Insights domain. If you have additional questions regarding this issue, please reach out to    with specifics.

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



Article is closed for comments.