Worklytics supports the following Identity Providers (IdP) as Single Sign-On (SSO) methods:
Users with the SecurityAdmin role may configure these via the Organization Settings > Single Sign-On section of the Worklytics Web App.
Google Identity and Microsoft Entra ID work in a similar way: once you select any of these, in the configuration flow, you'll be redirected to the corresponding login page to authenticate, and you will be asked for some permissions. After that, you'll be redirected back to Worklytics and the setup is complete.
Okta and SAML require some additional configuration; please refer to the specific documentation for all the details: Okta, and SAML.
When selecting an IdP for your organization, it's crucial to ensure that user identities are linked to a verified SSO domain. This domain must be associated with your organization's account in Worklytics. For security reasons, Worklytics manages this setting internally, and it is established during the account provisioning process.
For example, if your organization was provisioned with acme.com as one of the verified SSO domains, and any of your SecurityAdmin users attempt to configure an IdP that will provide user identities with emails from a different domain (e.g. user@foo.com), you'll get an error.
If you need to change the verified domains setting, please contact Worklytics Support.
All organizations in Worklytics need to configure at least one SSO method.
Once your organization's account has been provisioned, and you've received a One-Time Password (OTP) link, you should set up at least one SSO method. If you configure it incorrectly, or you want to switch to another provider, you'll need to set up a new SSO method before disabling the initial one. This restriction ensures that your organization does not lose access to the Worklytics Web App and minifies the risk of handling OTP links.
SAML is the only exception to this rule: Worklytics only supports one SAML IdP per organization, so you can change its configuration at any time.
Worklytics supports the Security Assertion Markup Language (SAML) for user authentication. You can integrate any Identity Provider (IdP) your company already uses if it supports SAML.
The Worklytics platform collects and analyzes workplace data at the instruction of Customer Organizations on their behalf, in accordance with our Privacy Policy, Terms of Service, and any customer agreement / laws / regulations which may supersede those terms. The Customer Organization remains the controller of this data and may instruct Worklytics to halt processing and destroy it at any time.
In order to set up a SAML integration, you have to be an administrator of your Worklytics account to configure the integration. If you don't have a Worklytics account, you can sign up here or contact our support team to get information on how to proceed.
The current version of the Worklytics SAML support, provides the following features:
Service Provider Initiated (SP-initiated) login flow. This option gives your end-users the ability to log into the Worklytics Login page using their email addresses.
Identity Provider Initiated (IdP-initiated) login flow. This option allows your end-users to sign in to Worklytics from your Identity Provider's website or application.
Worklytics SAML implementation requires the NAMEID email address format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. So, we will treat "name identifiers" as email addresses for the subjects of the assertions.
The ability to assign user roles based on the value of a SAML attribute sent by the IdP in the assertions. The configuration of this feature depends on the IdP of your choice. If you use One Login, go to you SAML connector configuration, add a custom parameter with the name groups and MemberOf as the value (this will send the groups membership of the user who is logging in, as they're configured in their OneLogin user profile).
Follow these steps to configure a SAML integration:
Log in to Worklytics as an Administrator (SecurityAdmin role).
Go to he "Settings" page and choose the Single Sign-On tab.
Click on Add Identity Provider in the "Identity Providers" section.
You will be prompted with different options, choose SAML.
Copy the Service Provider (SP) settings from the form you'll get (these values are specific to your Worklytics account):
Worklytics Single Sign On URL: this is the Assertion Consumer Service (ACS) value.
Worklytics Entity ID: this is also known as the Audience URI (per SAML standard).
Now follow the steps your Identity Provider requires to set up a SAML integration. The configuration may vary depending on the IdP you use. Examples:
At some point, you'll have to provide your IdP with the settings you've got in step #5, and grab the following settings to complete the configuration on our side:
IdP Single Sign On URL: this is where Worklytics will send the authentication requests.
IdP Issuer: identifies your organization in the IdP.
IdP X.509 certificate: authentication requests are signed using this value. Currently, Worklytics supports the SHA256 algorithm.
Once you have all the settings, fill the form (step #5) and click on Save settings.
If everything went OK, a confirmation message will appear.
(*) If you choose to use Microsoft Entra ID, and you plan to use "groups", you should configure the claims as follows: claim configuration. The http://schemas.microsoft.com/ws/2008/06/identity/claims/groups claim should have as source attribute Cloud-only group display names. And if you are using on-premises AAD synchronized with the Entra ID tenant, you will need to use sAMAccountName as source attribute.
If any doubts, contact our support team.
Assuming you're on the 7th step of the previous section, after logging-in to OneLogin as an administrator, you have to follow the next steps:
Go to Administration > Applications, and click on "Add App".
Search for "SAML Custom Connector (Advanced)", select it, fill up the "Display Name" with something that identifies it as to be used for Worklytics SP, and click "Save".
Now, in the configuration section, enter the SP settings you've got before:
Field RelayState: here you can specify any valid path (and params) of our Web App (e.g. /analytics/org). Users logging-in via IdP-initiated login flow will be redirected to that path after authentication.
Field Audience (EntityID) it's our Worklytics Entity ID field (i.e. https://app.worklytics.co).
Field Recipient it's our Worklytics Single Sign On URL field (i.e. https://app.worklytics.co/saml/sso/acme where "acme" it's your Worklytics' organization identifier).
Field ACS (Consumer URL) it's also our Worklytics Single Sign On URL field.
Field SAML nameID format: select Email.
Now, go to the SSO section where you'll find all the values needed to complete the settings form in our site:
Field X.509 Certificate
Field Issuer URL is our IdP Issuer field.
Field SAML 2.0 Endpoint (HTTP) is our Identity Provider Single Sign-On URL
Then, go to the Users section to manage the users who have to have access to Worklytics.
Go back to Worklytics and finish the configuration.
This page details how to 1) configure authentication for your organization's users to Worklytics (SSO) and 2) define a Role-based Access Control (RBAC) policy to authorize users to access with one or more supported roles (detailed below).
When your organization signs up for Worklytics, a new organization account is provisioned. Worklytics will send a One-Time Password (OTP) link to the designated account admin with the SecurityAdmin role (see below).
The recipient of the OTP link will be able to log in to the Worklytics' Web App and set up SSO (below) as well as define the organizations access control policies (grant user roles).
Worklytics supports the following SSO methods:
Any SecurityAdmin can configure these from the Organization Settings > Single Sign-On section. The configuration depends on the method and Identity Provider you choose; so, please refer to the specific documentation for each method.
Worklytics supports the following user roles:
| Role | Permissions |
|---|---|
Security Admins can grant or revoke roles to users through the "Roles and Access Control" user interface of the Web App. Typically, users will be identified by their email addresses when signing in using any of the single sign-on methods your organization has configured.
By default, any member of your organization that is able to log in to the Worklytics' Web App using any of those providers, will be granted the unprivileged User role unless the email address we receive from the Identity Provider matches one of the email addresses you have identified as subject of a role grant.
Role Conditions (**) can be added to restrict the role grant to a particular Identity Provider. For example, if Google and Microsoft are configured as Identity Providers, and a member of your organization's IT team has the email address user@acme.com on both providers, the SecurityAdmin role can be granted on the condition that they'll sign in using Microsoft; so, if they use Google the role won't be granted.
(*) SAML integrations also allow assigning roles by group. Check the SAML documentation for details on how this works.
(**) Role Conditions don't apply to One-Time Password (OTP) login links.
In the Roles and Access Control user interface, session management settings can also be configured:
Maximum Session Duration: the maximum duration of a user session before they must re-authenticate with any of the configured Identity Providers (defaults to 14 days)
Session Inactivity Duration: maximum time of inactivity before user sessions expire and they get logged out (defaults to 14 days)
The Worklytics App for Okta provides Single Sign-On (SSO) user authentication to access Worklytics, so you can use the credentials for your company's organization in Okta to log into your Worklytics account.
The Worklytics platform imports and analyzes workplace data at the instruction of Customer Organizations on their behalf, in accordance with our Privacy Policy, Terms of Service, and any customer agreement / laws / regulations which may supersede those terms. The Customer Organization remains the controller of this data and may instruct Worklytics to halt processing and destroy it at any time.
In order to add Okta as SSO provider, you have to be an administrator of your Worklytics account to complete the installation. You also need administrator rights of your Okta organization. If you don't have a Worklytics account, you can sign up here or contact our support team to get information on how to proceed.
The current version of the Worklytics App for Okta, supports two login flows:
Service Provider Initiated (SP-initiated) SSO. This option gives your end-users the ability to log into the Worklytics Login page using their Identity Provider credentials (your company's organization in Okta).
Identity Provider Initiated (IdP-initiated) SSO. This option allows your end-users to log into Worklytics directly from Okta, without having to go to the Worklytics login page.
Log in to Okta as an Administrator.
In your end-user dashboard, choose Applications then click on Browse App Catalog.
In the Search for an Application field, search for "Worklytics". When Worklytics' Okta-Verified OIDC appears, click on Add.
Now, on the General Settings page, you can type a name for the new application. For example: "Worklytics".
Use the option Assign to People, to assign those users that you want to have access to your Worklytics account.
Log in to Worklytics as an Administrator (SecurityAdmin role).
Go to he "Settings" page and choose the Single Sing-On tab.
Now, in the "Identity Providers" section, click on Add Identity Provider
You will be prompted with different options, choose Okta.
Complete the configuration by entering the following values that you'll find on the "Sign On" tab of the Worklytics application in Okta:
Client ID
Client secret: this is a private value that you must not share with anyone else.
Okta domain: your organization domain in Okta (example: my-company.okta.com).
When you complete the previous step, you'll be authenticated and redirected to Worklytics. If everything went OK, you'll see a new entry in the "Identity Providers" section of the Single Sign-On tab, and your end users can log into Worklytics from the login page using their email address, or by clicking on the Worklytics App Tile they'll get in their Okta's end-user dashboard.
If any doubts, contact our support team.
Analytics Viewer
AnalyticsViewer
Permissions to access the analytics dashboards and reports (e.g. members of your organization's people analytics team).
Data Connection Admin
DataConnectionAdmin
Permissions to create, remove, and manage integrations (data source connections). Usually, these are members of your IT Team.
Data Export Admin
DataExportAdmin
Permissions to export data from Worklytics, such as audit logs, data processing records (GDPR), and datasets.
Security Admin
SecurityAdmin
Permissions to make changes to the organization's settings. Ability to manage Single Sign-On (SSO) settings, grant roles to other users, change "Data Protection" and "Analytics" settings. Users with this role also have read-only access to integrations.
User
This is the implicit role that anyone who is able to sign-in to the Worklytics' Web App gets.
