Skip to Content

FAQ - Running the Enterprise Data Warehousing - NetWeaver 2004s BI Analysis Authorizations

If the new concept allows you to insert new authorizations into existing roles (whereby they appear under standard authorization object S_RS_AUTH), is it still possible to switch easily between old and new modes?

Yes. You can have both in one role; and only one set will be relevant depending on the chosen concept.

With the new concept, is it necessary to list every key figure in the system (except those related to sensitive salary) to ensure that people can see their data?

First of all, 0TCAKYFNM does not have to be authorization-relevant. It only needs to be marked as authorization-relevant if you want to restrict key figures.
In some InfoProviders, there are no restrictions on key figures. In this case, you just combine authorization for this InfoProvider with key figure authorization *.
For critical InfoProviders, you have to specify the authorized objects. You can do this by selecting the namespaces according to your naming conventions, such as ZHR*. The more logical the naming convention, the easier it is to maintain authorization-relevant objects.

Is there any other option – such as excluding sensitive key figures using 0TCAKYFNM rather than including ALL non-sensitive key figures (since there are thousands of these)?

As mentioned above, you can try using intervals, but exclusion is not an option.

Is there any way to enable the key figure check on specific InfoCubes only?

You can work around this by giving ALL users authorizations for 0TCAIPROV ABC, key figure *. InfoProvider ABC will then always work with all key figures. This is the only option. The best solution is to have a general reporting role to combine all those general authorizations that everyone should have.

Is access to RSECADMIN restricted overall or by tab function? Can I define authorizations but not specifically assign users? For example, now the BI team has access to RRMX, but not SU01 and PFCG (which is administered by a separate security team).

Yes. You can restrict the administrator to specific parts of RSECADMIN. They are connected to specific transactions that can be restricted using S_TCODE.
Also, it is sometimes necessary to have appropriate authorizations on S_RSEC for some of them. For more information, see the documentation of authorization object S_RSEC and the settings in SU22. This should outline all the various possibilities. Transport is restricted by transport authorizations.

Do the authorizations created in SAP BW 3.x release still work in SAP NetWeaver 7.0 BI?

Yes. The authorizations created in BW 3.x release still work in SAP NetWeaver 7.0s BI. We strongly recommend that you migrate these authorizations to the new concept ‘analysis authorizations'. BW 3.x authorizations in SAP NetWeaver 7.0 BI release are no longer supported by SAP, that is, SAP supports SAP BW 3.x concept in SAP NetWeaver 7.0 'as-is' and does not support any changes made or additionally created objects. Make sure that any new development is done only with the new concept. SAP can also not guarantee that the new features (e.g. Integrated Planning) will work with the old authorizations. In addition, only systems with relatively high SP status can be expected to work with no or with few changes in an upgraded system, since incompatible changes are sometimes necessary (such as fixes for security holes).

According to the documentation, RSEC_MIGRATION is approximately 80 % successful. Specifically, what does not work (other than customer exit variables that it mentions)?

The full list of what does not work can not currently be provided since the definition of authorization objects are quite individual. One example is not checking key figures for some InfoProviders. In the 3.x concept, this can be achieved by not including key figures in the authorization object. Migration takes existing authorization and migrates from authorization objects to analysis authorizations. Since there is no authorization for key figures, but key figures can be authorization-relevant, InfoProvider is checked. The check would fail which was not the case before.

How are two authorizations merged?

The rules for merging two authorizations are generally as follows:

  1. An empty dimension in an authorization that can be filled by the entries of the other authorization.
  2. The authorization can only be combined when at least one dimension is different (after the empty lines are filled).
  3. 0TCAKYFNM is treated as normal character (if it is authorization-relevant).

This is the general rule, but it can be improved:

  • If one of the authorizations has only asterisks in all dimensions, the second authorization can be ignored (it covers the second one). (This is already implemented.)
    This could be further improved to:
    If one authorization has only ranges and intervals, and they cover those from the second authorization, the second authorization can be ignored. (This is not yet implemented.)
  • The characters 0TCAIPROV, 0TCAACTVT, 0TCAVALID can be completely ignored since the merging is done at runtime, where the InfoCube and today's date are already known.
    However, this can sometimes be misleading. The authorization that is valid for today and for the current InfoCube is filtered out beforehand. Therefore, it is sometimes not possible to migrate global authorizations. However, when the InfoCube and date are known, this is possible. (This is used/implemented.)

If you assign authorizations directly to users (rather than through roles), is there still a similar concept to user comparison before the assignment is active?


Do the roles or authorization objects related to back-end transactions (such as RSA1) remain exactly as before? For example, is a migration required?  If it is possible to migrate from an old role to a new ‘authorization’, would it simply drop any back-end authorization objects?

For back-end authorizations, the same has to be done as without any upgrade. There are new authorization objects that need to be covered. Apart from that, nothing needs to be done. As of SAP NetWeaver 2004s, the S_RS_ICUBE and the like are no longer checked during query execution if the new analysis authorization concept is used.

Does SAP have a recommendation on how to assign the authorization-relevant object to users? (Use S_RS_AUTH in a role or assign directly to users using the central maintenance?)

There is no best way since it always depends on the customer. If it is feasible from a maintenance and monitoring point of view, working with roles for analysis authorizations is supposed to be reasonable, if standard authorizations are also maintained in roles. If the authorization concept is very detailed and hard to maintain in roles, generation of authorization using DataStore objects may be the right approach. Manual assignment can be done in either way. An advantage of roles: a complete overview of all authorization in one "tool." An advantage of maintenance in RSECADMIN: everything about analysis authorization can be seen in one transaction and maintained and changed more efficiently.

If we put the authorizations in s_rs_auth, what is the impact on system performance if users have many, for example, over 50 authorizations? What if they have 75 authorizations? Is there an impact on performance for users to have many authorizations?

Performance is not strongly influenced by the way you assign authorization to users; using S_RS_AUTH or in RSU01/RSECADMIN. However, there is an impact on performance depending on the number of authorizations. Roughly speaking, doubling the number of authorizations makes the checks four times more complex than before. This is one of the reasons why authorizations are merged/combined at the start of optimization.
This reduces the number of (more complicated) final checks of a selection versus authorization (merging also grows in the same way depending on the number of authorizations, but this is far less complex than the final checking).

From the point of composition of authorizations, the old concept does the intersection of business objects, and the new concept uses the union function. What do the intersection and union mean?

With the new concept, selections of query are checked against the union of the authorizations. With BW 3.x, the selections of query is checked against the ""intersection"" of authorization objects.
Example: one authorization grants access to cost center 1000 for year 2004, and a second authorization grants access to the same cost center 1000 for year 2005.
With the new concept, the access to query selections with cost center 1000 for year 2004 and year 2005 is granted.
With BW 3.x, if the two example authorizations are represented by two authorizations to different authorization objects, the query selection has to be in the intersection of the two authorization objects for the authorization should be granted. With the above example, access is not granted, since no selection is covered by both authorization objects.

Once an InfoObject is activated with the new concept, is it authorization-relevant? do you no longer need to activate it within an InfoCube? Is authorization therefore applied in the whole system? Is the implication of this that every user who accesses a query from an InfoCube containing that characteristic needs to have a value maintained for that analysis authorization?

Yes. That is correct. With the new concept, you can define authorizations by defining the included InfoObjects and related InfoProviders (0TCAIPROV), Activities (0TCAACTVT), and Validity (0TCAVALID) using the central transaction RSECADMIN. Instead of activating the authorization objects within an InfoCube with 3.x concept, you can now do all of these in one step using transaction RSECADMIN. The value ‘*' for 0TCAIPROV is the default while you are defining authorizations. This means that this characteristic or key figure is authorized for all InfoProviders. If you have set up naming conventions for InfoProviders, you can define the value as ‘FI*' and so on. As mentioned before, the better you set up the naming conventions, the easier it is to maintain authorization relevant objects.

Former Member

No comments