Smartling provides Enterprise customers wishing to manage their users via their company’s Single Sign-On (SSO) server with two integration options. We work with major authentication systems including Okta, ADFS, and Google.
When SSO has been integrated, and you invite users to Smartling, they must first activate their account with a placeholder password. After doing so, SSO will be activated from that user's next log in.
Each SSO integration is tied to a single Smartling account. Users who log in via SSO will only have access to that specific account. If you work in multiple Smartling accounts, you will need to log in with your email and password to access any accounts that do not have SSO configured.
OpenID Connect 1.0
OpenID Connect (OIDC), is a JSON-based identity management layer built on top of the OAuth 2.0 protocol. You may work with Smartling engineering to integrate their OIDC service as an upstream identity provider. Once configured, you can use your OIDC service to authenticate users to Smartling. Login is initiated using one of the flows below.
This is the recommended integration option for SSO.
If required, Security Assertion Markup Language 2.0 (SAML) can also be integrated for SSO.
SAML requires more implementation effort as it is an XML-based standard for exchanging authentication and authorization data between security domains. As this also requires manual key rotation, you will have to work with Smartling engineering to integrate.
Optional Configurations
Auto-registration
Smartling can enable automatic user registration for users that do not currently have Smartling accounts. If this feature is enabled, new users will automatically be granted either the Requester user role or Project Manager user role the first time they log in.
- Only one role can be enabled at a time (either Requester or Project Manager).
- If a Project Manager role is selected, we recommend reviewing the Notification Settings for automated email notifications. By default, users with a Project Manager role will receive email notifications for events occurring across all projects with Auto-registration. Users with a Requester role, on the other hand, will only be notified about the jobs they created themselves, or issues where they are mentioned specifically.
Tip: Consult your Solutions Architect to enable this feature for specific projects.
SSO Enforcement
Enabling SSO does not require users to log in with their SSO credentials. Once SSO is enabled, your users can use SSO or their existing Smartling Dashboard passwords. Smartling can enable SSO enforcement for specific domains and require users to use SSO.
Tip: Consult your Solution Architect to enable this feature for specific domains.
Login Flows
Smartling supports two login flows for initiating login from Smartling.com services using your authentication server.
Link-Based Login
Customers who maintain an internal portal and expect users to follow links from this portal into Smartling may use our link-based flow. For this flow to work, Smartling will provide a link to your account or project, such as:
Account links: https://sso.smartling.com/sso-apps/dashboard/accounts/1111111
Project links: https://sso.smartling.com/sso-apps/dashboard/accounts/1111111/projects/2222222
When following one of the links above, Smartling’s SSO server will know to use your company ODIC or SAML service for authentication. Instead of seeing the Smartling login form, the user will immediately be redirected to your login URL. When login completes on your authentication service, the user will be redirected back to Smartling and fully authenticated.
Form-Based Login
If you expect users to access Smartling.com services via a direct link, you may prefer to use our form-based login flow. With form-based logins, users will see the normal Smartling login form. However, they will not be required to input a password.
Based on the domain configured with Smartling for SSO, the user will be redirected to your login URL. When login completes on your authentication service, the user will be redirected back to Smartling and fully authenticated.
For example, if your company domain is @example.com, the authentication flow can be configured to redirect all user@example.com login attempts to your SSO server when the user enters credentials on Smartling’s login form. Using this flow, the password field on the Smartling login form will be ignored.
Contact your Smartling representative about setting up SSO
Frequently Asked Questions
What is the expected behavior after SSO has been implemented correctly?
For a new Smartling user, the invited user will still be asked to activate their Smartling account with a placeholder password (see screenshot below). After the account creation, the user's next login session will be through the SSO login page.
If the user already has a Smartling account:
- If the user never logged in via SSO in their web browser or is using a private browser session with no cache (e.g. "Incognito" mode in Chrome), the user will be prompted to log in through their SSO login steps, including multi-factor authentication (OTP code, etc.).
- If the user is already logged in via SSO in their web browser, the Smartling login page will take the user to their regular landing page in the Smartling dashboard.
When SSO enforcement is enabled, will external linguists and translation vendors still be able to access the Smartling Dashboard?
This will only affect your internal team members, i.e. anyone with your company email addresses.
All company-external members of your translation team (such as external Translation Resources or Agency Owners) can continue to use their preferred Smartling login flow - whether it's “Sign in with Google” or with their Smartling credentials.
Auto-registration has been enabled but my team is not getting automatically added to projects as expected. Why is this happening?
Check whether the user already exists in the Smartling platform (check Team > Users > Users tab). If the user account already exists in Smartling, auto-registration as a Requester or Project Manager will not work. In this case, the user’s role will need to be manually configured by a user with an Account Owner role.
Also check whether you have implemented SSO Login flows. For example, if your team is logging in via “Sign in with Google” button instead of going through your implemented SSO protocol, auto-registration won’t apply.