Pulse Security Overview

Pulse provides a flexible, layered security model that controls who can access the Pulse web client and what actions they can perform. Understanding how Pulse security works is essential before configuring users, groups, and authentication methods.

Security Layers

Pulse security operates at two levels:

Pulse Application Security — Controls access to the Pulse web client itself (login, groups, permissions).
TM1 Instance Security — Controls what TM1 data a user can see inside Pulse, inherited from the TM1 server's own security model.

Authentication Methods

Pulse supports several authentication methods:

Method	Description

Method	Description
Native (Pulse users)	Users are created and managed directly inside Pulse with a username and password.
Windows SSO	Users are automatically logged in using their Windows account.
CAM / Active Directory	Users authenticate via IBM Cognos Access Manager (CAM) backed by Active Directory.
OpenID (OIDC)	Users authenticate via an external identity provider such as Okta or Azure AD.
IBM ID	Used when Pulse monitors IBM Planning Analytics SaaS (PA Cloud).

Only one authentication method is active at a time. The method is configured in conf/Pulse.cfg under the [Password] and related sections.

Groups and Permissions

Pulse uses Groups to assign permissions to users. Every user must belong to at least one group.

Default Groups

Group	Access Level

Group	Access Level
ADMIN	Full access to all Pulse features and administration.
PUBLIC	Read-only access. Used as the default group for unauthenticated or newly created SSO users.

Custom groups can be created under Administration → Groups to restrict or grant access to specific Pulse features, environments, and TM1 instances.

Instance-Level Security

By default, all Pulse users can see all TM1 instances. If you want to restrict which users see which TM1 instances, you can enable inclusion-based instance security via the [Security] section in Pulse.cfg:

[Security]
UseInclusionForInstanceSecurity = true

When enabled, access to each TM1 instance must be explicitly granted to a Pulse group.

User Account Lockout

Pulse locks a user account after 5 consecutive failed login attempts. The lock is released by restarting the Pulse Application Server service. This limit is not configurable.

Security Best Practices

Run Pulse services under a dedicated Windows service account with the minimum required permissions.
Use Windows SSO or OIDC in corporate environments to avoid managing separate Pulse passwords.
Create dedicated Pulse groups for different teams (e.g. Developers, Finance, IT Admins) rather than assigning everyone to ADMIN.
Regularly review user accounts under Administration → Users and remove accounts for users who have left the organisation.
Enable UseInclusionForInstanceSecurity in environments where not all users should have visibility into all TM1 instances.