4 Replies Latest reply on Mar 15, 2011 1:23 PM by . Anuska

    What is the best strategy for row-level security?

    Ian Turner

      Hi,

       

      I'm new to Tableau having only discovered it in the past couple of weeks, but already looking to use it as part of multi-tenant product that we run.

       

      We'll be using Tableau Server with embedded views and trusted authentication, which I've successfully prototyped. We'll also be looking at providing some of our clients' power users with the Desktop product so they can create and publish their own views.

       

      As it's a multi-tenant system the delineation between each client's data has to be be really robust, so I'm thinking that row-level security at the DB is probably the only prudent way forward.

       

      We don't use AD so the Server is running with Local Authentication. We will typically offer each of our clients (let's say we have 20 for now) a 'starter pack' of two or three standard workbooks.

       

      In an ideal work we would just create the workbooks once, and then let Tableau Server work out which user is logged in, look up the correct db credentials in some kind of secure credential store, connect to the db and serve up the row-level secured view accordingly.

       

      Now, I'm pretty sure that that's not possible yet. So, the other end of the spectrum is that I publish 20 data sources with appropriate credentials, 20 copy/pasted workbooks, 20 client-specific projects, and tie-down all the permissions so that each client can only see what they are allowed to see. All possible, but quite a bit of an administrative headache.

       

      I'm hoping that someone will be able to tell me that a middle way exists!

       

      By the way, I did briefly think that User Filters might be an alternative to Row-Level security, but then realised that they can just be turned off by a power-user. So that's not an option.

       

      Can anyone offer some sage words of experience on this topic? Would be much obliged.

       

      Cheers

      Ian

        • 1. Re: What is the best strategy for row-level security?
          Allen Spurgeon

          We manage this by using an Identifier column on the reporting tables and a list of all Users with access to Tableau. A view creates a "mapping" of the Users to the correct Identifier value(s) and this is inner joined with the reporting tables in the report data source. A filter on each report is created looking for the "True" condition of where the logged in user name matches the user name in the User list view which will only return the records that a specific user can view.

          • 2. Re: What is the best strategy for row-level security?
            . Anuska

            Allen - I am very curious as to how applying row level security affected dashbords performance? What is the size of your reporting tables? I found this approach very inefficient when the reporting tables size is big (more than 1 mln rows) and security is applied to various attributes (a user can have access to one or many categories for instance). The extract file size has swollen up to more than 2 mln rows when I used only 2 users and 3 categories...have you experienced issues like that?

            • 3. Re: What is the best strategy for row-level security?
              guest contributor

              When our user mapping view is joined to our reporting tables the result set is 40M+ rows and that would be filtered down based on the name of the specific user to around a possible 400K rows being return to a report, we still get good performance.

               

              What data types are you joining/filtering on?

              • 4. Re: What is the best strategy for row-level security?
                . Anuska

                The fields I join on are integers. The data was filltered correctly to about 1.3 mln rows, but it took about 60 seconds for the dashboards to be rendered in Tableau. The reporting table has primary key on the recid and non-clustered index on the categoryid, it is joined with usercategory table (on categoryid column)..i still find it very slow...