3 Replies Latest reply on Jul 20, 2016 2:23 PM by Ruthie Petty

    RLS solution - vendor conflict over user tables v Groups

    Ruthie Petty

      Hi Tableau Admins. We're in conflict with a vendor, who is resisting our contractual agreement to apply a security model to Tableau workbooks, published on our Tableau server. I would greatly appreciate your thoughts if you have experience with (or ammunition for) the scenario described below. Logical, analytical arguments have not proved very helpful, but volume of argument may help.

       

      We are in the healthcare industry, and need to use row level security (RLS) on dashboards according to a user's role on up to 3 levels. Think of it as organization filter > clinic filter > provider filter. Our users will also mostly be external, so this is happening via Okta/SAML. We are contracting with the vendor for both a data warehouse and Tableau applications, building both at the same time.

       

      WE WANT TO

      Join SQL user tables to SQL data sources in Tableau and apply row level security using calculated fields. These are narrow and deep user tables, containing Tableau usernames and NPIs (healthcare identifier codes that will join to the data source) that we prepare separately, and will be automating. The best solution seems to me to place the user tables directly in the SQL database where the data sources reside. For some reason, still very unclear, they do not want to do that--although, I'm not sure what they might do, since we're hosting the server/s (both Tableau and data warehouse).

       

      THEY SUGGEST

      Their latest suggestion is for the Tableau Admin to set security "manually" in the Tableau Admin Console--this could only mean Groups. We would need to maintain a starting group of about 150 users in over 20,000 Groups to use ISMEMBEROF in calculated fields. $#@!*   The Tableau Server instructor said this was a bad idea last March, when I went for training, but the vendor is not listening to us.

       

      The vendor also thought we could wait for Tableau 10 and use cross-database joins (CDJ). I do not want to commit to that approach because it will not be ready in time for us to test and approve our sharing model (which is part of the contract). I've also read about performance concerns with CDJ, and that they may or may not work with extracts (apparently part of current beta 3 testing). While greatly anticipating Tableau 10, I bristle at vendors (who have much less skill w/Tableau than they indicated) dictating to us when we update versions.

       

      Another option is to use custom SQL to pull the user tables from another database and I have done this for a workaround in testing. I don't favor this approach as it doesn't seem to be best practice and we do have full access to our data sources.

       

      I appreciate your advice or insights. The sad part is that we're actually coming up with a great security solution, that we had contracted with them to be a part of. They're missing an excellent opportunity to grow their skill in Tableau and healthcare. We're currently on 9.3.

        • 1. Re: RLS solution - vendor conflict over user tables v Groups
          Toby Erkson

          Given your side of the story I agree with you.  As for their suggestion, throw it out, it's not an option nor open for discussion.  20K+ Groups?  Obviously they are clueless, what a nightmare that would be!

           

          If your option to use Custom SQL works then fine but plan on v10 testing once it becomes public.  You're very much correct not to commit to it at this time!  And I agree with you that less-Tableau-educated vendors shouldn't dictate when you do updates.

           

          Ruthie Petty wrote:

           

          ...

          We are in the healthcare industry, and need to use row level security (RLS) on dashboards according to a user's role on up to 3 levels. Think of it as organization filter > clinic filter > provider filter. Our users will also mostly be external, so this is happening via Okta/SAML. We are contracting with the vendor for both a data warehouse and Tableau applications, building both at the same time.

           

          WE WANT TO

          Join SQL user tables to SQL data sources in Tableau and apply row level security using calculated fields. These are narrow and deep user tables, containing Tableau usernames and NPIs (healthcare identifier codes that will join to the data source) that we prepare separately, and will be automating. The best solution seems to me to place the user tables directly in the SQL database where the data sources reside. For some reason, still very unclear, they do not want to do that--although, I'm not sure what they might do, since we're hosting the server/s (both Tableau and data warehouse).

           

          ...

          If I were you I would want to know exactly why they do not want to do that.  Maybe it's due to a health care legality?  If they don't have a valid reason and yours is clearly superior then they shouldn't be complaining, I mean, you are the expert which is one of the reasons why they hired you (the company you work for), right?  I'm sure you can relate to this (the concept, not necessarily the focus as a Desktop developer):  The best post ever about the data visualizationist's role!

          1 of 1 people found this helpful
          • 2. Re: RLS solution - vendor conflict over user tables v Groups
            Russell Christopher

            +1 on Toby's response.

             

            Unless you're getting paid by the hour (I kid! I kid! Joke!), there's no way you want to be manually managing that many users/groups in the portal. It'll be cumbersome and error prone. This is the sort of stuff you typically don't want human hands touching.

             

            As Toby mentioned, you really need to understand WHY they don't like your ideas and want to do the manual approach. On the face of things, it makes no sense - but maybe they're dealing with a very odd scenario they're not telling you about.

             

            The one thing that is really confusing to me is that they're objecting to a very standard design pattern to do RLS, yet they're willing to talk about using cross-database joins - which is essentially the same idea except with more moving parts. This makes no sense and makes me think there's still something you (or they) don't understand.

             

            In the short term, federated queries (cross database joins)  probably won't help you. A few months ago I did some "I wonder if" RLS-focused testing on this myself and found that the cross database join was much slower than "plan jane" join against a reasonably sized (5M+ rows) dataset.

             

            The reason for this is that in 10.0 we don't push down the (small set of ) join keys (representing the user we're dealing with) to the other datasource to  "pre-filter" the rows it returns...ALL the rows get pulled down and then we filter after the "joined" extract gets created. This'll change / be improved in the future (don't ask me when, I don't know), but in the short term it makes  cross-database joins kind of useless for row level security unless you have small datasets.

            1 of 1 people found this helpful
            • 3. Re: RLS solution - vendor conflict over user tables v Groups
              Ruthie Petty

              Thanks Toby and Russell. Appreciate your thoughts, especially the note about cross database joins...I've been concerned about the performance hit. We are trying to find out more, and are pushing back on them to provide a valid solution if they don't want to allow our user tables into the data warehouse. We're also hoping it may be a really crazy lack of understanding for what we're asking.