🔒 Security and Access Control

This section covers everything that controls who can use Pulse, how they authenticate, and how their access is scoped — from the first login through to multi-server security synchronisation.

What you'll find in this section

User Login and Authentication

The full hub for how users sign in to Pulse. Covers Pulse-native credentials, Windows Single Sign-On, CAM / Active Directory authentication, OpenID providers (such as Okta and Azure AD), and IBM ID. Also includes password reset, session timeout behaviour, and the underlying Pulse security model — instance security, user/group permissions, and Pulse's two-layer security architecture.

Why it matters: this is a single hub for every authentication question, instead of having "how do I log in?" answers scattered across the space. Whichever identity provider your organisation uses, this is where the configuration guidance lives.

Security Synchronisation Between Pulse Servers

How to designate a Master Pulse Server and have Dependent Servers pull their users, groups, and memberships from it — automatically, on-demand, or via manual export/import.

Why it matters: a single source of truth for security across multiple Pulse instances eliminates the drift that comes with maintaining the same users on every server independently. A change on the Master Server propagates everywhere on the next sync.

Summary

Pulse's security model is designed to fit alongside whatever authentication your organisation already uses — whether that's local credentials, Windows accounts, Cognos, or a modern identity provider. The articles in this section show how to configure each option and how to keep security consistent across a multi-server deployment.