Research & test user access via connected app in uat

[jacobthill]

We are having some confusion about what the rialto web app can/should manage and what should be managed in Tableau.

We seem to agree that the rialto web app can and should manage authentication e.g. it is the only place where we determine if a user is in the correct business group or is a Stanford affiliate. We seem to be confused about the various access levels that can be managed in Tableau (see image below):

@jmartin-sul referenced this documentation as something to investigate. My understanding of this document is that it documents a valid path to use a connected app to manage "row level" access to a data source–e.g. set a filter to the particular region that the user cares about or is allowed to see–whereas the permissions in Tableau are set on the site, project, or view. Even if we restricted access to every row via the JWT, the user would still see the dashboard, buttons, etc. I would just not have any data in it. I don't think we have a requirement to restrict row level access. And its not the same thing as telling a user they can't download the full data source, share it with others, comment, etc. These dashboard permissions need to be managed in the Tableau UI, as far as I understand it. This means we can't just get rid of the "Guest" user account, etc. We still need them to control these permissions.

If we tried to get rid of the "Guest" account and manage everything via our app, for example, we would have to not put any permissions on the dashboards in Tableau (since our app can't override permissions). We would then grant our app full permissions to view, download, etc. on behalf of the users (e.g. as the gate keeper). This would mean that when our app shows a user a dashboard, the download full data button, comment button, etc. will always be visible (since there are no permissions set in Tableau). Our app would then be responsible for hiding these buttons from the user when the user is not supposed to be able to download, comment, etc. This sounds like a security nightmare since Tableau can release an update at anytime that changes the location of the download button, etc.

[jacobthill]

We can definitely assign a single set of permissions to specific dashboards within a work book. We still need to understand if 2 work groups can have separate permissions for the same dashboard. We are also not sure whether this is a requirement.

[jacobthill]

There still seems to be some agreement on the above point that we can't manage download, comment, etc. permissions through a JWT. There is some remaining uncertainty on whether or not the Stanford group needs to have "Guest" user permissions, etc. We decided to move forward by testing rather than continuing discussion. The Open Access workbook is ready in uat. I have set the following permissions in Tableau:

Public

Stanford (Note no permission rule is set)

Business Group

[edsu]

I noticed that the web app is using the sul:rialto workgroup, but it is configured as sul-rialto in the Stanford OA Drill Down dashboard. I'm not sure if that's a problem or not since I'm not a member of the group and can't test.

I tested the three visualizations in #8 and it looks to me like the public vis works, but the stanford-only does not. It fails with Tableau error 10101:

The site is not licensed with the Embedded Analytics usage-based model that is required to enable on-demand access. For more information, see Understanding License Models.

I am not able to test the Business group sul:rialto because I'm not part of that work group. Maybe someone else who is can test at https://sul-rialto-web-stage.stanford.edu/ ?

[edsu]

Follow up after standup: the rialto work group isnt being passed to the webapp. @peetucket is going to file an ops ticket to ensure we are getting the rialto group, then we can ensure it works w/ Tableau.

The Stanford Only view is working now that the On Demand Access properties in the JWT were removed (again). I thought I had merged those changes already, but perhaps they got lost in the move from sul-dlss-labs...

[peetucket]

Ops ticket: https://github.com/sul-dlss/operations-tasks/issues/4238

[edsu]

Now that we have the dlss:rialto group membership being made available the sul-rialto-web-stage application, it is showing the restricted link. However it seems to require you to click on a Sign In button:

Clicking on the Sign In renders the visualization after sending you through SSO.

If you click on the stanford visualization first, and then click restricted then the Sign In button doesn't display. Which is kind of weird?

I guess asking Business Case users to click an extra button may not be terrible, since most users (Public and Stanford) wouldn't see it?

Alternatively, we could consider making the Tableau access permissions for the Business Case the same as Stanford Only, and letting the web application decide when it is appropriate to share them?

Otherwise, we might need to contact Tableau Support to see if there is a way for the Sign In to not display...

[edsu]

We experimented a bit and found that we can supply a hard coded "subject" aka sub in the JWT and Tableau will respect it.

rialto-web/app/services/jwt_service.rb

Line 23 in e8060e2

'sub' => Current.user.sunetid,

So, one option for Stanford Only user case would be to supply a known valid Tableau user, instead of requiring the logged in Stanford user's SUNETID to be present in Tableau's list of users.

Ideally UIT would create a generic Tableau User we could use in this case. @jacobthill is going to contact UIT to see if that is something they can do for us.

[edsu]

In our last meeting with UIT (2025-10-29) they indicated that there may be separate workgroups for Staff and Faculty that we can use for the Stanford Only use case. They were not fond of our idea of using an existing Tableau user for this.