SAC Security Fundamentals: Users, Roles, and Application Authorizations

Explanation

SAP Analytics Cloud (SAC) security operates on two distinct but related layers: application security (what a user can do inside the tool) and data security (what data a user can see once inside a model or story). This lesson focuses on the application layer because it is the entry point every consultant must understand before touching data-level controls. At the core is the User object. Users can be created locally in SAC, but in almost every production tenant they are provisioned through an identity provider using SAML single sign-on, often federated from a corporate directory or SAP Identity Authentication Service (IAS) in BTP-integrated landscapes. Each user is assigned one or more Roles. A Role is a bundle of permissions expressed as combinations of Business Object (Story, Model, Connection, Team, User, Role itself, Digital Boardroom Agenda, Application, Data Access Control, and more) and Permission (Create, Read, Update, Delete, Share, Maintain, Execute, Approve, Impersonate depending on object type). SAC ships several standard roles out of the box such as a system administrator role, a business content administrator role, and a basic viewer role, but production tenants almost always create custom roles scoped to job function, for example a 'Finance Story Author' role restricted to specific folders versus a 'Finance Viewer' role with only Read permission. Teams are the second major construct. A Team is a group of users that can be granted access to folders and content in bulk, and teams can also be linked to data access controls for data-level security, which is covered in the next lesson. Using teams instead of assigning permissions to individual users is the standard scalable pattern: you assign a Role to a Team once, add or remove users from the Team as staffing changes, and avoid re-touching role assignments constantly. Folders and content-level sharing add a second dimension on top of roles. Even if a role grants Read on the Story object type generally, actual visibility of a specific story is controlled by explicit sharing at the folder or file level, similar to file-system permissions. This dual-gate model (role permission type + explicit object share) is a common source of confusion: a user can have the correct Role permission but still not see a story because nobody shared the folder with their Team. Authentication itself matters for security posture. SAC supports SAML 2.0 SSO as the standard enterprise pattern, and in BTP-centric landscapes this is frequently brokered through SAP Identity Authentication Service, which can itself federate to a corporate IdP (Azure AD, Okta, on-premise ADFS). Understanding whether your tenant uses IAS-brokered SSO or a direct SAML trust to a corporate IdP is essential when troubleshooting login failures, because the certificate and metadata exchange differs slightly between these topologies. From a runtime flow perspective: a user attempts to open SAC, is redirected to the configured Identity Provider, authenticates, and SAC receives a SAML assertion containing the user identifier. SAC then resolves this identifier against its internal user store to determine role and team memberships, which drives what the user sees in the launchpad, what folders are visible, and what actions (create model, edit story, manage connections) are enabled in the UI. Provisioning mismatches (a user exists in the IdP but not yet created/mapped in SAC) are the most common day-one support ticket.

Code example

-- Not a programming language example; SAC roles are configured via UI, but here is a representative-- role definition expressed as pseudo-configuration for documentation/change-request purposes: Role: FIN_STORY_AUTHOR  Business Object: Story    Permissions: Create, Read, Update, Share    Scope: Folder = /Public/Finance/*  Business Object: Model    Permissions: Read    Scope: Folder = /Public/Finance/Models/*  Business Object: Connection    Permissions: Read    Scope: Specific connection = 'FIN_DATASPHERE_LIVE' Team: FIN_AUTHORS_TEAM  Assigned Role: FIN_STORY_AUTHOR  Members: jsmith, agupta, mrossi -- Folder share (separate step from role):Share /Public/Finance/ -> Team: FIN_AUTHORS_TEAM -> Access: Editor

Real project scenario

A finance transformation project onboarded 40 planning users across three regions. The project team created two roles (Planning Author, Planning Viewer) and three teams by region, then shared regional folders only with the matching regional team. During UAT, APAC users reported seeing EMEA stories; the root cause was that the initial folder share was applied at the parent Public folder level to all teams instead of per-region subfolders, illustrating why folder-level sharing must be explicitly scoped even when roles look correctly restricted.

Common mistakes

• Assuming a Role permission alone grants visibility, without realizing folder/content sharing is a separate required step • Assigning permissions directly to individual users instead of teams, causing unmanageable sprawl as staff change • Granting broad Read/Update on Story or Model business objects tenant-wide instead of scoping by folder • Not documenting which team owns which folder, leading to accidental over-sharing during reorganizations • Forgetting that removing a user from a Team does not retroactively revoke content they may have exported or embedded elsewhere

Best practices

• Always design security around Teams, not individual users, from day one • Keep role definitions narrow and named by business function (e.g., FIN_VIEWER) rather than generic broad roles • Maintain a folder structure that mirrors your team/role structure so sharing stays predictable • Periodically audit team memberships against HR/staffing changes, especially after reorganizations • Document the SSO topology (direct SAML vs IAS-brokered) so authentication issues can be triaged quickly

Interview angle

Interviewers commonly probe whether a candidate understands that SAC security has two independent gates: role-based object permissions and folder/content sharing. A strong answer explains both layers, gives an example of a support ticket caused by confusing the two, and mentions using teams over individual user assignment for scalability.