This article and video are ideal for any system administrator or security architect to address common questions to ensure a successful implementation. Focusing on key items you should know sooner rather than later to avoid surprises. For example:
- How user security works and the use of Scoped Roles with associated best practices
- Why mapping on e-mail for SAML SSO could create users with inconsistent userIDs between SAP Analytics Cloud and Datasphere (it may not matter, but worth knowing why)
- Why dynamic user creation when SAML SSO is mapped on e-mail could be problematic for Analytics Cloud, unlike Datasphere.
- What are the benefits of a predictable userID in SAP Analytics Cloud unlike the same need in Datasphere.
- How SAML SSO impacts Data Access Controls.
- Overview of Data Access Controls and demonstrations of implementing each of the 3 structure options
- How Spaces in Datasphere can be used with Data Access Controls to ensure users only see the data they should.
- Finally, additional best practices
Feel free to post a comment, but if you'd like a reply please instead post a question. (Since only 'questions' enable replies and keep the context of the question)
Resources
Preview and download | .pptx, Version 1.1, February 2025 |
 | Video .mp4, 1 hour 25 mins Version 1.0, July 2024 |
| SAP Enterprise Support Value Maps - E-Learning | Version 1.0, July 2024 |
Video bookmarks
- Application users
- User access is granted by roles
- What this means
- Best Practice (likely to evolve over time)
- Separate user directories (includes why dynamic user creation with SAML SSO mapped on e-mail could be problematic)
- For SAP Analytics Cloud, there are benefits of a predictable USERID of your choice
- Best Practice
- Database Users
- Demo of creating a new scoped role following best practice, assigning a user to a space, creating a view and consuming it as a database user
- Overview row-level security
- Concept
- Structures with ‘Single Values’
- Demo of creating Data Access Control with ‘Single Values’
- Structures with ‘Operator and Values’
- Demo of creating Data Access Control with ‘Operator and Values’
- Structures with ‘Hierarchy’
- Demo of creating Data Access Control with ‘Hierarchy’
- Securing Data Access Controls with the use of ‘Spaces’
- Additional practical and best practice advice
Application users
User access is granted by roles:
- Global Roles:
- Global roles grant privileges for Service (tenant) administration
- The union of all global roles determines the privileges
- Typically administrators need global roles, unlike regular users
- Scoped Roles:
- Grants both privilege and access to ‘Spaces’
- Membership of the Space grants access to artefacts stored within, such as tables, views etc.
- Users assigned to a particular space have access to all artefacts and data within that space
- Access to a Space can only be granted via a ‘Scoped Role’, not a global role
- Scoped Roles can not be set as ‘default’, which means new users are not automatically assigned a scoped role (see next slide for options)
What this means
- Granting access requires a single-scoped role since it grants both application privileges and access to Space(s)
- The same user can have different rights in different Spaces
- User could be a ‘viewer’ of one Space and a ‘modeller’ of another
Best Practice
- In general use 1 scoped role per Space
- So, a user needing access to 4 spaces, would be granted 4 scoped roles
- Though it can be handy to have an admin-scoped role over all Spaces.
- Means that admins need just a single-scoped role
- Limir re-using scoped roles for multiple spaces
- It isn’t always obvious when granting a scoped role to a user which Spaces they have access to
- Use of SAML mapping for roles will add all spaces of the scoped role
- Use of SCIM API will add all spaces of the scoped role
- The workflow to add roles to a user (Menu-Security-Users) will add all spaces of the scoped role
- Adding a new Space to an existing scoped role, will add all existing users of that scoped role to the new Space
- The following enables you to specify which Spaces of a scoped role are granted:
- Command line interface (doc)
- Workflow to add users to a Space (Menu-Space Management)
- Workflow to add users to roles (Menu-Security-Roles)
- Avoid using standard application roles, instead use them as a template for custom global roles and scoped roles
- SAP will update the standard application roles over time, which means you’re not in complete control when updates are applied. Always use a custom role instead.
Separate user directories
- User accounts are held in each application, SAP Datasphere and SAP Analytics Cloud
- Each application has its own roles and authorization model
- Means a user is created and maintained in each application
- Potential issue when the following is true:
- SAP Analytics Cloud OR Datasphere SAML SSO user attribute is mapped on ‘email’ AND dynamic user creation is enabled
- Why? Because the user ID assigned is derived from the email address and not determined by you
- MATTHEW, is likely the user ID for a user with email matthew @ sap.com
- Undetermined user IDs could make managing access rights more challenging since access is controlled by the ‘SSO user attribute’.
- In all other cases, the user ID can be determined by you
- If using SCIM, use SCIMv2 to define the user ID (userName) even when mapping on e-mail
For SAP Analytics Cloud, there are benefits of a predictable USERID of your choice:
- Users make sense of the SAC USERID, it appears within the user interface
- Easier to control, row-level security (for SAC-acquired models) is based on SAC USERID
- Gain insights easier as the activities log identifies the user by SAC USERID
- Resolves sharing permissions when content moves about the landscape as some artefacts are stored within themselves who can access them by SAC USERID
For Datasphere
- The ‘identifier’ used by Datasphere Data Access Control, is the attribute you map users upon
- If mapping on ‘email’, Datasphere row-level access will be authorized based on ‘email’ unlike SAP Analytics Cloud which is always by SAC USERID
Best Practice
- Can map on different attributes for each application, but not great for consistency
- Avoid enabling ‘dynamic user creation’ when mapping on e-mail to reduce potential complexity.
Database users
Database only users
- Users can also be created for ‘database’ only access
- Such users can read and/or write based on database-level privileges
- Each database user has an Open SQL schema automatically created for them
- Ideal for 3rd party tools that require only view-level access
- Such users can not enjoy Business Layer objects such as Analytical Models
- SAP Analytics Cloud users must connect to SAP Datasphere as regular Application users (i.e. not database-only users)
Overview row-level security
Data Access Controls Concept
Application of row-level security requires:
- 1) A ‘Data Access Control’ object (red outlined above)
- Such objects contain a ‘Permissions Entity’ which is a table/view
- 1 of 3 different table ‘structures’ must be specified
- ‘single values’ (as shown)
- ‘operator and values’
- or, ‘hierarchy’
- 2) Joining the ‘Data Access Control’ object to a table/view
- The ‘permission entities’ are joined to the ‘data’ table thus reducing the rows accordingly – see 2 for ‘single values’
- The data is then filtered by the user accessing the ‘data’ table
- User identifier is always the same as the ‘Subject NameID’ used to map the user to Datasphere as part of the SAML Single-Sign-On
- This can be a USERID, email, or a custom property
- For the default Authentication method, i.e. without any custom SAML SSO, the identifier is the email
- More details on ‘operator and values’ and ‘hierarchy’ structures next
Structures with ‘Single Values’
Structures with ‘Single Values’
- Row per value
- For 100 values, you’d need 100 rows
- Each entity is an ‘AND’ with others
- Ideal for simple use cases
- not necessarily the best choice for performance when lots of values are needed
- Documentation
Structures with ‘Operator and Values’
Structures with ‘Operator and Values’:
- Support much more complex logic
- Requires a more complex ‘permission table’ to support operators, restriction, criterion, operator, first and optional second values
- Support operators:
- ALL (or *) - Provides access to all records.
- N (or IS NULL) - Is null.
- NN (or NOT NULL) - Is not null.
- EQ (or = ) - Equal to First Value.
- NE (or <> or !=) - Not equal to First Value.
- GT (or >) - Greater than First Value.
- GE (or >=) - Greater than or equal to First Value.
- LT (or <) - Less than First Value.
- LE (or <=) - Less than or equal to First Value.
- CP (or LIKE) - Contains pattern First Value.
- BT (or BETWEEN) - Between First Value and Second Value.
- Documentation
Operator and Values
- Based on these three records:
- bob will have access to records with a:
- (restriction 0) - Code between CA and CZ, and having a Type equal to 1,
- or
- (restriction 1) - Class beginning with ERR.
- ann will have access to all records:
- (restriction 0) thanks to the ALL operator.
- The restriction defines the ‘OR’ and ‘AND’ operations:
- Restrictions of the same value are AND’ed
- Restrictions of different values are OR’ed
Based on these three records:
- MSHAW will have access to records with a:
- (restriction 0) - Code between CA and CZ, and having a Type equal to 1,
- or
- (restriction 1) - Class contains a pattern with ERR.
Structures with ‘Hierarchy’
Structures with ‘Hierarchy’:
- The entity must have a semantic usage of ‘hierarchy’
- Only external hierarchies with a single pair of parent-child columns are supported
- Not supported:
- Level-based hierarchies,
- dimensions with internal hierarchies,
- and entities with a semantic usage of Hierarchy with Directory
- Hierarchy table must have:
- A single root node with a parent value of null
- No nodes with multiple parents
- No circular relationships
Hierarchy example
- Based on these three records:
- bob will have access to: Europe, France, or Paris
- jim will have access to: France or Paris
- ann will have access to: Paris
Securing Data Access Controls With the use of ‘Spaces'
Spaces enable Data Access Controls to be secured
- ‘Permissions’ Space:
- Only users with access can edit the permissions
- ‘IT’ Space:
- Data Access Controls can’t be defined on a shared table directly, so a view is needed
- Users re-use the Permissions table (read-only) to define Data Access Control upon,
…and define the joins with the data view, which is then shared
- ‘Sales’ Space:
- Users re-use the ‘Sales’ view (read-only) which makes it impossible to avoid the enforced Data Access Controls defined on the data
- For more details see the official documentation
Eligible Users for Data Access Controls
Data Access Controls can be enjoyed by all users
- Regular application users
- These are users who interact with Datasphere directly via the User Interface or consume it via an SAP Analytics Cloud ‘live’ connection.
- These users exist in the Datasphere user directory and require authentication via the SAML Identity Provider
- Database users
- These are technical users connecting via a supported ODBC/JDBC
- These users do not exist in the external identity directory, instead, they are authenticated by Datasphere directly and no SAML authentication is used.
- An example database user is shown here. The username is ‘DATA_ACCESS_DEMO#MATTHEW’.
- Although database user support for access control is not yet documented, rest assured that it is fully supported
Data Access Controls for database users overview:
Step 1. Via Menu-Space Management-User Assignment-Database users-Create new database user
Step 2. Add the Database User Name to the Permissions table.
Shown here, ‘DATA_ACCESS_DEMO#MATTHEW’ is the database username added to the ‘Single Values permissions structure’ used earlier
Step 3. Access the view using the database user
Shown here with SAP HANA Database Explorer, we can see the database user has been restricted as expected, as defined in the permissions structure table
The ‘View_Single_Value_with_DAC’ already has a data access control defined on it as described earlier
Additional practical and best practice advice
Consider the use of virtual tables for ‘Permissions’
- Use virtual tables, instead of physical tables where necessary to reduce duplication
- However, enable replication for source tables, particularly if any source contains more than 500,000 rows (doc)
Reusing S/4 Authorisations is possible
Restrictions to restrictions!
- You can persist a view with Data Access Control set up, however, you can't persist a view consuming a view with Data Access Control set up
For detailed examples please refer to the documentation - SQL Script within the view enables additional flexibility if needed:
- Example blogs using hierarchies and wildcards, now redundant since they are supported natively
Re-using authorizations
- Importing Remote Authorization from SAP BW and BW/4HANA is supported
- (see blog post)
Bluesky
