Restricting data based on user

[molexx]

We have a need to restrict the tables, rows and columns that are returned based on the calling user.

It's straightforward to authenticate the user using Spring; then the user's roles and an @Entity representing the user in a table in the db are available in the SecurityContext.

Examples of business rules:

• Only users with 'ADMIN' role can access the table/entity 'audit_log'
• Rows in the 'user' table can only be returned or traversed if user.id == user's id, or if the user has the 'ADMIN' role. But ADMINs cannot see some columns e.g. the user's real name.
• Rows in 'user_content' are available where creator_id is the current user's id, or where there is a row in the 'friends' table with both users' ids on. But friends don't see 'user_content.private_notes'

What are the options for defining/expressing these rules? Is there an existing GraphQL, JPA or SQL way of doing this?

Thoughts:

• Annotations on the JPA classes. I'm not sure they can be expressive enough without getting messy.
• Entity graphs?
• JPA criteria for each table - would provide table and row level access but not projection
• Interface/method on the JPA class?

Next, how could we hook this in to graphql-jpa-query to filter values as they are queried?

• amending the JPA query as it is built?
• graphql directives?

[igdianov]

@molexx It is possible to restrict tables and columns based on user permissions by augmenting original schema at run time and using the modified schema to execute query requests. It is a cheap operation and is going to be easy to implement. .

To restrict rows, it should be possible to augment the query with hooks to add specific domain entities restrictions to the query predicates.

I will investigate how to make use of GraphQL schema decorators and directives to make it pluggable.

Can also think about details of the test cases for your requirements, i. e. user permissions, schema restrictions, data restrictions, entity model?

[molexx]

@igdianov like it!

Is it cheap enough to build the schema per HTTP request or would it be built once per session and cached in the session?

Thanks.

Yes, for testing I think I'll need to add some fields to the StarWars schema that should be private. We could use the 'friends' relationship to test rules like 'can only see friends of a friend'. Maybe the light side/dark side characters cannot see certain fields of characters on the other side.

[igdianov]

@molexx Yes, decorating schema at runtime is a cheap operation that can be done per request. I will add a factory method in GraphQLExecutor to be able to do that. You can decide if you want to cache it per user if needed. Stay tuned. I will make a crack at it over the weekend.

[molexx]

Aha that looks great, thanks @igdianov!

Would it be appropriate to add a GraphqlFieldVisibility implementation that builds the list of fields using rules from some kind of configuration defined near the JPA Entities?

What pattern do you think fits?

Some thoughts:

• Per-column annotations using Spring's SPEL e.g.:
  @PreAuthorize("hasRole('ROLE_ADMIN')")

• Per-column annotations like Jackson's @JsonView, not sure if that's flexible enough though

• an Entity-class-level method which returns List<Column>

In future we also want to hide values on a per-row basis, not sure if the design here could work with that too.

[igdianov]

@molexx I am thinking to add support for GraphQL directives mapping from Java annotations. Then, you can apply GraphQLVisibility function to hide fields in the schema based on ExecutionInput context, i.e. User roles and directive information, i.e. allowed roles.

For example, we can use JSR-250 @Secured annotation on entity classes and attributes to specify roles allowed to view them. Then, apply visibility filter that uses Spring user security context authorities from ExecutionInput context.

[zhikaing]

Hi, I manage to rebuild/augment the schema based on request however, the GraphQLTypeCollectingVisitor hits an AssertException complaining the following. Any idea? Debug further, it seems that the existing fieldDefinition is still being traversed which resulted 2 entries

graphql.AssertException: All types within a GraphQL schema must have unique names. No two provided types may have the same name.
No provided type may have a name which conflicts with any built in types (including Scalar and Introspection types).
You have redefined the type 'Trade' from being a 'GraphQLObjectType' to a 'GraphQLObjectType'