Leveraging `dash-auth` role-based access control

[gtauzin]

Have you already looked into this topic?

• I've reviewed the Vizro documentation for any relevant information
• I've searched through existing issues for similar questions
• I've already searched online (e.g., Dash documentation) but couldn’t find anything helpful

Question

Hi everyone 👋!

I am looking into authentification and role-based access control of my vizro apps. I went for dash-auth and it seems it has everything I need.

When it comes to group-based access control, dash-auth offers the protected and protected_callback functions and I am looking into how to integrate them nicely into vizro.

My idea on how to approach it is to do the following:

1. Create a vizro Modal component wrapping dbc.Modal
2. Create two Modal instances at the vm.Dashboard level to be opened whenever the user is unauthentified (with a login button) or missing permissions (with a logout / sign in with another account button).
3. Subclass vm.Action into a ProtectedAction that will call the protected function to open the right modal based on the authorization error (or none of them if the user is authorized)
4. Use ProtectedAction in place of vm.Action all over my app (by calling add_type appropriately)

I am having some issues with add_type (see below) for which I would really appreciate your help, but I would mostly like to know what you think about this approach.

Code/Examples

I have made a simple example of my ProtectedAction class on PyCafe that roughly implements the protection logic. There is no Modal in that example, so we expect the Show histogram button to not do anything if clicked without permissions.

However, I am running into a pydantic issue when calling add_type:

pydantic.errors.PydanticUserError: `Tag` not provided for choice {'type': 'definition-ref', 'schema_ref': 'app.ProtectedAction:153118520'} used with `Discriminator`

Note that before trying to write a ProtectedAction, I have tested that simply wrapping protected within the action worked:

@capture("action")
def show_plot_action():
    def func():
        return px.histogram(df, x="sepal_width", color="species")

    return protected(unauthenticated_output=None, missing_permissions_output=None, groups=["Admin"])(func)()

Thanks a lot for your help! :)

Which package?

vizro

Code of Conduct

• I agree to follow the Code of Conduct.

[gtauzin]

As this is a bit of complex question and PyCafe does not support auth, I have started a simple repository to demonstrate the issues I am facing: https://github.com/gtauzin/kedro-vizro-labeling

It contains the more advanced version of ProtectedAction as well as a somewhat generic implementation of Modal, DropdownMenuItem, and DropdownMenu used in a CustomDashboard. I'd be happy to contribute to vizro some of those if there's any interest.

Note that the code of interest is under src/kedro_vizro_labeling. Following the README should be enough to run the dashboard.

In time, I will push there a simple time series labeling dashboard with its accompanying kedro pipelines as we discussed previously on Zoom.

[antonymilne]

Hello @gtauzin, always great to hear from you! 🙂 Let me do a partial response here so it doesn't seem like I'm ignoring you, and then I'll post more later on the approach in general and hopefully even a working example!

Some context to begin with: in the past, it was possible to use dash-auth with vizro. This wasn't commonly done or documented anywhere, and due to limitations with dash-auth it was never a priority to improve much. However, since then dash-auth has actually come on a lot and now version 2.3 looks much more powerful. So we should look again into how to integrate it with Vizro or maybe even build it in directly, e.g. maybe to switch all our callbacks to public_callback so we're automatically compatible with dash-auth (edit: not a good idea) 🤔 I hadn't seen those before but that feels like it might be a no-loss thing to do.

No idea if it's useful for you but might be for someone else who sees this: ploomber cloud offers auth which I've never tried but looks good and should work out of the box with Vizro without needing to modify your code at all.

The issue with add_type ooccurs because the whole actions system is being heavily rewritten at the moment and so the add_type is in a weird intermediate state to ensure it remains backwards compatibility while trying to enable some new functionality. This means you need to do this:

from pydantic import Tag
from typing import Annotated

ProtectedAction = Annotated[ProtectedAction, Tag("protected_action")
vm.Button.add_types("actions", ProtectedAction)

(Doesn't actually seem to work on pycafe, not sure why - but it works with a simple toy example on my computer anyway...)

Hopefully that might help you make some progress straight away anyway, and I'll come back and comment more on the other bits tomorrow!

[antonymilne]

One quick question: is there a reason you use the main version of dash-auth? Are there unreleased features you need?

[gtauzin]

Hello @gtauzin, always great to hear from you! 🙂 Let me do a partial response here so it doesn't seem like I'm ignoring you, and then I'll post more later on the approach in general and hopefully even a working example!

Hi @antonymilne ! 👋 Thank you so much for your answer, it's already very useful :)

The issue with add_type ooccurs because the whole actions system is being heavily rewritten at the moment and so the add_type is in a weird intermediate state to ensure it remains backwards compatibility while trying to enable some new functionality. This means you need to do this:

from pydantic import Tag
from typing import Annotated

ProtectedAction = Annotated[ProtectedAction, Tag("protected_action")
vm.Button.add_types("actions", ProtectedAction)

(Doesn't actually seem to work on pycafe, not sure why - but it works with a simple toy example on my computer anyway...)

Hopefully that might help you make some progress straight away anyway, and I'll come back and comment more on the other bits tomorrow!

Thanks! Indeed, this helps but I got a new error:

ValidationError: 1 validation error for Button
actions.actions.0
  Input tag 'protected_action' found using _get_action_discriminator() does not match any of the expected tags: 'action', 'export_data', 
'filter_interaction', '_filter', '_parameter', '_on_page_load' [type=union_tag_invalid, 
input_value=ProtectedAction(id='eb116...ssing-permission-modal'), input_type=ProtectedAction]
    For further information visit https://errors.pydantic.dev/2.11/v/union_tag_invalid

I set the type of ProtectedAction to "action" and used "action" as well as my add_type Tag as a temporary workaround so I can run the code. So for now it works :)

---

One quick question: is there a reason you use the main version of dash-auth? Are there unreleased features you need?

This was what I used back in March and forgot to update it when I created the repo. I've set it to 2.3.0 now.

---

Some context to begin with: in the past, it was possible to use dash-auth with vizro. This wasn't commonly done or documented anywhere, and due to limitations with dash-auth it was never a priority to improve much. However, since then dash-auth has actually come on a lot and now version 2.3 looks much more powerful. So we should look again into how to integrate it with Vizro or maybe even build it in directly, e.g. maybe to switch all our callbacks to public_callback so we're automatically compatible with dash-auth 🤔 I hadn't seen those before but that feels like it might be a no-loss thing to do.

No idea if it's useful for you but might be for someone else who sees this: ploomber cloud offers auth which I've never tried but looks good and should work out of the box with Vizro without needing to modify your code at all.

For our internal Vizro dashboards, we already use OIDCAuth from dash-auth for auth and it works out of the box. Ploomber look quite nice indeed, but at the moment, we deploy them ourselves. What I am interested in is to setup group-based access control and from what I could see having a quick look at Ploomber, I am not sure this is possible.

As for dash-auth, from what I understand it enables group-based access control with protected or protected_callback that allows you to pass outputs for the cases corresponding to the user being unauthenticated and missing permissions.

I think it would be great if dash-auth was directly integrated into Vizro. If I may, I would say having the following would be great:

1. Support for BasicAuth and OIDCAuth
2. Possibility to specify required groups to vizro actions
3. Pre-defined (and customizable) action outputs when user is unauthenticated or missing permissions
4. Integrated user menu (typically it is accessed by clicking on a dropdown menu labeled with an avatar image) with user infos and button to sign in with another account and to logout
5. Would be good to have also the possibility to protect pages

This is basically what I am trying to do in my own way in my kedro-vizro-labeling demo repo. 2 is enabled with the ProtectedAction while 3 is enabled with dedicated modals that will open only when user is unauthenticated/missing permissions while other action outputs will be dash.no_update. For 4, I create a DropdownMenu with DropdownMenuItems being buttons to sign in and logout (WIP).

For now I have not had the need for dash-auth's public routes / callbacks so I have not thought of integrating it with Vizro.

I have updated kedro-vizro-labeling with a working version of ProtectedAction! Happy to keep discussing this further when you have some time to look into it :)

Thanks for your support! :)

[antonymilne]

I've been playing around with dash-auth today just to get myself up to speed. Let me dump the results of my current experimenting here and respond to your specific points in a separate reply @gtauzin. Maybe this will form the basis for some future documentation and/or built-in integrations with Vizro and hopefully it's useful for other people to refer to already.

BasicAuth

The examples here are based on HTTP basic auth and the dash_auth documentation, which as the Dash documentation explains, has significant limitations:

• Users can not log out of applications
• You are responsible for sending the usernames and passwords to your viewers over a secure channel
• Your viewers can not create their own account and cannot change their password
• You are responsible for safely storing the username and password pairs in your code.

HTTP basic auth is good for writing toy examples like here though, and depending on your situation maybe it's all you need. In more sophisticated scenarios you'll want to use something else:

• dash-auth with OIDC
• Dash Enterprise and dash-enterprise-auth
• Ploomber Cloud

Protect the whole app

This works exactly as expected: you get a login screen that blocks access to the whole app.

from dash_auth import BasicAuth
import vizro.plotly.express as px
from vizro import Vizro
import vizro.models as vm

df = px.data.iris()

page = vm.Page(
    title="My first dashboard",
    components=[
        vm.Graph(figure=px.scatter(df, x="sepal_length", y="petal_width", color="species")),
        vm.Graph(figure=px.histogram(df, x="sepal_width", color="species")),
    ],
    controls=[vm.Filter(column="species")],
)

dashboard = vm.Dashboard(pages=[page])

USER_PWD = {
    "username": "password",
}

app = Vizro().build(dashboard)
BasicAuth(app.dash, USER_PWD)
app.run()

Within a protected app, you can set certain routes to be public so that unauthenticated users can access them:

BasicAuth(app.dash, USER_PWD, public_routes=["/"])

This works to some extent:

• pages with only static content (vm.Card, vm.Text) work
• any dynamic content will not be loaded since the on_page_load callback gets blocked for unauthenticated users. It's not currently possible to make this a public_callback due to a dash-auth bug that would be fixed by an open PR.

Protect parts of the app

You can make any dynamic component (vm.Graph, vm.Figure, vm.AgGrid, vm.Table) visible to only certain users using groups and the dash-auth protected functionality. It's not possible to immediately combine @combine with @protected but this might be nice to have in future so you can immediately just add one line @protected after the @capture.

There's two patterns you can use here. Here's an example where the first graph is visible only to users in the admin group but the second graph is visible to everyone.

Pattern 1. Use protected inside the @capture function.

from dash_auth import BasicAuth, protected
import plotly.graph_objs as go
import vizro.plotly.express as px
from vizro import Vizro
import vizro.models as vm
from vizro.models.types import capture


# This is what a user without permission sees instead of the scatter plot:
forbidden_graph = go.Figure(
    layout={
        "paper_bgcolor": "rgba(0,0,0,0)",
        "plot_bgcolor": "rgba(0,0,0,0)",
        "xaxis": {"visible": False},
        "yaxis": {"visible": False},
        "annotations": [
            {
                "text": "You don't have permission to see this graph",
                "xref": "paper",
                "yref": "paper",
            }
        ],
    }
)


@capture("graph")
def scatter(data_frame, **kwargs):
    def _scatter():
        return px.scatter(data_frame, **kwargs)

    return protected(forbidden_graph, groups=["admin"])(_scatter)()


df = px.data.iris()

page = vm.Page(
    title="My first dashboard",
    components=[
        vm.Graph(figure=scatter(df, x="sepal_length", y="petal_width", color="species")),
        vm.Graph(figure=px.histogram(df, x="sepal_width", color="species")),
    ],
    controls=[vm.Filter(column="species")],
)

dashboard = vm.Dashboard(pages=[page])

USER_PWD = {
    "username": "password",
    "admin": "password",
}

USER_GROUPS = {"username": ["user"], "admin": ["admin"]}

app = Vizro().build(dashboard)
BasicAuth(app.dash, USER_PWD, user_groups=USER_GROUPS, secret_key="<PUT SOMETHING SUPER SECRET HERE>")
app.run()

Pattern 2. Custom model.

class ProtectedGraph(vm.Graph):
    # The unauthenticated response could be made different for different graphs by adding an unauthenticated_output field.
    # Here it's the same forbidden_graph always.
    @protected(forbidden_graph, groups=["admin"])
    def __call__(self, **kwargs):
        return super().__call__()


page = vm.Page(
    title="My first dashboard",
    components=[
        ProtectedGraph(figure=px.scatter(df, x="sepal_length", y="petal_width", color="species")),
        vm.Graph(figure=px.histogram(df, x="sepal_width", color="species")),
    ],
    controls=[vm.Filter(column="species")],
)

The same two patterns work for vm.Action. You may find that the callbacks trigger on page load so you never see ""Click the button to see the secret text". I was working off a branch different from main where it doesn't get triggered but in current Vizro releases it might be triggered.

Username username sees:

Username admin sees:

Pattern 1. Use protected inside the @capture function.

from dash_auth import BasicAuth, protected, list_groups

@capture("action")
def update_text():
    # Just using list_groups() here to prove it works.
    groups_text = f"You're in `{list_groups()}`"

    @protected(f"{groups_text}. You don't have permission to see the secret text.", groups=["admin"])
    def _update_text():
        return (f"{groups_text}. You have permission to see the secret text.",)

    return _update_text()


page = vm.Page(
    title="My first dashboard",
    components=[
        # FYI it's not yet documented but you can now just do outputs=["text"] without the "children"
        vm.Button(actions=[vm.Action(function=update_text(), outputs=["text.children"])]),
        vm.Text(id="text", text="Click the button to see the secret text"),
    ],
)

Pattern 2. Custom model.

# This is probably not really public and not a good type hint for Vizro anyway, but used here just for consistency
# with dash_auth. 
from dash_auth.group_protection import OutputVal


def prevent_update():
    raise PreventUpdate


class ProtectedAction(vm.Action):
    # Here we have a field to configure unauthenticated_output. If not specified then it defaults to just cancelling the
    # callback, just as for @protected_callback.
    unauthenticated_output: OutputVal = prevent_update

    # Instead of trying to alter the callback defined in Action.build to a protected_callback, it's easier to just 
    # wrap the underlying function. This function isn't public though so may not have the same name or exist in
    # future, but it should still be possible to do something like this.
    def _action_callback_function(self, *args, **kwargs):
        return protected(self.unauthenticated_output, groups=["admin"])(
            super()._action_callback_function(*args, **kwargs)
        )
        
page = vm.Page(
    title="My first dashboard",
    components=[
        # FYI it's not yet documented but you can now just do outputs=["text"] without the "children"
        vm.Button(actions=[ProtectedAction(function=update_text(), outputs=["text.children"])]),
        vm.Text(id="text", text="Click the button to see the secret text"),
    ],
)

Open a modal for unauthorised users

Here's my simplified version of what you've done building on my above examples. It actually works pretty well I think, thanks to your idea of the modal.

from typing import Literal, Annotated

from dash import set_props
from dash_auth import BasicAuth, protected
import plotly.graph_objs as go
from pydantic import Tag

import vizro.plotly.express as px
from vizro import Vizro
import vizro.models as vm
import dash_bootstrap_components as dbc

from vizro.models.types import capture

# This is what a user without permission sees instead of the scatter plot:
forbidden_graph = go.Figure(
    layout={
        "paper_bgcolor": "rgba(0,0,0,0)",
        "plot_bgcolor": "rgba(0,0,0,0)",
        "xaxis": {"visible": False},
        "yaxis": {"visible": False},
        "annotations": [
            {
                "text": "You don't have permission to see this graph",
                "xref": "paper",
                "yref": "paper",
            }
        ],
    }
)


# set_props has some limitations but actually should work pretty well here. It means you can update something outside
# the Dash outputs without needing to modify the callback at all.
# https://dash.plotly.com/advanced-callbacks#setting-properties-directly
# Note unauthenticated_output is always run within the context of a callback (assuming you never do
# ProtectedGraph.__call__ outside a callback, which Vizro doesn't by default).
def unauthenticated_output():
    set_props("auth_modal", {"is_open": True})
    return forbidden_graph


class ProtectedGraph(vm.Graph):
    # The unauthenticated response could be made different for different graphs by adding an unauthenticated_output field.
    # Here it's the same forbidden_graph always.
    @protected(unauthenticated_output, groups=["admin"])
    def __call__(self, **kwargs):
        return super().__call__()


df = px.data.iris()

page = vm.Page(
    title="My first dashboard",
    components=[
        ProtectedGraph(figure=px.scatter(df, x="sepal_length", y="petal_width", color="species")),
        vm.Graph(figure=px.histogram(df, x="sepal_width", color="species")),
    ],
    controls=[vm.Filter(column="species")],
)

dashboard = vm.Dashboard(pages=[page])
app = Vizro().build(dashboard)

# This is the lazy way to insert a dbc.Modal into the layout without needing to do a whole new CustomDashboard model.
app.dash.layout.children.append(
    dbc.Modal(
        [
            dbc.ModalHeader(dbc.ModalTitle("Access denied")),
            dbc.ModalBody("You don't have permission to see some things on this page"),
        ],
        centered=True,
        id="auth_modal",
    )
)
USER_PWD = {
    "username": "password",
    "admin": "password",
}

USER_GROUPS = {"username": ["user"], "admin": ["admin"]}

BasicAuth(app.dash, USER_PWD, user_groups=USER_GROUPS, secret_key="<PUT SOMETHING SUPER SECRET HERE>")
app.run()

If you want to do this through ProtectedAction, I think you're on the right lines but it could be simplified quite a bit to avoid overriding so many methods, either by using set_props to avoid altering any callback outputs or by continuing to alter callback outputs but with the code written a bit differently.

Protect pages

It's possible to block access to certain pages. In this example we just give a 404 page if the user is not authorised to view the page.

Disclaimer: this might not be 100% secure in that a small amount of information can be leaked (e.g. by inspecting local storage a user could see the names of actions defined on pages they're not allowed to visit) but it should be good enough for most uses.

In theory it's not too hard to make it page you don't have access to doesn't show in the nav panel, but in practice it's a bit fiddly to get working fully (e.g. edge cases where number of pages you have access to goes from 2 to 1).

from typing import Optional

from dash_auth import BasicAuth, protected

import vizro.plotly.express as px
from vizro import Vizro
import vizro.models as vm

# This method needs two custom classes, one for the Page and one for the overall Dashboard.
# Possible alternatives:
#  - alter dash.page_registry["page_id"]["layout"] directly. Should work basically the same way but less vizro-ic
#  - raise PreventUpdate in `page.build` (don't try and create a fake `html.Div` with all the right keys) - should
#     work fine and means less overriding of private things, but a bit more code gets executed before being cancelled
#     as unauthorised
class ProtectedPage(vm.Page):
    groups: Optional[list[str]] = None


class DashboardWithProtectedPages(vm.Dashboard):
    def _make_page_layout(self, page: ProtectedPage, **kwargs):
        if isinstance(page, ProtectedPage):
            return protected(self._make_page_404_layout, groups=page.groups)(super()._make_page_layout)(page, **kwargs)
        return super()._make_page_layout(page, **kwargs)


df = px.data.iris()

page_1 = vm.Page(title="Normal page", components=[vm.Text(text="Any authenticated user can see this")])
page_2 = ProtectedPage(title="Private page", groups=["admin"], components=[vm.Text(text="Top secret text")])

dashboard = DashboardWithProtectedPages(pages=[page_1, page_2])
app = Vizro().build(dashboard)

USER_PWD = {
    "username": "password",
    "admin": "password",
}

USER_GROUPS = {"username": ["user"], "admin": ["admin"]}

BasicAuth(app.dash, USER_PWD, user_groups=USER_GROUPS, secret_key="<PUT SOMETHING SUPER SECRET HERE>")
app.run()

Known problems/open questions

Issues with dash_auth:

• public_callback doesn't work due to a dash-auth bug that would be fixed by an open PR.
• logo doesn't work on public routes but can be fixed by altering DASH_PUBLIC_ASSETS_EXTENSIONS. There's a discrepancy for the default value of this that's documented (includes jpg, svg, etc.) vs. what it actually is set to (only includes js and css). Easy to fix.
• Discrepancy between "It defaults to unauthenticated_output when not set" documentation vs. behaviour for protected_callback - either the docs or the function is wrong. Easy to fix.

Notes:

• possible alternative to overriding _action_callback_function would be to modify callbacks into protected_callbacks after they're registered in GLOBAL_CALLBACKS_MAP, maybe taking inspiration from Dash Extensions
• the above ways of protecting a callback could also be used to block built-in actions like on_page_load, filter, etc. without needing to block execution at the Figure-level. This will be much easier after the actions are reworked so these are public
• the protection of figures is always done at the callback-level and the Dash pages callback cannot easily be protected (?). Hence the result of the initial page build before on_page_load is called will be visible to all authenticated users regardless of their group. Implications:
  • it's not currently possible to protect static components like vm.Card or the whole page. Probably we can figure out some way to do this though.
  • if we change how the Page.build/on_page_load mechanism works to that graphs are shown upfront (very unlikely to happen but not impossible) then this would potentially make things you think are protected visible. So you should check the authentication is still working as you intend if you upgrade Vizro (good practice anyway but essential if security is important to you).

[antonymilne]

Now for some comments on your particular approach. I went through all your code and left some comments and questions in a PR so take a look: gtauzin/kedro-vizro-labeling#1.

Generally speaking I'm super impressed by your ambition and your success achieving it, particularly given you had to deal with bits of Vizro and dash-auth where there is not much documentation! Really cool stuff 🙌 Thanks for posting this issue and prompting me look at dash-auth again. I think I've read through pretty much every line of their codebase now so have a much better understanding of it than before which is very useful.

My idea on how to approach it is to do the following:

1. Create a vizro Modal component wrapping dbc.Modal
2. Create two Modal instances at the vm.Dashboard level to be opened whenever the user is unauthentified (with a login button) or missing permissions (with a logout / sign in with another account button).
3. Subclass vm.Action into a ProtectedAction that will call the protected function to open the right modal based on the authorization error (or none of them if the user is authorized)
4. Use ProtectedAction in place of vm.Action all over my app (by calling add_type appropriately)

I think the idea of using dbc.Modal is a very good one. If we integrated it into Vizro then I'm not sure whether it should be a model that the user can configure or just something that's fixed (in which case we may or may not want to turn it into a Vizro model). I just added a simplified example based on your modal idea to my above post.

A couple of questions for you:

1. is it important to you to have different behaviours of unauthenticated vs. unauthorized? As it stands I don't actually see how unauthenticated is possible in your example or any Dash app which doesn't include some public routes. Because in order to access any page you need to login first, which means you cannot be unauthenticated. Am I missing something here?
2. Is the pattern of ProtectedAction actually what you want to do or just a workaround you thought of? Would it be better or worse to use my ProtectedGraph idea? Obviously the "Show histogram" button is just a toy example but I'm wondering if you actually want ProtectedAction at all if you could instead protect the output figures? I think both approaches are legitimate but it probably depends on individual use case which is best.

I am having some issues with add_type (see below) for which I would really appreciate your help, but I would mostly like to know what you think about this approach.
...
I set the type of ProtectedAction to "action" and used "action" as well as my add_type Tag as a temporary workaround so I can run the code. So for now it works :)

This I haven't been able to solve. I'm not sure why the code I posted above doesn't work. But the good news is I think you don't need to worry about it - just do ProtectedAction(vm.Action) with no new type or add_type and I think it will work as you like so long as you configure your dashboard using Python (not e.g. yaml).

---

For our internal Vizro dashboards, we already use OIDCAuth from dash-auth for auth and it works out of the box. Ploomber look quite nice indeed, but at the moment, we deploy them ourselves. What I am interested in is to setup group-based access control and from what I could see having a quick look at Ploomber, I am not sure this is possible.

Nice, that is very good to know that you have got it working with OIDCAuth, especially given the minimal documentation on the matter! I may need to pick your brains some time on how you got it working - I've not tried it before and don't know much about it.

I think it would be great if dash-auth was directly integrated into Vizro. If I may, I would say having the following would be great:

1. Support for BasicAuth and OIDCAuth
2. Possibility to specify required groups to vizro actions
3. Pre-defined (and customizable) action outputs when user is unauthenticated or missing permissions
4. Integrated user menu (typically it is accessed by clicking on a dropdown menu labeled with an avatar image) with user infos and button to sign in with another account and to logout
5. Would be good to have also the possibility to protect pages

This is basically what I am trying to do in my own way in my kedro-vizro-labeling demo repo. 2 is enabled with the ProtectedAction while 3 is enabled with dedicated modals that will open only when user is unauthenticated/missing permissions while other action outputs will be dash.no_update. For 4, I create a DropdownMenu with DropdownMenuItems being buttons to sign in and logout (WIP).

Generally agree with all these ideas. My main hesitation (other than other roadmap priorities as usual) would be that I don't know much about what other people would want here which makes it hard to extract a common pattern that we could build into vizro, i.e. we'd need to do some more user research. For me the ability to protect a whole page sounds like a fundamentally important requirement (more so than protecting individual graphs) whereas for you it sounds more like a "nice to have" so we'd have to get a much more general understanding of requirements here. We have at least one person in McKinsey who has done something similar but apparently didn't use dash-auth, not sure why.

Some of the questions would be:

• where should the protection live: action? graph? page? all of these?
• what do you want to happen when someone is unauthorized/unauthenticated? How customisable should this be? Is a modal good for everyone? Is a blank graph good or you need to be able to specify a different non-authenticated graph?
• how is your login system setup so we can connect to it the right way? Does OIDCAuth abstract everything away here to a common standard that everyone follows? I don't know enough about the topic yet to say.
• what would you actually need in the user menu: just a logout button or anything else? One thing I'm sure of is that we don't want to go into user management (reset password, etc.) but delegate that to whatever system you're using.

There's a general long-term plan to move the theme switcher into a more general settings area by adding some more things there just like you've done with your menu. We'd need to work a bit on the designs for this to figure out what goes there and what it looks like since I'm not sure what else we might want to add there in future as well as a logout button.

tl;dr: I love the idea, not sure what its priority is, I need to understand more about OIDCAuth and other people's use cases before anything would be implemented on core vizro. But definitely let's continue trying to work out how to solve your particular case right now anyway, and then it can live either as documentation, example app, maybe even in vizro.integrations.

[gtauzin]

Hi @antonymilne 👋 ! Honestly, I did not expect such complete answers (and a PR with comments!!!), this is just amazing. I am also very grateful that you shared your own study of dash-auth capabilities, there is so much interesting content in there.

Now for some comments on your particular approach. I went through all your code and left some comments and questions in a PR so take a look: gtauzin/kedro-vizro-labeling#1.

Thank you so much, I really appreciate the time you took to support those efforts! I'll reply to your comments shortly.

Generally speaking I'm super impressed by your ambition and your success achieving it, particularly given you had to deal with bits of Vizro and dash-auth where there is not much documentation! Really cool stuff 🙌 Thanks for posting this issue and prompting me look at dash-auth again. I think I've read through pretty much every line of their codebase now so have a much better understanding of it than before which is very useful.

Thanks for the kind words. I think dash-auth's code is self-contained and well-written so it was a good learning experience for me to go through it. Obviously, vizro's code quality is very high so even without docs, I can usually get an idea of what the code does (maybe except for the more advanced pydantic code like the Tag!)

I think the idea of using dbc.Modal is a very good one. If we integrated it into Vizro then I'm not sure whether it should be a model that the user can configure or just something that's fixed (in which case we may or may not want to turn it into a Vizro model). I just added a simplified example based on your modal idea to my above post.

I am glad you like it. I personally believe I would be fine with a default behavior chosen by the Vizro team. I am sure you would come up with something relevant for all my use cases. But I did like the idea of using the @protected decorator along with @capture as a complement to allow full customization. This was actually the first thing I tried.

A couple of questions for you:

1. is it important to you to have different behaviours of unauthenticated vs. unauthorized? As it stands I don't actually see how unauthenticated is possible in your example or any Dash app which doesn't include some public routes. Because in order to access any page you need to login first, which means you cannot be unauthenticated. Am I missing something here?

You are not missing anything! Indeed, at the moment I can't check the unauthenticated behavior because my dashboards have no public routes. I simply over-extended my approach of the missing permissions case because I though a modal with a button redirecting you to login would apply to the unauthenticated case as well. I now realize this was confusing. Sorry about that. :)

1. Is the pattern of ProtectedAction actually what you want to do or just a workaround you thought of? Would it be better or worse to use my ProtectedGraph idea? Obviously the "Show histogram" button is just a toy example but I'm wondering if you actually want ProtectedAction at all if you could instead protect the output figures? I think both approaches are legitimate but it probably depends on individual use case which is best.

My ProtectedAction was more like a way to showcase the type of dash-auth integration I would like (e.g. using protected with modals). I started with this mostly because it is the equivalent of protected_callback. That being said I really like your ProtectedGraph and it probably is more relevant for a real app. I do believe that the next step is for me to make a ProtectPage as I already have a use case for it.

I am having some issues with add_type (see below) for which I would really appreciate your help, but I would mostly like to know what you think about this approach.
...
I set the type of ProtectedAction to "action" and used "action" as well as my add_type Tag as a temporary workaround so I can run the code. So for now it works :)

This I haven't been able to solve. I'm not sure why the code I posted above doesn't work. But the good news is I think you don't need to worry about it - just do ProtectedAction(vm.Action) with no new type or add_type and I think it will work as you like so long as you configure your dashboard using Python (not e.g. yaml).

I guess this is the right opportunity for me to ask something I have been wondering. If I extend a vizro model i.e. say I extend tabs, to have tab ids and actions triggered by active_tab, do I need to define a type at all in the class that inherits from vm.Tabs?

For our internal Vizro dashboards, we already use OIDCAuth from dash-auth for auth and it works out of the box. Ploomber look quite nice indeed, but at the moment, we deploy them ourselves. What I am interested in is to setup group-based access control and from what I could see having a quick look at Ploomber, I am not sure this is possible.

Nice, that is very good to know that you have got it working with OIDCAuth, especially given the minimal documentation on the matter! I may need to pick your brains some time on how you got it working - I've not tried it before and don't know much about it.

I am not an expert unfortunately! In order to setup OIDCAuth, I was provided with a keycloak realm that our DevOps created.

However, I can try and create a toy realm on my kedro-vizro-labeling repo to make use of OIDCAuth. That would also help demonstrating things like logout which does not work with basic auth. Hopefully, this can speed up your efforts. I'll create a PR and let you know!

Some of the questions would be:

( I am not sure whether you were prompting me for an answer on the potential user research questions, but I gave it a try anyways :) )

• where should the protection live: action? graph? page? all of these?

Personally, I would say all of these!

• what do you want to happen when someone is unauthorized/unauthenticated? How customisable should this be? Is a modal good for everyone? Is a blank graph good or you need to be able to specify a different non-authenticated graph?

On my side, I believe a modal (with appropriate button) is a good default. As for the graph, I am not sure I don't really have a use case in mind where I would use ProtectedGraph.

• how is your login system setup so we can connect to it the right way? Does OIDCAuth abstract everything away here to a common standard that everyone follows? I don't know enough about the topic yet to say.

I am also not the right person to answer this.

• what would you actually need in the user menu: just a logout button or anything else? One thing I'm sure of is that we don't want to go into user management (reset password, etc.) but delegate that to whatever system you're using.

I would say something with the account info (name, email, permissions), a "sign in with another account" button and a "logout" button. From what I understand, user management is indeed managed by the access manager.

There's a general long-term plan to move the theme switcher into a more general settings area by adding some more things there just like you've done with your menu. We'd need to work a bit on the designs for this to figure out what goes there and what it looks like since I'm not sure what else we might want to add there in future as well as a logout button.

I think the theme is the settings menu would look better than if it was next to the Settings button. I don't really like my current menu with DropdownMenu and I am sure you would come up with something much better looking.

tl;dr: I love the idea, not sure what its priority is, I need to understand more about OIDCAuth and other people's use cases before anything would be implemented on core vizro. But definitely let's continue trying to work out how to solve your particular case right now anyway, and then it can live either as documentation, example app, maybe even in vizro.integrations.

Great to hear! I am happy to support a future integration into Vizro as you see fit. :)

---

Finally, I think I should share one additional resource that I found quite interetsing to look at. A Dash user made an app with auth and some group-based access control without dash-auth. Maybe you'll find it interesting as well:

https://community.plotly.com/t/dash-app-with-user-registration-login-and-logout-functionality/85291

There's also a live app to check it out.

---

Thanks again for your amazing support!

[antonymilne]

Thanks for the appreciation, comments and feedback @gtauzin! This was a really interesting issue to think about, although I suspect I may now be at the point where I've worked out everything than I can do easily and would now need to dive into OIDC properly to make more progress, which will take longer 😬

I just figured out a way to do protected pages and updated my above "documentation" comment with it. Let me know what you think and if it works for you.

This I haven't been able to solve. I'm not sure why the code I posted above doesn't work. But the good news is I think you don't need to worry about it - just do ProtectedAction(vm.Action) with no new type or add_type and I think it will work as you like so long as you configure your dashboard using Python (not e.g. yaml).

I guess this is the right opportunity for me to ask something I have been wondering. If I extend a vizro model i.e. say I extend tabs, to have tab ids and actions triggered by active_tab, do I need to define a type at all in the class that inherits from vm.Tabs?

This is a great question, and honestly I'm not sure I can fully remember the answer to it 😅 But I think:

• if you want to do configuration from yaml/json/dictionary then defining type is essential
• if you're only interested in configuring by explicitly instantiating pydantic models then you probably (definitely?) don't need to define type, but there might be some cases where if you want to use both the original vm.Tabs and modified InheritedFromTabs in the same app you need to define type. If you only use one or the other then no such cases can occur.

In short, if you can start a dashboard and it looks like you want without defining type then you're all good and nothing will break while your dashboard is in use. In the docs we decided not to go into these technicalities and just say that you should always define type because that's easier than trying to explain when you do and don't need it, but often you actually don't really need it.

I am not an expert unfortunately! In order to setup OIDCAuth, I was provided with a keycloak realm that our DevOps created.

However, I can try and create a toy realm on my kedro-vizro-labeling repo to make use of OIDCAuth. That would also help demonstrating things like logout which does not work with basic auth. Hopefully, this can speed up your efforts. I'll create a PR and let you know!

This would be great, thank you! 🙏

Finally, I think I should share one additional resource that I found quite interetsing to look at. A Dash user made an app with auth and some group-based access control without dash-auth. Maybe you'll find it interesting as well:

https://community.plotly.com/t/dash-app-with-user-registration-login-and-logout-functionality/85291

There's also a live app to check it out.

Nice, thank you for this - I will check it out!