Question: How do you recommend enforcing authorization?

Hello,

I’d like to systematically enforce authorization for nodes and individual fields within the nodes.

Conceptually something like this might work:

class MyNode(AuthZSQLAlchemyObjectType):
    class Meta:
        model = MyModel
        authorize_node_function = node_authorizer
        field_auth = dict(
              "name": all_authorizer,
              "private_things": self_only_authorizer,
       )

node_authorizer(model_instance) would get called whenever a new Node of that type is created. Only fields in the field_auth dict would be exposed in node, and then the associated function would be called like resolve_authorizer(model_instance, field_name)

Any opinions on the best way to achieve this?

[duboisj-illuminate]

This is somewhat old but still open. Has there been any additional development to support this in graphene-sqlalchemy, or are there authorization patterns the community has settled on as workable?

[hoffrocket]

Thanks @Nabellaleen Those approaches seem inline with what we’d like to do.

Our goals:

1. prevent new columns added to a SQLAlchemy model from leaking into the GraphQL schema (by enforcing use of only_fields like whitelist)
2. associate a role or auth function with each column to enforce authorization rules at query time
3. associate a role or auth function with the Node itself to catch things like id and custom fields that are not in the list of columns

We had been solving these concerns by being using only_fields on every Node and then overriding the resolve methods for columns where we need authorization controls. But that has become cumbersome and error prone. We have a lot of boilerplate code that looks like this:

class OurNode(SQLAlchemyObjectType):
    class Meta:
       only_fields = ("name", "created_at",...)
    
    @self_or_staff_required
    def resolve_name(self, info):
        return self.name

    @staff_required
    def resolve_created_at(self, info):
        return self.created_at

I’ve been experimenting with the concept above and it’s pretty similar to what @dfee suggests here https://github.com/graphql-python/graphene-django/issues/79#issuecomment-306583068

It seems to work, and I wonder if we can get some consensus around an approach that could be pushed upstream and be generally useful.

One fundamental challenge to overcome in this community is that graphene-django is basically a superset and fork of graphene-sqlalchemy.