Skip to main content
Qlik Cloud is an analytics platform that holds your company’s apps, datasets, and other analytics content. Connect your Qlik Cloud tenant to Oleria to see who can administer the tenant, who can see or edit each space and its content, and which bot users, OAuth clients, client secrets, and API keys can reach the tenant API. Oleria connects with a machine-to-machine (M2M) OAuth client and can take remediation actions directly from Oleria. Each Oleria integration covers one Qlik Cloud tenant. To connect another tenant, add another integration.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Qlik Cloud tenant:
  • Accounts - every active, provisioned, invited, and disabled user, with name, email, status, creation date, and roles. Invited users are shown as disabled. Users who hold a tenant role with admin level, such as TenantAdmin, are marked as administrators.
    • Last activity - the time of the user’s most recent action in the tenant audit log, so you can find dormant accounts. License changes and Qlik’s own background events don’t count as the user’s activity.
    • SSO - shown as configured for every user when the tenant has an active interactive SAML or OIDC identity provider, and as not configured otherwise.
    • Licenses - each user’s license assignment type, such as full user, professional, or analyzer, from the tenant’s license assignments.
  • Non-human identities (NHIs):
    • Bot users - the user that Qlik creates for each machine-to-machine OAuth client, shown as a service account under the client’s name.
    • OAuth clients - every OAuth client in the tenant, shown as an application, with the member who created it and a link to the bot user it acts as.
    • Client secrets - each OAuth client’s secrets, shown as secrets and paired with a credential that shows its status, creation date, and creator. Oleria never reads secret values. A bot user and its OAuth client show their newest secret’s creation date as their last credential rotation.
    • API keys - shown as personal access tokens, or as API tokens for SCIM keys, each paired with a credential that shows its status (active, expired, or revoked), expiry, and creator. Personal keys are linked to the user who owns them.
  • Groups - groups synced from your identity provider, custom groups, and the built-in Everyone group, with their members and the tenant roles assigned to each group.
  • Roles - tenant roles, built-in and custom, who holds each, directly or through a group, and what each tenant role allows on spaces, apps, and each other kind of content, read from the role’s permissions. Space roles, such as consumer, contributor, and producer, appear as a separate role for each space, such as consumer (Finance), so a space-level grant isn’t mistaken for a tenant-wide one.
  • Resources - shared, managed, and data spaces, and the apps, datasets, and other content items in them. Oleria maps who can reach each space through which space role, directly or through a group, which users and groups an app is shared with directly, and which apps anyone can open through an anonymous link. Space owners and item owners have owner-level access. Apps link to the app in Qlik Cloud. Anyone with an anonymous link appears as one anonymous account with the Anonymous Accessors role.
  • Activity - events from the tenant audit log, such as:
    • user sign-ins and sign-outs, and tokens issued to bot users
    • user, group, role, space, app, and OAuth client creation, changes, and deletion
    • space membership changes
    • API key and client secret creation and deletion
    • license assignments, tenant settings, and identity provider changes
    • app opens and reloads, changes to sheets and other objects in an app, and AI assistant changes
    • app shares
    Each event reads as a sentence, such as “Jane Doe opened app Sales Dashboard”, and events on an app link to the app in Qlik Cloud. Sign-ins show whether the user signed in through SSO or with a Qlik Account password. Event types that Qlik Cloud adds later are kept as custom events.
The integration shows the tenant’s sign-in methods: SSO when the tenant has an active interactive SAML or OIDC identity provider, and Qlik Account email and password otherwise. When the tenant uses a SAML identity provider, Oleria links Qlik Cloud to the app in your identity provider through the SAML signing certificate. Oleria refreshes this data on its regular sync schedule.

​
Prerequisites

  • A Qlik Cloud user with the TenantAdmin role, to create the OAuth client and assign it a role.
  • A dedicated OAuth client for Oleria. Qlik Cloud creates a bot user for it, and that bot user is Oleria’s service account in your tenant. Don’t share the client with other tools, so its access and audit events belong to Oleria alone.
  • The address of your Qlik Cloud tenant, for example https://your-tenant.us.qlikcloud.com. Any commercial Qlik Cloud region (*.qlikcloud.com) is supported.
  • Admin access to the Oleria workspace.

​
Required permissions

Qlik Cloud limits an M2M OAuth client’s token to both the scopes the client is allowed and the roles of its bot user. Oleria needs both of these: Oleria checks both when you connect and before every remediation action, and reports which one is missing.

​
Create an OAuth client in Qlik Cloud

1

Create the client

In Qlik Cloud, go to Administration -> OAuth and select Create new. Choose the Web client type, select Allow Machine-to-Machine (M2M), and add the admin_classic scope.
2

Trust the client and copy its credentials

Set the client’s consent method to Trusted, then copy the client ID and the client secret.
3

Give the bot user the TenantAdmin role

In Administration -> Users, give the client’s bot user the TenantAdmin role. Qlik creates the bot user, named after the client, the first time the client requests a token. If the bot user isn’t there yet, connect the integration in Oleria first: Oleria requests a token and then reports that the bot user lacks TenantAdmin. Assign the role, then select Authenticate again.

​
Connect Qlik Cloud to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations, then select the Qlik Cloud tile.
2

Complete the connection form

3

Authenticate

Select Authenticate. Oleria requests a token for the client, checks that Qlik granted it the admin_classic scope, and checks that the client’s bot user holds TenantAdmin. Then it saves the integration.
If Oleria can’t reach the tenant, check the tenant URL, client ID, and client secret, and confirm that the client allows M2M and its consent method is Trusted. If Oleria reports that the client has no bot user, the client isn’t a machine-to-machine client. Create one as described above.

​
Verify the integration

Confirm the new instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, you can review the discovered users, groups, roles, spaces, and NHIs in your Oleria workspace. On the integration’s Capabilities tab, Read users, Read groups, and Read roles show as available, each with the admin_classic permission.
If you rotate the client secret in Qlik Cloud, edit the integration and enter the new secret. When you edit the integration, leave OAuth Client Secret (optional) blank to keep the stored secret. If you change the client ID, enter that client’s secret too.

​
Remediation actions

Beyond discovery, Oleria can act on Qlik Cloud access to remediate risk. Every action needs the admin_classic scope and the TenantAdmin role on the bot user. Oleria checks both before an action runs and reports any that’s missing. Space ownership isn’t a space role, so Oleria can’t grant or remove the owner role of a space. Change the space owner in Qlik Cloud instead. Oleria won’t remove a role from, disable, delete, remove from a group or a space, or revoke app access of the bot user the connection runs as. It won’t disable the OAuth client the connection uses or revoke that client’s secrets.

​
Known limitations

  • No MFA status or password change date. Qlik Cloud’s APIs don’t expose either, so MFA shows as unavailable for users and the last password change stays empty. Qlik Cloud also doesn’t expose how each user signs in, so it shows only on their sign-in activity.
  • Last activity comes from the audit log. Qlik Cloud doesn’t record a last sign-in on the user. Oleria uses the time of the user’s most recent audit-log event. A user with no event in the last 90 days shows no last activity. OAuth clients and client secrets show no last use.
  • Activity covers the last 90 days. Oleria reads the audit log that Qlik Cloud keeps for 90 days. It doesn’t read archived audit events. Audit events carry no IP address or location.
  • OAuth client creators come from the audit log. Qlik Cloud doesn’t record who created an OAuth client, so Oleria reads it from the client’s creation event. Clients created more than 90 days ago show no creator.
  • SSO is detected per tenant. Oleria shows SSO as configured when the tenant has an active interactive SAML or OIDC identity provider. It doesn’t show SSO as required, because Qlik Cloud doesn’t expose whether users can also sign in another way.
  • License data depends on your subscription. If Qlik Cloud doesn’t return license assignments for your subscription, such as a capacity-based subscription, license fields show as unavailable.
  • API keys depend on the tenant setting. If API keys are turned off for the tenant, Qlik Cloud refuses to list them, and Oleria syncs everything else without API keys.
  • Personal spaces aren’t collected. Qlik Cloud doesn’t list personal spaces, so their items appear only when the connection’s bot user can see them.
  • Anonymous links need Qlik Cloud’s anonymous access subscription. Only tenants with that subscription can share an app through an anonymous link. On other tenants there are no anonymous links to show or remove.
  • Only apps have links. Qlik Cloud doesn’t provide a link for spaces and other items, so only apps, and activity on apps, link to Qlik Cloud.
  • Interactive OAuth clients can’t be disabled. Qlik Cloud has no way to disable an OAuth client, so Oleria disables an M2M client’s bot user instead. Interactive clients have no bot user, so Disable NHI refuses them. Revoke their client secrets instead. Oleria doesn’t show which users have authorized an interactive client.
  • Group actions cover custom groups only. Groups from your identity provider are managed there, so Oleria refuses to change their members. For a user who is also in identity-provider groups, Oleria checks after each change that those groups are unchanged, and reports the action as failed if they aren’t. Oleria restores the user’s custom groups. Groups from your identity provider that Qlik Cloud dropped come back the next time the user signs in.

​
Contact us

For questions about this integration, contact us at support@oleria.com.