Access control lists

Persistent Query ACLs

Just as Access Control Lists can be applied to tables, they can also be applied to Persistent Queries. The owner of a query, as well as designated administrator groups, have full access to the query. They can see every table and are able to edit the query, restart it, stop it, etc. The owner and administrator can also select groups that can view the query. Viewer groups are not able to view the query source code, stop, start, or edit the query.

However, permissions do not carryover to the plots generated by those same Persistent Queries. To set access control for viewing these plots, you must use the setValidGroups method in the Persistent Query that generates the plot. See setting permissions for viewing plots.

Caution

Table and plot operations may or may not preserve their source's ACLs. Best practice is to apply ACLs at the end of your Persistent Query to make sure that they are not unexpectedly dropped.

Tables

As part of the Groovy code, filters can be added to tables. These filters do not take effect for the owner, admin, or members of the iris-superusers group -- only for viewers.

When no per-table ACLs are defined, the behavior of the Deephaven system is controlled by the property PersistentQuery.openSharingDefault, which defaults to true.

When PersistentQuery.openSharingDefault is true, if no filters are defined on any table, viewers can see all of the rows in all the tables produced by the query. If a filter is defined for at least one table, then viewers cannot see any tables without filters. This has the effect of making it convenient to let people see the full results of a query. Assuming care is taken to restrict part of the query, the parts that have not been addressed from a security perspective are hidden.

When PersistentQuery.openSharingDefault is false, viewers are not permitted to load any tables from the query if no filters are defined on any table. This requires explicit ACLs to be defined for all tables to be shared, but makes inadvertent sharing of data less likely.

For Legacy workers, Row and Column filters are applied to tables using a TableFilterProvider instance, created as follows:

TableFilterProvider.FACTORY.create(db, table)

Operations to add Row or Column ACLs can then be chained to apply the desired permissions to the table.

Row ACLs are applied using the following method:

.addFilter("group", "filter1", "filter2", ...)
  • db - is the database object
  • group is the group to which access is provided,
  • filter1, filter2, etc. are filter generator expressions to add (disjunctively). The format of the filter expressions is the same as for Table ACLs defined in the DB ACL Editor.

Column ACLs are applied using the following method:

.addColumnACL(“group”,”Column1,Column2,...”, “filter1”, “filter2”, ...)

Filters can be chained, for example:

TableFilterProvider.FACTORY.create(db, table)
    .addFilter("group1", "*")
    .addFilter("group2", "whereClause(\"A=`B`\")")
    .addFilter("group2", "whereClause(\"A=`C`\", \"D=`E`\")")
    .addColumnACL(“group3”, “Bid,Ask”, “new GroupFilterGenerator(\”MarketDataGrp\”)”)

In this example, group1 may access the entire table, but group2 can only view rows where A is equal to B, or rows where A is equal to C, and D is equal to E. Additionally, group3 can only view the specified rows.

Plots

The ability to see and edit Persistent Queries and the tables they generate is determined by the settings used by the query author in the Access Control tab of the Persistent Query Configuration panel. However, those permissions do not carryover to the plots generated by those same Persistent Queries.

To set access control for viewing these plots, you must use the setValidGroups method in the Persistent Query that generates the plot.

.setValidGroups(String... validGroups)

.setValidGroups(Collection<String> validGroups)

To limit viewing access to a particular plot, first write the query to create and show the plot. Then, assign the setValidGroups method to that plot.

Note

In a Python query, the setValidGroups argument must be on a separate line. Arguments to setValidGroups method include the names of the User(s) and Group(s) you want to be allowed to see the plot.

For example, the following query creates an XY Series chart to show the price of a single security (PFE) over the course of one day. No viewing restrictions are currently in place.

t1 = db.t("LearnDeephaven","StockTrades").where("Date=`2017-08-24`","USym=`PFE`")
PlotPFE = plot("PFE", t1, "Timestamp", "Last")
    .xBusinessTime()
    .show()

To set the viewing permissions for this plot, add the following line to the query.

PlotPFE.setValidGroups("User1", "User2", "Group1")

When this query is executed in Deephaven, only User1, User2, and individuals included in Group1 would be allowed to open and view the plot using the Show Widget button in the Deephaven console.

For example, if User3 was not included in Group1, User3 would not be able to view PlotPFE even if User3 was authorized to view the Persistent Query and/or the tables generated by the Persistent Query.

Note

The setValidGroups method will have the same effect as the addFilter method (described above in the Tables section) in that, if used, any table without restrictions will also be hidden.

Keep in mind that the setValidGroups method does not differentiate the data shown to each user. The widget can make use of the IrisWidgetSupport getIrisUserContext method to restrict information based on the user.

The LiveWidgetVisibilityProvider interface can be implemented by a widget to restrict the set of users that can load the widget. However, it does not differentiate the data shown to each user. The widget can make use of the IrisWidgetSupport getIrisUserContext method to restrict information based on the user.