How Restrict Access to Embedded Dashboards on a Role-By-Role Basis

[mschaefer-gresham]

If I configure GUEST_ROLE_NAME = "Gamma" then Superset creates an anonymous user with the Gamma role for viewing embedded dashboards. But if I create a new user in Superset and assign it the Gamma role, this user can't see any dashboards. It seems the anonymous user can actually see any dashboard in the system that has been enabled for embedding (at least in the example database). Is this true?

There is a fundamental difference between anonymous Gamma users and logged-in Gamma users. This is confusing to me. It would be wonderful is someone could explain this.

I want to authorize embedded dashboards based on the Superset role associated to the user logged into my app where the dashboard is embedded. For example, every user in my app also has a corresponding user in Superset. A user can have one of three roles in Superset. Each role in Superset has access to a unique set of dashboards.

Then when I create an iframe in my app, I want to use the Superset role associated to the logged-in user in my app to embed the dashboard (not the GUEST_ROLE_NAME role every time). This way I can be certain users won't see data that doesn't belong to them.

How can I achieve this? Thank you!

[dosubot[bot]]

I found a similar solved discussion that might help you: Is it possible to programmatically add users and roles in superset? ^[1]. Additionally, there are some related unsolved discussions and closed issues that might provide further insights:

1. Embedding with different roles (unsolved) ^[2]
2. Send external portal permission to superset dashboard (unsolved) ^[3]
3. Dashboards should be loaded with current user access rights, not with dashboard owner's access rights (closed) ^[4]
4. Authorization issue with user roles in embeddable dashboards (closed) ^[5]

To authorize embedded dashboards based on the role associated with the user logged into your app, you can modify the request_loader method to return the appropriate user based on your app's authentication mechanism. Here is an example of how you might achieve this:

def request_loader(self, request: Request) -> Optional[User]:
    # pylint: disable=import-outside-toplevel
    from superset.extensions import feature_flag_manager

    if feature_flag_manager.is_feature_enabled("EMBEDDED_SUPERSET"):
        # Replace this with your app's user retrieval logic
        user = self.get_user_from_app(request)
        if user:
            return user
        return self.get_guest_user_from_request(request)
    return None

def get_user_from_app(self, request: Request) -> Optional[User]:
    # Implement your logic to retrieve the user based on your app's authentication
    # For example, you might use a token in the request headers to identify the user
    token = request.headers.get("Authorization")
    if token:
        # Validate the token and retrieve the user
        user = validate_token_and_get_user(token)
        return user
    return None

def validate_token_and_get_user(token: str) -> Optional[User]:
    # Implement your token validation and user retrieval logic here
    # This is just a placeholder example
    user_id = decode_token(token)
    if user_id:
        user = get_user_by_id(user_id)
        return user
    return None

def decode_token(token: str) -> Optional[int]:
    # Decode the token and return the user ID
    # This is just a placeholder example
    try:
        payload = jwt.decode(token, "your_secret_key", algorithms=["HS256"])
        return payload.get("user_id")
    except jwt.ExpiredSignatureError:
        return None
    except jwt.InvalidTokenError:
        return None

def get_user_by_id(user_id: int) -> Optional[User]:
    # Retrieve the user from the database by ID
    # This is just a placeholder example
    user = db.session.query(User).get(user_id)
    return user

In this example, the request_loader method is modified to call get_user_from_app, which retrieves the user based on your app's authentication mechanism. If a valid user is found, it is returned; otherwise, the guest user is returned. You will need to implement the validate_token_and_get_user, decode_token, and get_user_by_id methods according to your app's specific authentication and user retrieval logic ^[6].

The default behavior of the GUEST_ROLE_NAME in Superset is to create an anonymous user object that defaults to the public role, configured with GUEST_ROLE_NAME = "Public". To allow logged-out users to access some Superset features, you can use the PUBLIC_ROLE_LIKE config setting and assign it to another role whose permissions you want passed to this role. For example, by setting PUBLIC_ROLE_LIKE = "Gamma" in your superset_config.py file, you grant the public role the same set of permissions as for the Gamma role. Explicit grant on specific datasets is still required, meaning that you need to edit the Public role and add the public data sources to the role manually ^[7][8][9].

To continue talking to Dosu, mention @dosu.