Q and A


SAP NetWeaver BW Experts Richard Hunt & Tom Venables on protecting SAP NetWeaver BW reports (transcript)

by Allison Martin

I recently moderated a web forum with data security experts Richard Hunt and Tom Venables on the authorizations strategies introduced in BW 7.0 and the challenges of coordinating security between BW and ERP systems.

For the full Q&A, you can view the questions from Insider Learning Network members and Richard and Tom’s responses in the BI Forum, or read excerpts from the transcript of the Q&A, below.

Protecting SAP NetWeaver BW reports:

An exclusive Q&A today with data security experts Richard Hunt and Tom Venables on authorization strategies in BW 7.0.

Allison Martin (Moderator):

Welcome to today’s forum on protecting your BW reports. Thanks to everyone for joining us, and thanks for taking these questions Richard and Tom.

For those who have not yet registered for the Q&A, click here to receive an exclusive download of Richard Hunt’s presentation on BW authorizations from GRC 2012. “What Every SAP Customer Now Needs to Know About Analysis Authorizations, a New Security Concept Within SAP NetWeaver Business Warehouse 7.0.” previously only available to conference attendees, includes guidance on planning for BW 7.0 and the new authorization approach, plus detailed steps for configuring analysis authorizations.

We have a few questions already posted, so Richard and Tom will be responding to these shortly.

Malini Rao:

Hi - What is the role design strategy for BI 7.0 Security including analysis authorization? And what is the best recommended approach?


Tom Venables:

Hi there - you need to work with your datamodel team to ensure that
the structure of the data reflects items you need to secure as per your ERP authorizations design. You can then structure roles and analysis authorizations to reference this model. An example would be to keep all data-privacy relevant information in a separate infoarea, on which you can authorize in both the roles and analysis authorizations

Always try and keep the solution as simple as possible - remember
that any characteristics you define as authorization relevant will be active
across the whole landscape.

In terms of the assignment of analysis authorizations, it
is recommended to assign these via the roles themselves, not only will this
simplify administration, but also will allow for ease of reporting on
authorizations, especially if GRC is implemented on the BW system.


Karen Mattheessens:

What are the (dis)advantages of assigning analysis authorizations through a PFCG role compared to direct assignment via transaction RSE CADMIN?

Tom Venables:

Hi there - assignment of analysis authorizations via the roles, rather than directly to the user IDs allows for a much more integrated approach to the authorizations within BW. Because the access to data within reports as controlled by the analysis authorizations must be coupled with profile-based authorization to elements of the datamodel, this approach simplifies these assignments greatly.

Other advantages are where CUA is implemented, to allow the automated assignment of analysis authorizations where the BW role is included for a user, as well as easier of reporting on authorizations, especially if GRC is implemented on the BW system.


Robert Moore:

Hi - I have below questions.

1. What are design practices (best practices) for implementing analysis authorizations and what are pros and cons over each other?

2. Is there any standard format that can act as technical spec document while implementing analysis authorization?


Richard Hunt:

Hi Robert - some answers below:

1. What are design practices (best practices) for implementing analysis authorizations and what are pros and cons over each other?

This is a very broad question. I personally don’t like the term ‘best’ practice too much but I would say that there are few ‘good practices’ and in my view the most important of these are as follows:

- Don’t extract sensitive data in the first place if you can avoid it. BW is probably not the most appropriate place to hold data privacy or commercially sensitive data.

- Assign your analysis authorizations via a PFCG role. I really can’t see any downside to this.

- Engage with your BW configuration team and architects to ensure that you understand the data model. A good BW security design will reflect a combination of the display access users have in ECC, the business’ reporting requirements, legislative/compliance issues and the BW data model itself.

- Try to avoid using the migration tool unless your BW 3.x solution is very straight forwards.

- Use a consistent pattern in your analysis authorizations.

In the slides you’ll also find some thoughts on three different ways to design your analysis authorizations together with some thoughts on the pros and cons of each:

1. InfoProvider-Based Solution

A data model with logically defined InfoProviders centered around the restrictions you wish to achieve might work better with an InfoProvider-based security design.

2. Characteristic-Based Solution

A data model using a “single version of the truth” with reporting based on a small number of InfoProviders may be suited to a characteristic-based security design.

 3. Report Name-Based Solution

A solution using a very tight naming convention may which suit a security solution based around the report name.

2. Is there any standard format that can act as technical spec document while implementing analysis authorization?

- There’s nothing available as standard but you should be able to re-use a tech spec from a custom authorization object as a starting point for this. Alternatively you could adapt the tech spec from one of your PFCG roles in ECC.

Beauregard Pascal:

Hi - Why would an enterprise would use the strategy to assign ??analysis authorization directly to a user ID rather use PFCG role?

If the enterprise decided to manage the ??analysis authorization directly to a user ID, could it use the CUA (central user administration) to manage the access or is the access managed only directly in BW?

Tom Venables:

Hi there - I have not seen any great advantages to assign analysis authorizations directly to the users, rather than via roles. Because the profile-based authorizations to the datamodel must exist in conjunction with the analysis authorizations to the data within the reports, keeping them separated can result in complexity and increased manual user administration.

As for using CUA to assign analysis authorizations directly to users, I have not seen this operating effectively. In most clients, the CUA parent system is set up on an ERP or solution manager system and the RSECADMIN transaction is not included in these. Use of roles to assign analysis authorizations allows CUA to manage this aspect of the authorizations solution. Hope this helps.

Ravikanth Gadicheri:

Hi - What is the best approach if we have to setup the authorization/security at the Sales employee (end user) level where the user can only see his transactions or sales data? (for e.g. no. of users: 1500) Regards, RK.

Richard Hunt:

Hi There - This one is difficult and I am not sure if there's an easy way to achieve an 'elegant' solution with standard analysis authorizations.

My suggestion would be that you ensure that the (Sales) userID is stored as an authorization relevant characteristic against the sales data. You might want to make the sales userID distinct from standard userID somehow (e.g. with a prefix) as otherwise you'll have an auth error every time userID is found on the infoprovider (or you'll have to give the access back somehow.)

The problem you then have is how to give the individual access to their own userID. Here you I think have two options:

1. Create an analysis authorization for each userID and assign it to the user, either manually or via some sort of (custom) automated assignment.

2. Create an analysis authorization that uses a variable for the (Sales) userID which is then populated automatically with the users' own ID (plus the prefix if used.) This would require some customization in the istep customer exit. Hope that helps.

Victor Perez:

The migration process is user and not role based. Since the user master data is not the same across the landscape, Dev, QA and Prod environments; should the process be run and thus the analysis authorizations created in the Production system? Thanks!

Richard Hunt:

Hi Victor - the transport system in BW is very similar to that used in ECC. You can transport Analysis Authorizations and I would treat the path to production in exactly the same way as you do for ECC roles, e.g. Create in Dev, Test in QA, transport to Prod and assign. Hope that helps.

Jaya Prakashchapara:

Hi - What is the best solution to setup complex authorization for the below scenario...

We have two analysis authorization objects in a role.

Each has two infoobjects defined. Compcode and Govt/Non-Govt indicator

If a person has govt access to one company code and non govt access to another company code, this role is giving govt and novt to both company codes.


Can you tell us why and can you please suggest a solution for this?

Richard Hunt:

Hi JP - from what you have described and assuming that you have two SEPARATE analysis authorizations I would not expect them to be giving access to each other.

Two things to check:

1. The user does not have 0BI_ALL or another wide access analysis authorization assigned (either directly or via a PFCG role). I know this may seem obvious but it's important to double check.

2. If the issue still persists then use the trace facility (which is significantly better than ST01) to establish how the user is getting access to both company codes.

Hope that helps a little - unfortunately I can't really be more definitive without seeing your system.


Kiran Talluri:

Can we secure Universes for Business Objects Universe designers? I want to find out if we can secure Universes across different developers.

Tom Venables:

It is certainly possible to secure universes within the Central Management Console. For each object within the console, be it a universe, folder, report etc, you can assign users' access to them with a right-click. It is recommended to create access levels as containers for the types of authorizations you would like your groups of users to have, in order to minimize the amount of manual assignment you have to perform.

In this way you can assign a "designer" access level to each user or user group (which can be imported from the BW roles) for specific universes and control who can maintain, vs. who has display-only access (or none).

Maria Menendez:

Hi Tom - what would you review from controls perspective in a recent BW 7.0 implementation? Thanks.

Tom Venables:

Hi there - Depending on the sensitivity of your data in the BW system (which may require data privacy reviews) most controls reviews in BW focus on the ability to administer the system. The ability to maintain extractors, to change the datamodel, maintain authorizations and standard BASIS functions such as client maintenance represent similar risks to system integrity as you would expect in an ERP system.

SoD ris ks tend not to be highlighted in reporting systems, but consequently sensitive access receives slightly more attention, especially when GRC RAR is implemented. Hope this is helpful

Robert Moore:

Hi - Here is a scenario where in access is primarily restricted on company code and still there are managers who requires reports based on say for product groups irrespective of company codes.

What would you suggest in terms of design that will solve this scenario?

Richard Hunt:

Hi Robert - Whilst it's preferable to reflect the user's access in the ECC system with their reporting access this is not always going to meet the requirements of the business. Therefore you could open up company code in BW and restrict on Product code instead IF that's what the business want and they understand the security implications.

The other thing to consider is using your data model to ensure that non-sensitive data that can be shared cross company code is held on a separate infoprovider(s) to the data that needs to be restricted by company code. You can then use your analysis authorizations to apply different restrictions to each infoprovider based on the sensitivity of the data. Hope that helps. Regards.

Malini Rao:

Hi Tom - I would like to know what the strategy for setting up Hierarchy Authorizations is. What would be the correct approach of setting up Hierarchy authorizations? In which scenario should we decide to Implement Hierarchy Authorizations? Thanks & Regards

Tom Venables:

Hi Malini - the hierarchy option exists to give us the flexibility to recreate hierarchy authorizations that exist in the source systems, so we use them in scenarios where a hierarchy must be replicated, one of the best examples of this is the organization hierarchy within SAP HCM. Because the structural authorizations in HR refer to nodes in t he hierarchy we can replicate this in BW.

Another example of the use of hierarchies is when authorizing on the datamodel, it is possible to include info areas in the hierarchy, rather than specific infoproviders when maintaining the standard authorization relevant characteristic.

These are created in the second tab when defining the analysis authorization and we define the behavior of the authorization (whether it applies to just the selected node or to a sub-tree etc.). General rule of thumb is to try and replicate the appropriate restrictions from the source system. Hope this helps


Jay Hirun:

Hello - Is there a con for having a composite role in BI? Let's say, 1 role for analysis authorization and 1 for query/report with S_RS_COMP and S_RS_COMP1

Richard Hunt:

Hi Jay - my personal opinion is that there's always a con for having a composite role!

I don't like them much as they create an extra layer of complexity that often makes roles more difficult for the business to understand and analysis more difficult than it needs to be. This is a personal opinion though and there are certainly circumstances when composite roles are a useful tool, arguably they are even essential in CUA.

What I would definitely say is that you shouldn't create composite roles unless you need to. Therefore, in you particular scenario I would definitely just add both your S_RS_COMP and S_RS_COMP1 authorizations to the same role.

Maria Mendez:

Hi – how would you achieve a segregation for privacy by region? And by frb? Would you still use pfcg? Thanks.

Richard Hunt:

Hi Maria - my first comment here would be that if the data is Data Privacy sensitive you should cons ider excluding it from the BW extraction in the first place. You should be able to meet the user's reporting requirements directly in ECC.

If you do still need to extract the data then the solution will depend on how your enterprise structure is configured.

Assuming you are talking about an HCM system (?) you would normally see Personnel Area used as a location based characteristic. This can therefore be used to determine which country the data relates to. By making Personnel Area authorization relevant you can achieve a country based restriction.

Either way I would always use PFCG to assign your Analysis Authorizations to users.


Allison Martin (Moderator):

Thanks to all who posted questions and followed the discussion!

A full summary of all the questions will be available here in the BI Forum and the Compliance Group and the BI/BW Group on Insider Learning Network. I encourage you to join these groups for ongoing information and additional resources, including a recent podcast with Richard Hunt on this topic. And of course, I invite you to our annual GRC 2012 conference. The US conference is already scheduled for Las Vegas, March 13-16, 2012. 

And finally, thank you to Richard Hunt and Tom Venables of Turnkey Consulting for taking the time to respond to these questions


Tom Venables:

Thanks to everyone for your questions, I hope the answers have been helpful - Tom

Richard Hunt:

Thank you for all your questions. I hope our answers were of some use and wish you all luck with your BW security implementations Best Regards - Richard

Malini Rao:

Thanks a lot Tom & Richard! Your responses have been really helpful. Thanks Allison for facilitating this. Best Regards - Malini Rao.












An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!