Row Level Security using BO SDK - Dynamic Group and Criteria (where clauses)

To the Universe Gurus out there:
I have a rather daunting task of implementing a Row Level Security on a number of tables within our project using BO XI R2 SP2 with SQLServer 2005. Given the nature of the requirements around this (listed below), I am going to go with BO SDK to accomplish the creation of Restrictions. That said, I need some insight into some of the problem areas I have listed below. Any help is much appreciated.
We have 11 tables that are to be restricted.
Each table is accessible to potentially 1..* group of users only.
For eg SALES is accessible to ALL_SALES members only.
Each row within each table is accessible to 1..* groups of users only. The restriction will occur on 2 columns Jurisdiction and LineID on SALES table.
For eg
1)Rows with NY Jurisdiction and LineID=123 are accessible to NY_SALES_ADMIN group only initially.
2)NY_ADMIN will then approve that the above rows be open to NY_SALES_INTERNAL group only. This approval in turn will call upon the BO SDK to add a new restriction for the group with appropriate where clause.
3)At a later point, the above rows will be opened to NY_SALES_EXTERNAL group also.
This same concept holds good a number of jurisdiction (more or less static) and a dynamic number of LineIDs. So, if 10000 rows of data corresponding to new LineID 999 and Jurisdiction AK are in the table now, they are initially accessible only to AK_SALES_ADMIN group only. No one else should be able to access it.
1) With the way I laid out the business rules above, I am ending up with 528 groups.
2) There is a restriction created for a unique combination of Jurisdiction and LineID for each table.
How can I restrict access to the new rows to one group only. I know that I can let a certain group only look at certain data but how can I restrict that all others cannot look at the same.
AK_SALES_ADMIN can look at LineID=999 and Jurisdiction='AK'.
Do I use an Everyone group based restriction? If so, my Everyone group will end up with tons of restrictions. How will they be resolved in terms of priority.
Am I even thinking of this the right way or is there a more noble way to do this?

the connectinit setting should look something like this:
declare a date; begin vpd_setup('@VARIABLE('BOUSER')'); Commit; end;
The vpd_setup procedure (in Oracle) should look like this:
CREATE OR REPLACE procedure vpd_setup (p_user varchar)IS
  DBMS_SESSION.set_vpd( 'SESSION_VALUES', 'USERID', p_user );
END vpd_setup;
Then you can retrieve the value of the context variable in your vpd functions
and set the vpd.

Similar Messages

  • How to implement row level security using external tables

    Hi All Gurus/ Masters,
    I want to implement row level security using external tables, as I'm not sure how to implement that. and I'm aware of using it by RPD level authentication.
    I can use a filter condition in my user level so that he can access his data only.
    But when i have 4 tables in external tables
    Then in which table I need to give the filter conditions..
    Pl let me know this ...

    You pull the Group into a repository variable using a session variable init block, then reference that variable in the data filters either in the LTS directly or in the security management as Filters. You reference it with the syntax VALUEOF("NQ_SESSION.Variable Name")
    Hope this helps

  • Implement row-level security using Oracleu2019s Virtual Private Databases (VPD)

    Environment: Business Objects XI R2; Oracle 10g
    Functional Requirement:
    Implement row-level security using Oracleu2019s Virtual Private Databases (VPD) technology. The restriction is that the Business Objects Universe connection should use a generic/u201Capplicationu201D database user account. This will allow the organization to avoid the situation where the Business Objects password and the Oracle password need to be kept in synch.
    What do we need from the Business Objects support team?
    1.     Review the 2 attempted solutions that we have tried to implement
    2.     Propose solutions/answers to open questions for each of the attempted solutions
    3.     Propose any alternate solution that will help us implement the Function Requirement stated above
    Attempted Solution 1: Connection String uses Oracle Proxy User
    The connection string that is specified in the Universe is the following:
    app_user = generic application user
    end_user = the oracle account of the end user which is set using arrobaVariable('BOUSER') app_user_pwd = password of the generic application user
    We have tried and implemented this in our test environment. However, we have some questions and concerns around how the connections are reused in a connection pool environment.
    Open Question for Solution 1:
    i. What happens when multiple proxy users try to connect on at the same time?  Business Objects shares the generic app_user connect string.  However, every user that logs on will have their own unique proxy user credentials.  Will there be any contention involved?  If so, what kind of errors can we expect?
    ii. If a user logs on using his credentials (proxy user), and business objects opens up a connection to the database using that user's credentials (as the proxy user but logging in through the generic app user). Then the user exits out --> based on our test today, it seems like the database connection remains open.  In that case, if another user logs on similarly with their credentials, will business objects simply assign the first users connection to that second user?  If so, then our security will not work.  Is there a way that Business Objects can somehow ensure that everytime we close a report, the connection is also terminated both at the BO and DB levels?
    iii. Our 3rd question is general high level -> How connection pooling works in general and how it is implemented in BO, i.e. how are new connections assigned, how are they recycled, how are they closed, etc.
    Attempted Solution 2: Using the ConnectInit parameter
    Reading through a couple of the Business Objects documents, it states that u201CUsing the ConnectInit parameter it is possible to send commands to the database when opening the session which can be used to set database specific parameters used for optimization.u201D
    Therefore, we tried to set the parameter in the Universe using several different options:
    ConnectInit = BEGIN SYSTEM.prc_logon('arrobaVARIABLE('BOUSER')'); COMMIT; END; ConnectInit = BEGIN DBMS_SESSION.SET_IDENTIFIER('arrobaVariable('BOUSER')'); COMMIT; END;
    Neither of the above iterations or any variation of that seemed to work. It seems that the variable is not being set or being u201Cexecutedu201D on the database.
    One of the Business Objects documents had stated that Patch ID 38, 977, 350 must be installed in our BO environments. We have verified that this patch has been applied on our system.
    Open Questions for Solution 2:
    How do we get the parameter ConnectInit to work? i.e. what is the proper syntax to enter and what other things do we need to check to get this to work.
    Note: Arroba word is being used instead of the symbol in order to avoid following error message:
    We are sorry but your message can not be posted since you have included an email address. Please remove the email address and re-post.

    the connectinit setting should look something like this:
    declare a date; begin vpd_setup('@VARIABLE('BOUSER')'); Commit; end;
    The vpd_setup procedure (in Oracle) should look like this:
    CREATE OR REPLACE procedure vpd_setup (p_user varchar)IS
      DBMS_SESSION.set_vpd( 'SESSION_VALUES', 'USERID', p_user );
    END vpd_setup;
    Then you can retrieve the value of the context variable in your vpd functions
    and set the vpd.

  • Row Level Security - using a policy function.

    I am trying to implement RLS within our database and am getting the following error message:
    ORA-28112: failed to execute policy function
    Looking around the web, these seems to point to un-handled exception in my function, but I cannot seem to find anything untoward.
    I have tested the function and can confrim that it is returning the desired predicate where appropriate..
    Here is the function..
        -- Author:  MLLOYD
        -- Purpose: Policy function that supplies a predicate to limit access to tables based
        --          on the site code
        -- Created: 30/12/2010
        -- Revision History
        -- Date            Version        Comments
        -- 30/12/2010         1           Created
        CURSOR Cur_Rls_Site IS
          SELECT s.Site_Code
          FROM   All_Users u
          INNER  JOIN Rls_Discoverer_User_Role Ur
          ON     Ur.User_Id = u.User_Id
          INNER  JOIN Rls_Discoverer_Roles r
          ON     r.Role_Id = Ur.Role_Id
          INNER  JOIN Rls_Discoverer_Role_Sites Rs
          ON     Rs.Role_Id = r.Role_Id
          INNER  JOIN Commons.t_Site_Codes s
          ON     s.Siteid = Rs.Site_Id
          WHERE  u.Username = USER;
        Rec_Rls_Site Cur_Rls_Site%ROWTYPE;
        Lcl_Predicate    VARCHAR2(2000);
        Lcl_Return_Value VARCHAR2(2000);
        Lcl_Predicate    := NULL;
        Lcl_Return_Value := NULL;
        IF Pin_Schema = USER THEN
          Lcl_Return_Value := NULL;
          OPEN Cur_Rls_Site;
            FETCH Cur_Rls_Site
              INTO Rec_Rls_Site;
            EXIT WHEN Cur_Rls_Site%NOTFOUND;
            Lcl_Predicate := Lcl_Predicate || q'(')' || Rec_Rls_Site.Site_Code ||
    q'(')' || ',';
          END LOOP;
          IF Lcl_Predicate IS NULL THEN
            Lcl_Return_Value := NULL;
            Lcl_Predicate := Rtrim(Lcl_Predicate,
            Lcl_Return_Value := 'SITE_CODE IN (' || Lcl_Predicate || ')';
          END IF;
          CLOSE Cur_Rls_Site;
        END IF;
        RETURN Lcl_Return_Value;
          IF Cur_Rls_Site%ISOPEN THEN
            CLOSE Cur_Rls_Site;
            RETURN Lcl_Return_Value;
          END IF;
      END Fnc_Rls_Control;
      -- ************************************************************************************I have applied this to a specifc table using the following:
        object_schema    => 'REPORTING',
        object_name      => 'URS_OP_VISIT_STATISTICS',
        policy_name      => 'ACCESS_POLICY',
        function_schema  => 'REPORTING',
        policy_function  => 'PKG_REPORTING.FNC_RLS_CONTROL',
        statement_types  => 'SELECT'
    END;Have I missed anything obvious?

    Policy function must have two IN paranters on varchar2 type and return varchar2 .
    So add second parametr to you function.
    Simple example
    schema_var IN VARCHAR2,
    table_var  IN VARCHAR2
    return_val VARCHAR2 (400);
    return_val := 'SALES_REP_ID = 159';
    RETURN return_val;
    END auth_orders;
    /First parametr is schema_name second parametr is object name. So you can have one universal function that on IN parameters return appropriate where condition.

  • Row-level Security Filters applied to Columns and Tables only? no Areas?

    Good day all,
    Just quick question (obiee - Is there a way to edit row-level security using Whole subject areas (instead of bringing in the individual Fact tables and applying filters by copying/pasting them).
    Follow up question - if I have nested facts in presentation layer (ones preceding with "-" - do I specifically add them to conditions, or would they be inherited by only including parent fact)?
    Message was edited by:

    I'm not sure how that would help; by using the Faculty_ID Session Variable I can identify the CRN and Term of all courses a faculty member is teaching. But I don't think that has to do with the problem I am having?

  • Dynamically creating policies for Row-level security (RLS)

    Hi everybody,
    I’m looking for suggestions on how to configure Row-level security (RLS).
    I have a large number of tables (about 500) and about 100 database users. Each user must see a portion of the data, filtered on a specific field. The field used to filter the data is a Client Id (let’s assume for simplicity that this field is present in all tables and has the same name everywhere).
    Some users must be able to see just one client, other users must be able to see a group of clients, and some other users must be able to see all the clients. The association between Users and Client Id’s is stored in separate database tables.
    I’d like to avoid having to manually create a policy for each table, so I’m looking for a solution that makes use of pl/sql programs to create policies dynamically.
    Has anybody already implemented anything similar? Can you share your approach? Of course I’m looking for the easiest / most robust / most flexible way to implement this.

    It sounds like you would want a single policy function and that you would then apply that policy function to all 500 tables (at least given the simplifying assumptions you make in your question). If your policy function simply returned the `WHERE` clause
    client_id IN (
        SELECT client_id
          FROM table_mapping_user_to_client
         WHERE user_id = <<something that identifies the current user>> )Then you would simply apply that policy to all the tables
    FOR x IN (SELECT * FROM dba_tables WHERE <<condition to find the 500 tables>>)
        'Restrict by client_id', -- name of policy
        <<owner of function above>>,
        <<name of function above>> );
    END LOOP;Justin

  • Row Level Security in OBIEE using OID as authentication Mechanism

    Hi OBIEE Gurus,
    I am trying to implement Row Level Security in OBIEE . Currently I have setup OBIEE to have OID do the user authentication.
    I want to implement RLS by doing the following :
    1. Have Security Groups defined in OID and assign users with group membership.
    2. Import these Security Groups into OBIEE metadata
    3. Apply filters to these Security Groups
    4. Run Answers requests to see if RLS works or not
    Please let me know if this approach works. If this is not the right way or most efficient way to do this, please let me know if there is any document I can follow to accomplish this.
    Appreciate your help.
    Edited by: drakesh on Sep 26, 2008 7:09 AM

    Follow the steps in the following link to set up OID and Row level security:
    Instructions for the link above:
    1.In place of Edit Data Source as database you have to select LDAP,define the groups and default initializer as filter expression.
    2.A more simpler approach ,is to create the groups explicitely using the Security Manager in BI Administrator, add filters to those groups, and assign users to those groups.
    Otherwise follow Matt's view

  • Row-level security problem using VPD

    Hi all,
    I've implemented row-level security for my application using the following procedure:
    1) Created a procedure for setting the context for the application:
    PROCEDURE set_empno
    emp_id NUMBER;
    SELECT empno
    INTO emp_id
    DBMS_SESSION.SET_CONTEXT('emp_sel_context', 'empno', emp_id);
    WHEN OTHERS THEN emp_id := 0;
    2) Created the application context:
    CREATE CONTEXT emp_sel_context USING secman.app_security_context;
    In which secman is my security schema and app_security_context is the name of above procedure package.
    3) Created a function to access the application context:
    e_predicate VARCHAR2(2000);
    e_predicate := 'empno = SYS_CONTEXT(''emp_sel_context'', ''empno'')';
    RETURN e_predicate;
    4) Created a logon trigger:
    5) Added a policy on scott.emp like this:
    dbms_rls.add_policy (
    object_schema => 'SCOTT',
    object_name => 'EMP',
    policy_name => 'EMP_SEL_POLICY',
    function_schema => 'SECMAN',
    policy_function => 'EMP_SECURITY.EMP_SEC',
    statement_types => 'SELECT',
    update_check => TRUE
    My problem is that when a user queries the EMP table the above procedure does not work and 'no rows selected' is returned for each user that queries the table. Does anybody know which part of my procedure is wrong?
    Any helps is really appreciated.

    I suggest:
    create another table emp1(logon with scott),this table only include empno,ename,then insert a few record,then modify
    procedure set_empno as
    PROCEDURE set_empno
    emp_id NUMBER;
    SELECT empno
    INTO emp_id
    DBMS_SESSION.SET_CONTEXT('emp_sel_context', 'empno', emp_id);
    WHEN OTHERS THEN emp_id := 0;
    certainly ,you should grant select on emp1 to the user who will be test.

  • Row level security without using VPD

    I am wondering if there is a way to have row level security in APEX without having to use the virtual private database (VPD). I cannot afford the Enterprise Edition license that is required for VPD.
    I need a way to customize the list of rows that appear for each user on a report page.
    For example, I only want managers to be able to see their employees and not employees of other managers.
    Thanks for your help !

    While it wont provide all the features that Oracle RLS does, you can leverage Oracle 'Contexts' to provide a form of Row Level Security.
    This article describes how
    Within APEX you can set your application to call the 'context' setting function in the 'VPD' section of the 'Edit Security Attributes' page.

  • Suggestion required for using row level security

    We have a scenario to provide row level security to some of the transaction tables like HR_EMPLOYEE which has a foreign key column DEPT_ID to HR_DEPARTMENTS table. This table may grow up to about 5 million records. There could be regular SELECT operations on this table and not so frequent UPDATES compared to the SELECT operation.
    We were looking at the following approaches...
    Table :
    1. Enable Oracle Label Security policy on this table and use static predicates.
    In this approach we add the OLS policy column (POLICY_COLUMN) and add predicate to access data.
    e.g. we will be giving access to global data by predicate like
    where C::DEPT is the OLS Label
    2. Using VPD policy. We donot add any column, instead use the existing column DEPT_ID to provide row label security. In this approach the DEPT_ID is to be compared against an additional table and DOMINATES function will be used to verify the permission for the user to access the data.
    e.g. In this approach, the policy function is like
    The GET_LABEL_FROM_DEPTID function returns the OLS label for the corresponding department. This is compared with the user's session label and appropriate rows are given access.
    Can someone suggest on which of the above approaches is more performance effective considering the number of records and the additional OLS column added to the table.

    Hi there,
    would you be able to describe as detailed as possible what you want to achieve? From my first glimpse at your code, it seems as if you are using both OLS and VPD in a rather extraordinary way.
    Best, Peter

  • Row level security in Hyperion System 9 - 9.3.1

    Hi Gurus,
    I have a requirement where the users get to see records in a table based on their localization code. This is currently implemented using views.
    The view has a set of conditions which checks the localization table with te employee table. For example, if any of the first manager, second manager etc.. localization code
    matches then they get to see records for that location.
    The RLS in Hyperion uses Groups to assign security rules. But in my case, the determination is dynamic based on the localization code. And these things change depending on employee movement, transfer, promotion etc..
    In such a scenario, can I use RLS only if I know a set Groups of users and where they belong to? Can RLS accomodate my above said requirement?

    Follow the steps in the following link to set up OID and Row level security:
    Instructions for the link above:
    1.In place of Edit Data Source as database you have to select LDAP,define the groups and default initializer as filter expression.
    2.A more simpler approach ,is to create the groups explicitely using the Security Manager in BI Administrator, add filters to those groups, and assign users to those groups.
    Otherwise follow Matt's view

  • How to implement row level security?

    Hi all,
    There is a database which is for 3 companies to use it and how to use row level security to make sure that they can only manipluate their own data? For example, "employee" table, for each company they just can see their own employees information. How to use dynamic view to do it?
    Many Thanks

    Here are two options to achieve what you want.
    A. You can do this by coding, that's if you are ready to. Are you? If yes then try the steps below:
    1. create a security codes table. Say for example
    001 - company a
    002 - company b
    2. create a security table that will list all users and which company they should have access to. You can also implement this by roles.
    3. alter all tables in the application schema to add a security code column. This will be a foreign key reference to table created in 1 above.
    4. update all data in the tables according to which company they belong to.
    5. write a procedure or package that does a validity check whenever a user requests for data. This procedure/package determines which company data the user has access/rights to.
    With this, you should be able to achieve what you want if you do not want to spend on VPD and FGAC. The problem comes where there are users who would have cross access to data from both companies. In this regard, then you have to modify your security table a little bit to handle this.
    B. This option i will admit is not so clean. You can also achieve this by two different views for every table in the application schema. And on each of these views, create a private synonym for every user. For illustration purposes:
    Table name = Employee.
    Create a view employee_a on employee
    create a view employee_b on employee
    Let's say you have users x and y. X has access to employees of company a and y has access to employees of company b. You can now create private synonyms for each of these users as follows:
    create synonym employee on employee_a in x schema.
    create synonym employee on employee_b on y schema.
    This i have not tried but believe should work.
    Hope one of these options serve your purpose.

  • Parent-child hierarcy - row level security

    Im using OBI and have a problem about row-level security in parent-child dimension.
    I have created a parent-child dimension, simlar to:
    By using a session variable 'SESVAR1', I want to restrict the visible hierarcy. For instance user 'a1.1' should only see:
    To do this I created a parent-child closure table with the whole dataset. Then I created a physical table using select statement with my session variable in repository. Whenever I viewed data in repository, it showed the correct set.
    I created a parent-child dimension, using the original parent-child closure table. But since current distance values are different from the original hierarcy, I can not managed to build a security such a security system with this method.
    How can I build a security system, that a member can only see its child hierarchy only?
    Thanks for answers and links...
    Edited by: user4516917 on 16.Nis.2012 06:54
    Edited by: user4516917 on 16.Nis.2012 06:55

    According to searches I made in and google, it seems that it is not possible to view just a branch of a parent-child tree. Because the closure table is static. Therefore, you can not change the distances of objects dynamically.
    This parent-child ability is very frustrating for me. As I understand, parent-child dimension ability can only be used in read-only sources. Any filtering or dynamic changes does not seem possible in this structure. Any changes on parent-child table requires parent-child relation table to be rebuilt.
    I couldnt find any functionality of indexcol or choose functions in parent-child dimensions. I think they can only be used in level based dimensions.
    Any comments appriciated..

  • Row level Security in obiee11g

    I am trying to implement Row Level security for some 10,000 users based on the Cost Centers which are about 30,000. I know how to implement the data level security using groups an dapplication roles and creating security filters on those groups.
    But There are two issues I am facing :
    1. The no. of cost centers are huge i.e 30,000 . So creating these many groups doesn't seem feasible. Any other approach.
    2. Cost center has got level based hierarchies having 20 levels and is a ragged hierarchy. There are some users who have access to Parent level node and there are some having access to child level cost centers. What I believed that for users having access to Parent level , I can assign all the child level cost centers and teh security will rollup to provide access to the Parent node (like you have access to California and Florida so automatically you get access to US (Cal + Flo).
    But the issue is there could be one user who will have access to the TOp level so I will have to assign all teh cost center (30,000) so that he can get access to the Total Cost Centers. There could be other Managers who will have respective Parent Cost center access leading to assigning them to say 5000 - 10000 cost centers. My fact conatins the leaf level cost centers.
    Is there a better approach to handle this.

    You can try to model your security requirement similar to Position-Based Security in OBIA .
    Check *7.5.1 Primary Position based Security*

  • Object Level Security,Data Level Security&Row level Security

    can anyone explain main difference between "Object Level Security,Data Level Security & Row Level Security " and how to implement.
    Thanks in advance,

    Hi Kumar
    Dashboards, Reports, Guided Navigation Links, Texts, briefing books are all Dashboard OBJECTS which are available at UI level of OBIEE..if you restrict them Say User 'A' wants to see 2 Dashboards and USer 'B' Wants to see 1 Dashboard....these settings & permission u r restricting in Object level called Object Level Security
    lly datalevel security is restriction of Data.. consider the same above example and User 'B" wants to see 2-3 regions data where as User A will see only Single Region Data..which you will do/restrict at logical tables, using variables..
    Row level security: refer this link, clearly explains you
    Please mark Correct or helpful if this clears

Maybe you are looking for