Column level security

Hi,
While changing PROJECT_INACCESSIBLE_COLUMN_AS_NULL to YES in NQSConfig file to implement the column level security, we get an error saying 'A general error has occurred. [nQSError: 46036] Internal Assertion: Condition m_CountFields == static_cast<int32>(m_ColumnNameVector.size()), file .\Src\SQCSCacheStorageListStream.cpp, line 221. (HY000)' while running the reports.
Can anyone help in resolving the same.
Thanks in Advance,
Durgeswari.

Don't confuse database user with application user, your
implement use specific security. You will create tables to keep
your application data dictionary. Then you can do anything you
want to. good luck.
tip Keep your application design simple as much as posible it
good for your life.

Similar Messages

Grand Total not displaying correctly on Column level security.

Hi All,
I have implemented the Column level security for three columns. But in dashboard report. The grand total is not displaying correctly. The grand total values are still displayed for the hidden columns.
Is there any work around for this.
The sample how my report looks like after column level security is.
ColumnA Metric1 Metric2 Metrics3(to be hidden)
A 100 200
B 150 100
GrandTotal 250 300 400( this includes the value of A = 300, B = 100).
Regards,
Bhavik

Any pointers please.

Column Level Security - Grand Total row

Hello All, I have a question about Column Level Security in a report where Grand Total is turned on. I am working inside of the OOTB Paint rpd and I am looking at the 'Finish Sales Trend for Current Year' report on the Brand Analysis dashboard page. Inside of the Admin Tool I added column level security on the Units presentation column in the Sales Measures table. I implemented security that will not allow the Central Region Manager group to view the Units column. When I access the report I noticed that the Grand Total row of the table is slightly skewed because the Units column is hidden. The Grand Total row is showing, however all the results are off by 1 cell.
The forum is not allowing me to attach pictures to this post.
Thanks for your help

Hi User,
It is an bug refer the metalink,
Bug.9576412 - GRAND TOTAL NOT WORKING WHEN COLUMN LEVEL SECURITY IS IMPLEMENTED
For eg:
consieder a report with following columns,
Year Product Measure1 Measure2
In this if for measure1 the column level security is enabled (user1 who is not supposed to see the data).
Then grand total value of measure2 will be in the grand total of measure1. (for user1)
When column level security is enabled, that column will be pushed to the end of the table view.
So that it is happening.
By using case statements with groups or users we can get it work without enabling the column level security.
Thanks,
Vino

Column Level Security Using VPD under oracle 11g

Hi
I am using an example from Oracle Database 10g: Advance Security -- Virtual Private Databases
1. The Application Context -- that sets the session environment for the use is ok.
2. The Logon Trigger that executes the above is ok. It had been tested.
3. The Security Policy that returns a predicate after checking the output of the Application Context is ok.
4. The security policy applied to the STOCK_TRX table is ok.
5. Select and Insert from the database work.
However, after dropping both the insert and select policy, I am having problem getting a select policy to work with column-level VPD. I will get the ORA-28104 -- input value for statement type is not valid and ORA-06512 at SYS.DBMS_RLS line 20. See code below
begin
DBMS_RLS.ADD_POLICY
('PRACTICE', 'STOCK_TRX', 'STOCK_TRX_SELECT_POLICY', 'PRACTICE', 'SECURITY_PACKAGE.STOCK_TRX_SELECT_SECURITY', 'PRICE');
end;
Note:
PRICE is the sec_relevant_cols
STOCK_TRX is the table
Can you please help.
Thx

The syntax for row level security is not the same for columns level security. All the parameters to the DBMS_RLS.ADD_Policy() function should be preceded by the type of the parameter for:
begin
DBMS_RLS.ADD_POLICy(object_schema=>PRACTICE, ... sec_relevant_cols=>'PRICE);
end;
I did not know this before. I thought they were there in the example for explanatory reasons. I decided to answer the question for myself because I know others have the same interpretation.

Oracle Virtual Private Database (VPD), Column Level Security

Hello,
About Oracle Virtual Private Database (VPD), is it possible to set a Column Level Security without setting a Row Level Security (without using any predicate)?
Thanks,
Herve.

Thanks, Zoran.
A colleague shared with me a link containing a function without returning a predicate (in using SYS_CONTEXT function to skip row restriction).
Herve.
Link

Will Performance degrade due to Column Level Security

Hi All,
I have report with 40 Columns, of which more than 20 columns are restricted to many users on the Dashboards.
This security is controlled by assigning permissions to those columns in RPD presentation Layer.
And setting the PROJECT_INACCESSIBLE_COLUMNS_AS_NULL to YES in NQSConfig.ini
Will the performance of reports degrade due to this type of design.
Is there any solid evidence?
Thanks
Kaushik

Hi,
I dont see any performance hinderance because of the column level security.
But remember in the pivot table you can still see the column without values. And its a bug. Would serve good for table views.
Hope this helped/ answered
Regards
MuRam

Can't find column level security in BO 3.1

I am trying to implement column level security in Web Intelligence in Business Objects 3.1.
After studying articles on google I found that it can be achieved using Business Security Profile but when I searched I couldn't find any such profile or setting in BO 3.1.
Can anyone please guide me in correct direction on how to achieve the same in BO 3.1
Please also let me know the will there be any compatibility issues as Development environment is in BO 3.1 and Production environemt is BO 4.0.
Thanks for your time
Siva

Hi Siva,
You can use "Manage Access Restriction" option to acheive column level security in Business Objects 3.1 universe.
See below document for more detail-
Implying Security on Business Object XI 3.1 Universe having SAP BW as Source
~Anuj

Tab level and column level security

Hi
Can anyone suggest a high level view of implementing a tab level security based on the user logged on? I have a form that has multiple tabs and within each of these tabs there are multiple fields displayed (in a multi record block). Based on the user, the relevant canvas tabs should be enabled and only those fields within each of these tabs to which the user is authorized to view should be displayed. I am looking for an approach methodology that can be implemented dynamically. There could be another form to maintain the user, roles and accessibility options.
Any suggestions are welcome.
Thanks

When the form loads, capture the username (network login ID).
Based on this username, in you when-new-form-instance trigger or when timer expired trigger(you have to create a timer for this), set the property that certain tabs/fields must be enabled/disabled depending on the user.
Say, you have two groups of users, admins and non-admins..
when the form loads, capture the username
compare this username with the tabular data to determine if that user is an admin or non-admin (you can do this using a select query)..
and using when-no-data-found exception you may set the appropriate previleges using set_tab_property('tab_name',ENABLED,property_true) and hence forth
hope this helps

Using Session Variable in the Column Level Security

My Question -
1. I created an initialization block with initialization string by calling a new session variable CTP_ID_LIST in the sql command, given appropriate database connections and when I exit out of Block, and chosen Row-wise initialization. I do not see a new session variable created under variables list. Why does this happen? Please help me on this.

Hi,
This happens when you select Row-wise Initialization.
The row-wise initialization feature allows you to create session variables dynamically and set their values when a session begins. The names and values of the session variables reside in an external database that you access through a connection pool. The variables receive their values from the initialization string that you type in the Initialization Block dialog box.
You can also use the row-wise initialization feature to initialize a variable with a list of values. You can then use the SQL IN operator to test for values in a specified list.
Example: Using the table values in the previous example, you would type the following SQL statement for the initialization string:
select 'LIST_OF_USERS', USERID
from RW_SESSION_VARS
where NAME='STATUS' and VALUE='FULL-TIME'
This SQL statement populates the variable LIST_OF_USERS with a list, separated by colons, of the values JOHN and JANE; for example, JOHN:JANE. You can then use this variable in a filter, as shown in the following WHERE clause:
where TABLE.USER_NAME = valueof(NQ_SESSION.LIST_OF_USERS)
The variable LIST_OF_USERS contains a list of values, that is, one or more values. This logical WHERE clause expands into a physical IN clause, as shown in the following statement:
where TABLE.USER_NAME in ('JOHN', 'JANE')
Regards
MuRam

Column level versus row level security in SAP BI

This is a question. Sorry about the terminology clarification but it really does get to a question. Thanks for your patience and help.
There is some confusing terminology among BI users so let me explain terms. The terms appear to have some currency in the BOBJ world.
Row level security = the ability to control access to some data based on the values of a characteristic. Only the data authorized will be selected.
Column level security = the ability to exclude certain characteristics from display by any user.
In SAP BI row level security is managed by analysis authorizations (RSECADMIN).
To the extent of my experience (and I am unable to test it for about a month) column level security can only be managed by authorization object S_RS_IOBJ excluding the infoobject to be controlled with the sub-object DATA).
However my experience is that any query that reads an infoprovider that contains that infoobject will fail. It won't exclude and present to the user all the other infoobjects (i.e. columns).
Is this really so and if so is there any mechanism that can exclude columns without forcing the developer to either design an infoprovider or multicube that excludes the infoobject?
Edited by: Corwin Slack on Dec 14, 2009 2:07 PM

Two things
1. I would prefer not to have to rely on developers to implement a restriction in a query. Then I have to police every query.
2. I am not certain that the authorization isn't checked anyway because the query accesses the cube. (Sorry no test environment available until mid January)
My preference is that any queries that contain this authorization object just bypass the displaying the characteristic. My frecollection to date is that this isn't what happens. The query fails entirely.

Row and Column Level Select Permission

Hello Friends,
I am using Oracle Oracle9i Enterprise Edition Release 9.2.0.1.0 and Windows XP. I have two questions. How to set :
1. Row Level Select Permission?
2.Column Level Select Permission?
1. I have a table having 100 records in it. I don’t want to allow all the user to see them; means, if user1, user2 and user3 are going to select * from mytable then only they can get all the rows; while other users (including sys) should not able to get all rows, they should be capable of from 11th record.
Though it can be managed by using another table, but I am just finding the other solution.
2. Likewise, if I don’t want to allow to fetch all the columns; suppose column4 is having confidential info and only be visible by user1,user2 and user3 only, not by any othr user; what should I do?
Please guide and help me.
Regards

You would need to use Virtual Private Database (VPD)/ row level security (RLS) to apply row-level security policies to the table. The DBMS_RLS package is used for this
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_rls.htm#sthref6168
Unfortunately, column-level security wasn't available in 9.2. You would need to upgrade to Oracle 10g to get that functionality. Before that, you would have to create views that selected appropriate subsets of columns and grant permissions on those views to different users.
Justin

Row Level Security (VPD)

We are enhancing our corporate security model using VPD fine grain access to allow more flexible policies. This will provide different levels of row level access on each set of mart fact tables (Health Board level access on Mart A, GP Practice level on Mart B etc). We also want different column level security (masking) on common dimensions depending on which mart is being queried, e.g. a user might be allowed to see confidential patient columns when querying Mart A, but not on Mart B.
OID groups hold user attributes, and we can retrieve these via logon trigger and policy functions and then set user contexts accordingly.
When a query is submitted to the database (via Business Objects), it triggers the policy function on a particular mart fact table(s), which applies the particular row level constraint based upon the users context. So far so good. Problem is, when any dimension policy functions are being triggered (at the same time), they need to know which particular Mart is being queried, so that they can retrieve the correct user context to apply either confidential or non-confidential column masking.
I basically need a means of interrogating the SQL before (or as) it reaches the dimension policy functions, from which the function can identify the Mart from the named tables in the SQL FROM list. Is there a way of doing this, or some other mechanism entirely for delivering this level of access control?
One solution is to have a separate dimension view specific to each Mart. A particular view would join to a particular mart (in Business Objects), and the policy function amended for each. However we would rather avoid this as it could mean up to 20 + views for each dimension, and require a substantial maintenance overhead.
Thanks
Simon
Edinburgh

Why would you want a situation where USER1 cannot see any of the data in the table but owns a procedure that allows him to update any row in the table? That would basically defeat the purpose of using VPD-- if USER1 can circumvent the VPD policy in this procedure, USER1 can circumvent the policy in any procedure and can create procedures that allow him to view and manipulate the data.
Can you provide a bit more background about what problem you're trying to solve? Why does USER1 need to own the procedure if USER1 isn't allowed to see any of the data? Are you trying to write a procedure that will apply the caller's VPD policy (i.e. when USER2 calls the procedure, he can only update the rows that his VPD policy allows him to see)? Or do you want the procedure code to bypass the VPD policy entirely? Why are you fine with granting USER2 the ability to bypass the VPD policy but you are not OK granting USER1 that same privilege?
Justin

Data Level Security OBIEE,PLEASE HELP

How can we implement data level security in OBIEE. For example, a Sales officer should only see data for his customers, similarly a Sales Manager should only be able to see data for Sales Officers working under him....
any help would be appreciated

Hi there are many blogs on data level security..
understand the concepts and try to implement, if you stuck up anywhere will help you out..
http://obieeblog.wordpress.com/2009/01/15/obiee-data-security-column-level-security/
Data level security in OBIEE

VPD Update policy at column level

Hi,
I have a table abc and I have applied a policy for update. Now the user who has no access is unable to update the table abc. Can I just restrict the user from updating a specific column ( user_id column in the table abc), rather than restricting the user from updating all columns?
Thanks.

hi,
You can use sec_relevant_cols parameter of the DBMS_RLS.ADD_POLICY procedure
begin
dbms_rls.add_policy (
object_schema => 'SCOTT',
object_name => 'EMP',
policy_name => 'VPD_TEST_POLICY',
function_schema => 'SCOTT',
policy_function => 'TEST_VPD',
statement_types => 'select, insert, update, delete',
sec_relevant_cols => 'sal,comm');
end;
you can see this doc
http://www.in-oracle.com/Oracle-DBA/DBA-I/vpd-virtual-private-database.php
or
You can also use views to enforce column-level security, showing only which columns in a table may be updated. For example, assume that you must design roles based a table where only managers may view or update the salary column of the employee table (column restriction).
1 - You can grant the end-user access to only those columns you wish to update:
grant update (col1, col2) on mytab to fred;
2 - You might create a view with only those columns that you want to allow updates, the table appears to the end-user as-if it contains only those columns. By granting access only to that view (and not the base table), you can effectively implement column-level security and restrict which columns in a table may be changed.
regards,
Edited by: dataseven on 04.Eki.2012 23:22

Column masking row level security in Peoplesoft Databases

Hi
How about the credibility of using VPD( for column masking,row level security) in People soft Databases?where the sensitive data is redundant across 100's of tables.
My intention is to use the VPD across all the tables that contain the sensitive data ( ssn,bank accno, etc)
Appreciate your help.
Chelli

Hi.
I also have a trouble like yours,but mine is more simple.
I'd tried to solve,and find that it's really hard and must lost a lot of time to solve,because some table have 2,3 or more derive information that to use VPD is not easy.
Can i ask for any aspect to solve problem like this.
Thanks for any answer and support.
Thinhbk.

Column level security

Similar Messages

Maybe you are looking for