4 Replies Latest reply on Feb 17, 2016 8:33 AM by Sean Mullane

    Locking down permissions to send alerts

    Sean Mullane

      Is there a way to secure VizAlerts to control who can set up alerts? I haven't seen anything yet that would allow us to control access to the emailer at a more granular level than the set of people with the ability to publish. Since publishers can control the "to" and "from" fields it's important that we be able to restrict that ability to a trusted subset of our users. In our case that subset is smaller than the set of publishers.

       

      We'd like to start using VizAlerts but basically need to make sure we have a way to prevent, say, J. Random Publisher from sending out emails from:TheCEO@ourdomain.com.

       

      Thanks

       

      PS: I should add that this question stems from my understanding that the "from" field can be set more of less arbitrarily by a publisher. If that's not correct it may change the importance of this question for us.

        • 1. Re: Locking down permissions to send alerts
          Matt Coles

          Hey Sean. That's the correct understanding--the publisher can set arbitrary values for the from/to/cc/bcc fields.

           

          There are two ways to restrict the "permissions":

           

          1. VizAlerts uses a domain whitelist in the config file which applies to all alerts that anyone publishes. If the email domain for any of the recipients of the the alert does not match any in the whitelist, the entire alert fails and the subscriber and admin are sent an email indicating that it couldn't be sent, and why.

           

          2. You can tell VizAlerts to disregard alerts being attempted by any Tableau Server user you want by editing the SQL query at the bottom of the config file. This query is essentially asking Tableau Server's repository database for a list of alerts to process. It's a little daunting to look at, but the comments at the bottom show where such a modification could be made. You'd uncomment the "allowed users" line by removing the first two dashes, and adding whatever users you wanted to have access to VizAlerts in there:

           

          WHERE 1 = 1
            AND (
            (s.is_test = true)
            OR
            -- ######################################################
            -- ######## Editable Filters #########
            -- ######################################################
            (
            LOWER(sch.name) LIKE '_lerts%' -- only Alerts schedules ("_" single-character wildcard allows you to substitute Cyrillic capital A, U+0410 for sorting purposes)
          
            --AND st.name IN ('Default','TestSite') -- allowed Sites
            --AND p.name IN ('Sales') -- allowed Projects
            --AND su_sub.name IN ('mcoles', 'nkamkolkar') -- allowed Users
            --AND st.name = 'administration'
            --
            -- ######################################################
            -- ######## DO NOT EDIT FILTERS BELOW THIS LINE #########
            -- ######################################################
            AND sch.active = 'f' -- only disabled schedules
            )
            )
            AND coalesce(su_sub.email, '') <> '' -- only accounts with valid emails (no service accts)
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          

           

          This allows for a lot of flexibility. You can whitelist, blacklist, allow only certain combinations of specific alerts and users, etc. Just watch the logs after modifying the query so that you ensure it parses and runs correctly. The only downside to this approach is that users attempting to use VizAlerts can still subscribe on the VizAlerts schedules because Tableau Server has no permissions model for those. Their alert simply won't run. So they might be a bit confused about it. One could build an admin alert to email any individual subscribed to a VizAlert who wasn't on a whitelist failry easily, though, which can mitigate that issue.

           

          Let me know if you have any more questions!

           

          Matt

          • 2. Re: Locking down permissions to send alerts
            Sean Mullane

            Thanks Matt, very helpful. This is necessary functionality (both the recipient domain whitelist and the sender whitelist) for us so I'm glad it's there. I can see whitelisting adding a bit of administrative overhead/headache but your admin alert idea could help.

            • 3. Re: Locking down permissions to send alerts
              Matt Coles

              One more thing I thought I should clarify--if you've allowed say, three different users the ability to create an alert by adding them to the SQL query above, there is no mechanism to stop any of those three from sending out an email from TheCEO@ourdomain.com.  I could at some point add a config setting that toggled whether users were allowed to send email from addresses that aren't their own. That wouldn't be hard. But as of right now, that feature doesn't exist.

              • 4. Re: Locking down permissions to send alerts
                Sean Mullane

                I think the filter in the SQL query meets our minimum security needs. We can restrict this ability to people we trust with this level of ability. As we expand usage I could see a need for something like what you're talking about, where we have some sort of mapping between which user is allowed to send from which addresses. I think restricting users to their own address may be too restrictive as it would prevent us from using a noreply@ourcompany.com type of address, which we would probably want to use for this.