_SYS_BIC; WHAT TO GRANT INSTEAD?

[Former Member]

Hi

_SYS_BIC holds all the Columns Views of activated objects. _SYS_BI holds some tables for created Variables, Content Mapping, Time Data Schema Mapping. I have a situation where Data Preview over contents of a specific package (attribute and analytic views) would be possible if I grant my user SELECT privilege over _SYS_BIC and _SYS_BI.

I do not want to do so as he can do data preview on all the packages, therefore I am wondering what would be the alternative.

Tx

Reza

[former_member184768]

Hi Reza,

The users you mentioned, are these application users or developers. Data preview or HANA Studio is for the development team. Your actual end users may be looking at the data from the front end reporting tool like WebI / BO toolset which can also implement the data security concept.

Secondly you can restrict the access on the underlying tables on which HANA Information models (Analytic view / Calc view) has been built.

You also need to consider that during the HANA Information model creation if you have selected "Definers right (SYS_REPO User)" or "Invokers right".

So there are multiple ways by which the data access can be restricted. I'd suggest it to implement at the database table level becuase it is not necessary to access the data ONLY through the Information models (Analytic / Attribute / Calc view), somebody can even fire a SELECT statement on the underlying table to see the data.

Regards,

Ravi

[Former Member]

Hi Ravi

Thanks for your reply.

User is developer/tester. Access to tables has already been granted through SELECT privilege over the schema and we have no issues with that. However the user needs to play around with those 3 tabs in Data Preview option (Analysis, Distinct Values and Raw Data) over the already-activated views.

As a matter of fact I had uploaded another question prior to this which explains more on the issue we have been facing:

http://scn.sap.com/thread/3296621

Tx

Reza

[former_member184768]

Hi Reza,

Frankly I did not understand the logic behind this requirement, as even if you manage to restrict the user to access the data from the Information model views from a specific package, the user can still fire select statements on the underlying tables. So the data can still be accessed by alternate methods.

You can restrict the users on specific packages only so that I cannot open the objects from other packages and hence will not be able to perform the data preview.

Kindly note that data preview is just a utility which fires the select statement on the Column views created by Information models. The data still remains in the tables which can be accessed directly.

Regards,

Ravi

[Former Member]

Hi Ravi

Sorry if my explanation was not clear enough, here is a sample situation:

We have package A created out of schema A and we have schema B (and therefore package B). The contents of tables in schema B are confidential. Hence the views created for tables in package B are also confidential. Now a developer needs to go through the views in package A (including Data Preview and its 3 tabs) however he should not see views of B. He has access to schema A and is able to list the contents of package A too. However he cannot use the function of Data Preview when he chooses a view in package A.

A quick fix is to grant him SELECT over _SYS_BIC and _SYS_BI however by doing so he can also gain access and see (somehow!) the run-time objects of package B (although we have not given him access over schema B or package B, but we do not intend to leave any back-door open).

Let me know of your thoughts on this, can this to be tackled through analytic privileges?

Tx

Reza

[rama_shankar3]

Reza,

Based on your scenario, you need to only provide authorizations at the package level.

  One more thing, for the developer provide full access to both the packages. When the solution is built work with the admin folks to create two test IDs for your scenario i.e: usertestpkga and usertestpkgb with appropriate authorizations and then let the deveoper test the solution using the test ids.

Hope this helps.

Regards,

Rama

[Former Member]

Hi all,

is there any update to this issue?

I have a similar problem as Reza: we have separate packages where users should not see the content of other packages. I would be able to separatly assign select permissions on the generated views in _SYS_BIC, but this would be a manual step for every single create view.

Otherwise users are able to execute "Open Join Viewer" successfully and hence get some knowledge about views in other packages. Furthermore, some knowledge about existing views in other packages can be infered as the names can be seen. I.e., for using the views this is fine, but for granting someone the permission to create and test views I have a problem.

Any help would be appreciated!