Security Assertion Markup Language (SAML 2.0) is a web security standard for logging users into applications.
This enables "single sign-on", which allows users to access multiple applications or websites via a single authentication source. This is perfect for large organizations with enhanced security or user provisioning requirements.
Enterprise customers can enable SAML 2.0 SSO for all managed domains in their Organization.
Coda currently supports any IdP supporting SAML 2.0.
Common terms
IdP or Identity Provider: The service or product that manages user accounts, credentials, and the login process. It will send "SAML Responses" to the SP (below) to authenticate users. Examples include Okta and Microsoft Azure.
SP or Service Provider: The service or product that the Identity Provider is sending a "SAML Response" to to log in an end user - that's Coda in this case!
JIT or Just-In-Time Provisioning: Creates new users or updates existing users on the fly. When a user first logs into Coda through SSO, Coda will set up a new account for that user. The account will be updated (including avatar, first name, last name, etc.) on subsequent logins to Coda.
Managed Provisioning: An optional form of provisioning using the SCIM protocol. This allows IT administrators via Identity Providers to create, update, import, deactivate, reactivate, and delete users. Most Identity Providers can use this protocol to automate system provisioning, updating, and deprovisioning for your users automatically.
FAQ
What preparation steps should I go through prior to enabling SSO?
To ensure your users' continued access to Coda, ensure everyone in your workspace(s) are all logging into Coda via their company email address. Only accounts under the Organization's list of managed domains will be able log in via SSO.
What happens to existing users when SSO is enabled?
Any user currently logging into Coda via an email address in a domain now managed by your Organization will be able to log in via SSO. They will continue to have access to existing workspaces, folders, and docs regardless of the mechanism they log in with. Note that users will not be logged out of Coda automatically.
Why can't I use the Google Drive integration with SSO?
Using Google's Drive API requires Coda to have a per-user Google authentication token. If users are not logging in with a Google OAuth token, Coda will not have the required token to send to Google API endpoints.
Can I have multiple forms of authentication enabled?
Yes, this is particularly useful during a transition from non-SSO to SSO-based authentication for testing or onboarding your company.
What happens when I deactivate or delete a user?
Deactivation of a user will log that user out (if they're currently logged in), prevent that user from logging back into Coda, and will stop accruing costs for that user (if they are a paid Doc Maker). Their docs will become read-only but could be migrated to new owners by Organization administrators.
How can I change ownership of a deactivated user's docs?
If you are an Organization Administrator, and one of your user's accounts has been deactivated via SCIM, you can transfer all their owned docs to another user in your organization. See more here.
Related Articles: