Identity and access management in enterprise PSA is more demanding than in most enterprise software categories because the data the PSA holds is sensitive across multiple dimensions simultaneously. Time entries reveal individual consultant activity. Rate cards contain proprietary pricing. Project margin data is commercially confidential. GL-adjacent billing records are financial records subject to audit. A PSA that allows all authenticated users to see all of this data — or that manages credentials independently of the firm’s identity provider — creates security and governance risk that IT and finance teams will both flag during procurement. This article explains how SSO, SAML, and role-based access control work in enterprise PSA, and what distinguishes a permission model that actually governs financial data access at scale from one that provides the appearance of access control without the substance.
SSO and SAML: How Authentication Works in Enterprise PSA
Single sign-on allows users to authenticate once through a central identity provider and then access multiple systems — including the PSA — without entering separate credentials for each. In enterprise environments, SSO is not primarily a convenience feature. It is a security control: it means the PSA does not maintain its own credential store, which eliminates a category of risk (compromised PSA-specific passwords, orphaned accounts after employee departure) and centralizes authentication management in the IT team’s existing infrastructure.
SAML 2.0 (Security Assertion Markup Language) is the protocol that most enterprise identity providers use to communicate authentication decisions to service providers like the PSA. When a user attempts to access the PSA, the PSA redirects the authentication request to the identity provider. The identity provider validates the user’s credentials — through password, multi-factor authentication, or device certificate, depending on the firm’s policy — and issues a signed assertion back to the PSA confirming the user’s identity and, optionally, their group memberships and attributes. The PSA trusts that assertion without ever seeing or storing the user’s password. Any identity provider that supports SAML 2.0 is compatible with this pattern, which covers Okta, Microsoft Entra ID (formerly Azure AD), ADFS, OneLogin, Ping Identity, and most other enterprise identity platforms in common use.
Identity Provider Compatibility and Configuration Depth
SAML 2.0 support is the baseline, but the configuration depth available within that standard varies between PSA platforms and matters for enterprise deployments. The questions that reveal configuration depth go beyond “do you support SAML 2.0” — all serious enterprise PSA platforms do — to how the platform handles SAML assertions in practice.
Attribute mapping is the first depth indicator. When the identity provider issues a SAML assertion, it can include attributes beyond the user’s identity: group memberships, department, location, employment type. A PSA that can consume those attributes and use them to automatically assign the correct role and cost center access to the user — without requiring a PSA administrator to manually configure each new user — scales to a 300-person firm without becoming an administrative burden. A PSA that requires manual role assignment after every SSO login does not.
Just-in-time provisioning is the second depth indicator. When a user authenticates via SAML for the first time and no PSA account exists, the platform can either reject the authentication or automatically create an account with default permissions derived from the SAML assertion. Just-in-time provisioning is what allows new joiners to access the PSA immediately on their first day without an IT ticket to create a PSA account. Without it, every new employee requires a separate provisioning step in the PSA that IT must complete before the employee can log in.
Role-Based Access Control: What It Means in the PSA Context
Role-based access control (RBAC) is the principle that a user’s access to data and operations is determined by their role in the organization, not by individual configuration. In most enterprise software, roles map to functional job types — administrator, manager, user — and the permissions attached to each role are fixed by the vendor. Enterprise PSA access control is more complex because the relevant dimensions are not just functional roles but also the organizational scope of those roles.
A resource manager at a 300-person firm should be able to see utilization data and resource allocations for consultants in their practice, but not in other practices. A billing coordinator should be able to create invoices for their assigned client portfolio, but not view the margin data behind those invoices. A finance director should have read access to all financial data across cost centers, but not be able to modify billing rules. These access patterns require a permission model that combines role-based functional permissions (what operations can this user perform?) with data-scoped organizational permissions (on which cost centers and engagements does this role apply?). A flat role model — where all billing coordinators see all client data or all resource managers see all utilization data — does not serve a firm where different practices operate independently and confidentiality between them matters.
The Two-Tier Permission Architecture
Enterprise PSA platforms handle this complexity through a two-tier permission architecture that separates system-wide permissions from data-scoped permissions.
System-wide permissions (sometimes called global permissions) control access to features that affect the entire platform: the ability to configure system settings, manage currencies and exchange rates, maintain the cost center hierarchy, administer user permissions, and run system-level reports. These permissions are granted sparingly because they carry elevated risk — a user with permission to modify the cost center structure can potentially rearrange the hierarchy in ways that grant themselves access to data they were not intended to see. System-wide permissions are typically held by a small number of administrators and the finance team leads who own specific system-level configurations.
Data-scoped permissions (cost center permissions) control what a user can see and do within specific parts of the organizational hierarchy. These permissions are granted at a node in the cost center tree and inherited downward: a user with a permission at the European regional level inherits that permission across all practices and entities beneath it, without requiring individual configuration for each child cost center. Two types of data-scoped permissions exist: action-based (what operations can the user perform — create engagements, maintain billing rates, approve timesheets) and data-based (what cost center data can the user see when running reports, independent of what operations they can perform). The separation matters because a user might need to run consolidated reports across cost centers they cannot operationally modify.
Governing Access to Financial Data Specifically
The most governance-sensitive data in a PSA is financial: rate cards, cost rates, project margin, billing configurations, and the GL-mapped transaction records that feed the ERP. At enterprise scale, the principle of least privilege — granting each user access only to the financial data their role requires — is both a security requirement and an operational one. When too many users can see cost rates, sensitive compensation-adjacent data spreads beyond the HR and finance perimeter. When too many users can modify billing rules, invoice accuracy depends on trusting every one of those users to configure correctly.
Example: A 320-person consulting firm configures PSA permissions so that project managers can view their own project’s budget versus actuals but cannot see the underlying cost rates used to calculate margin. Finance directors can see all financial data across all cost centers but cannot modify billing rules — that permission is limited to the billing administration team. Resource managers can view utilization data across their practice but cannot see individual consultant cost rates. The permission model is configured once at each level of the cost center tree and inherited downward, requiring no per-user configuration for the 260 consultants and project managers in the firm.
The configuration risk in financial data governance is privilege escalation — a user who can modify the permission model can grant themselves access they were not intended to have. Enterprise PSA platforms address this by making the “Users & Permissions” administrative capability itself a separately controlled global permission, and by maintaining an audit log of permission changes so that IT administrators can review any changes to the access model after the fact.
User Provisioning and Deprovisioning at Scale
At 300 people, manual user provisioning in the PSA becomes a meaningful IT burden. SCIM (System for Cross-domain Identity Management) is the protocol that automates this: when the identity provider creates a new user, updates their attributes, or deactivates their account, SCIM pushes those changes to connected applications — including the PSA — automatically. The result is that onboarding a new consultant involves one action in the HR system or identity provider, and the PSA account is created with the correct roles and cost center assignments derived from the user’s department and job title, without an IT ticket.
- Deprovisioning: when an employee leaves, their PSA account should be deactivated on the same day their identity provider account is deprovisioned — not when someone remembers to check the PSA user list. SCIM-based deprovisioning makes this automatic. SSO-only (without SCIM) means the account is effectively inaccessible because the user cannot authenticate, but the account remains in the PSA and appears in user lists, resource scheduling, and reporting until manually removed.
- Role changes: when a consultant is promoted or moves to a different practice, their PSA access should update to reflect their new organizational position. SCIM-based attribute sync means those changes propagate from the identity provider to the PSA automatically. Without SCIM, a practice manager who moves to a different practice may retain their old practice’s data access for weeks or months until an administrator notices.
- Audit trail: every access change — account creation, role modification, permission update, deprovisioning — should be recorded in a tamper-resistant log that compliance and security teams can query. When a SOC 2 auditor asks for evidence of access control effectiveness, the provisioning log is the primary artifact.
Questions That Reveal Access Control Maturity
Three questions move PSA access control evaluation from feature claims to operational evidence. Ask them in sequence during the security and IT evaluation phase, not the functional demo phase.
First: show us a new user being provisioned via SAML just-in-time provisioning with automatic role and cost center assignment derived from identity provider attributes. This single scenario tests SSO depth, attribute mapping, and automatic role assignment simultaneously. A vendor who cannot demonstrate this in a live environment is relying on manual provisioning regardless of what their feature list claims.
Second: what happens in the PSA when a user’s identity provider account is disabled? The correct answer is immediate loss of PSA access — either through SCIM-triggered deprovisioning or through SAML authentication failure at the next session renewal. If the answer is “the PSA account remains active until manually deactivated,” ask how that manual step is tracked and what the average lag is between identity provider deprovisioning and PSA deprovisioning. The lag is your orphaned account risk.
Third: walk us through the permission model for a user who changes roles within the organization — for example, a project manager who becomes a practice lead. Specifically, how are the old permissions removed and the new ones applied, who performs that action, and is the change logged? This tests whether the RBAC model supports controlled role transitions or whether role changes accumulate permissions over time rather than replacing them.
