Row-level filtering

[molexx]

Whilst #163 is about hiding certain fields in the schema, there is a separate need to hide certain rows from the results depending on the query's context. As determining the filtering depends on the context, variables and db data at execution time the filter code needs to be run per-query as part of its execution. Usually (always?) that code will need to be Entity-specific, and may depend on the data in related Entities. My immediate use-case is by relation to the currently logged in user but let's design a generic system for other use-cases.

Requirements

• allow predicates to be defined per-entity class which will be applied to all queries using it

• the predicates must apply whenever the entity is referenced via relationships, not just top-level. e.g. if 'Luke Skywalker' is filtered out we will not see him on a query for all Characters, nor will we see him as a friend if we query for all Characters and include their friends list in the projection.

• predicates must be able to join to other tables. For example this would allow querying of friends only.

• predicates should re-use joins, otherwise a query in a large schema where every entity has a filter will become very large and slow

• allow sets of predicates to be enabled/disabled at runtime depending on the context

Implementation considerations

• Hibernate has @Filter which looks like it should do this, but:

• • I have been unable to reference other tables/entities, hibernate bug HHH-12967 for this has been open over a year
• • if tables are already used in the query I'm not sure if @Filter will re-use those joins or add them again under a different alias which will affect performance on a reasonably sized schema

• As @igdianov suggested it would be nice to be able to specify the predicates as a JPQL string, which could include SpEL referencing ExecutorContext properties. Spring-data's use of this is relatively simple as the entire string is the query, to use here we would need to merge the string in with the rest of the generated JPQL. Would it be easy to re-use existing joins when doing that?

• Add methods to Entity classes which return List<Predicate> and are annotated with new annotation @GraphQLRowFilter. For user and testing flexibility the filters can be named and a list of active filters can be passed to the executionEnvironment.

---

I'm currently experimenting with option 3 from above, calling the Entity methods from getFieldPredicates() and using reuseFetch() to try and keep the queries smaller.

[molexx]

@igdianov what do you think about the igdianov-executor-context-factory branch created for #163 ? I have merged it into my workspace - along with the upgrade-to-graphql-java-13 branch - so that I can set executor/executionInput/environment Context properties at runtime.

Also I am interested in getting GraphqlFieldVisibility working soon.

[igdianov]

what do you think about the igdianov-executor-context-factory branch created for #163 ? I have merged it into my workspace - along with the upgrade-to-graphql-java-13 branch - so that I can set executor/executionInput/environment Context properties at runtime.

I will make some minor refactoring in #163 to be able to configure context and execution input providers independently for better decoupling. I can also merge and release 0.4.x branch with graphql-java 13 support. Stay tuned.

[igdianov]

@molexx This is how Spring Data uses Spring Security common security expressions to augment repository methods with @Query annotations:

@Repository
public interface MessageRepository extends PagingAndSortingRepository<Message,Long> {
    @Query("select m from Message m where m.to.id = ?#{ principal?.id }")
    Page<Message> findInbox(Pageable pageable);
}

They can use the following common security expressions to augment predicates at runtime:

Expression	Description
hasRole([role])	Returns true if the current principal has the specified role. By default if the supplied role does not start with 'ROLE_' it will be added. This can be customized by modifying the defaultRolePrefix on DefaultWebSecurityExpressionHandler.
hasAnyRole([role1,role2])	Returns true if the current principal has any of the supplied roles (given as a comma-separated list of strings). By default if the supplied role does not start with 'ROLE_' it will be added. This can be customized by modifying the defaultRolePrefix on DefaultWebSecurityExpressionHandler.
hasAuthority([authority])	Returns true if the current principal has the specified authority.
hasAnyAuthority([authority1,authority2])	Returns true if the current principal has any of the supplied authorities (given as a comma-separated list of strings)
principal	Allows direct access to the principal object representing the current user
authentication	Allows direct access to the current Authentication object obtained from the SecurityContext
permitAll	Always evaluates to true
denyAll	Always evaluates to false
isAnonymous()	Returns true if the current principal is an anonymous user
isRememberMe()	Returns true if the current principal is a remember-me user
isAuthenticated()	Returns true if the user is not anonymous
isFullyAuthenticated()	Returns true if the user is not an anonymous or a remember-me user
hasPermission(Object target, Object permission)	Returns true if the user has access to the provided target for the given permission. For example, hasPermission(domainObject, 'read')
hasPermission(Object targetId, String targetType, Object permission)	Returns true if the user has access to the provided target for the given permission. For example, hasPermission(1, 'com.example.domain.Message', 'read')

For GraphQL application domain, here is a very comprehensive implementation of GraphQL access controls by Hasura: https://docs.hasura.io/1.0/graphql/manual/auth/index.html

I would like to discuss and explore the approach that allows to define select row and attribute permission rules via annotations that use existing GraphQL JPA search criteria syntax mixed with SpEL expressions, so we can inject any values via SpEL expressions into security evaluation context root provided by ExecutionInput with user authentication details (id, roles, groups, permissions) into custom predicates. The access control rules can be defined similar to Hasura implementation:

After that, it will be possible mutate query predicates with access controls restriction predicates evaluated at runtime to execute restricted access query using similar to Hasura implementation:

For field level access controls we can apply GraphqlFieldVisibility rules for execution result that will use SpEL expressions like Spring Security @PreAuthorize, @PostAuthorize, @PreFilter, @PostFilter annotations on entity attributes.

Does it makes sense?

[molexx]

Those spring-data @Query strings are the JPQL for the entire query, but for our usage they would need to be merged into the rest of the query that is already built up. Is that easy to do?
Whilst ensuring joins are reused effectively?

Those expressions are provided by Spring; possibly spring-security. I don't see a problem using them but it would tie graphql-jpa-query in to Spring, is that ok?

Are you thinking of writing those strings as annotations in the Entity Java classes or storing them somewhere alongside like Hasura?

[igdianov]

Those spring-data @Query strings are the JPQL for the entire query, but for our usage they would need to be merged into the rest of the query that is already built up. Is that easy to do?
Whilst ensuring joins are reused effectively?

In Spring Data, the whole query is being evaluated using security context with method parameters and then used to get results. The query is static, so this will not work with GraphQL adhoc queries.

We need to try create a few tests to evaluate feasibility of using GraphQL SpEL expressions:

1. Before running query builder, we need to be able to intercept datafatcher get method call to traverse query AST, evaluate SpEL predicates for matching entities in the fetch graph and transform parsed query AST in order to apply access restriction predicates with existing predicates. After that, we can pass the modified AST to query builder which will produce JPQL query with reuse joins if needed.

[igdianov]

Those expressions are provided by Spring; possibly spring-security. I don't see a problem using them but it would tie graphql-jpa-query in to Spring, is that ok?

It does not need to have a hard dependency on Spring Security. Spring Security expression could be added as an extension bean to SpEL evaluation context in order to be able to use them. The SpEL expressions used in annotations could simply use execution input context injected by provider implementation.

[igdianov]

Are you thinking of writing those strings as annotations in the Entity Java classes or storing them somewhere alongside like Hasura?

Let's try to define sample annotations for use cases and see if it makes sense. I will add my thoughts below

[igdianov]

@molexx I took my time to contemplate and research the proposed approach with GraphQL expressions. I don't think it is feasible for several reasons, but the main reason is that it brings GraphQL filter expressions into JPA domain, i.e.

@Entity
@GraphQLJPAQueryFilter("id: { EQ: #{ principal?.id } } } ")
public class Author {
	@Id
	Long id;

	String name;
}

I think users should be able to define filter predicate SpEL expressions using familiar JPQL like dialect on entity classes using annotation, i.e. to specify that logged in principal can only see the books he is the author:

@Entity
@GraphQLJPAQueryFilter("id=#{ principal?.id }")
public class Author {
	@Id
	Long id;

	String name;

	@OneToMany(mappedBy="author", fetch=FetchType.LAZY)
	Set<Book> books;
}

For the Books entity, users can specify path in filter expression to be able to filter books with a join to Author

@Entity
@GraphQLJPAQueryFilter("author.id=#{principal?.id}")
public class Book {
	@Id
	Long id;

	String title;

	@ManyToOne(fetch=FetchType.LAZY, optional = false)
	Author author;

	@Enumerated(EnumType.STRING)
	Genre genre;
}

Users may also define hidden User entity with user id and login attribute representing users in the system,

@Entity
@GraphQLIgnore
class User {
  @Id
  private Long id;
  
  private String login;

}

And then define filter expression to join owner with current principal:

@Entity
@GraphQLJPAQueryFilter("owner.id=?#{ principal?.id}")
public class Author {
	@Id
	Long id;
        
        @ManyToOne 
        User owner;

	String name;

	@OneToMany(mappedBy="author", fetch=FetchType.LAZY)
	Set<Book> books;
}

@Entity
@GraphQLJPAQueryFilter("author.owner.id=#{principal?.id}")
public class Book {
	@Id
	Long id;

	String title;

	@ManyToOne(fetch=FetchType.LAZY, optional = false)
	Author author;

	@Enumerated(EnumType.STRING)
	Genre genre;
}

Does it make any sense?

[molexx]

Yes looks good!

I'm experimenting with something similar but not quite that user-friendly yet.

Would the strings be JPQL with SpEL expressions in them? If so the SpEL parser could be used first to replace the values in the strings from the context, leaving us with a JPQL String.
But once we have it I don't know how to merge the JPQL string into the existing query?

[igdianov]

Yes, the filters will be user-friendly JPQL expressions with SpEL in them. Initially, I think it will be OK for PoC to use SpEL parser to evaluate the expressions in order to replace SpEL placeholders. Then the filter expression can be parsed into AST in order to generate JPA Predicate against existing JPA query root with joins. The generated predicate will be added to the query predicate list.

However, for better performance, it will be useful to parse expression string with SpEL into AST once and determine bindings for arguments that use ? prefix for SpEL expressions, i.e.

@GraphQLJPAQueryFilter("author.owner.id=?#{principal?.id}")

Then, having bindings in expression AST, we can apply SpEL parser to evaluate argument values for bindings at runtime and then convert AST into Predicate.

[molexx]

@igdianov

I'm working with 0.4 branch now, thanks!

I want to set a property to enable/switch rowfiltering. I see with the new context code I can set it per execution, but that seems unnecessary as it is unlikely to need to change per execution, it's more app level.

Do you think it's important enough to add a SchemaBuilder property for it?

Or is there/would it be appropriate to add a property Map for general usage at a higher level than ExecutionContext?

[azizkhani]

+1

[molexx]

I have an initial implementation of this that is working, but is not in a releaseable state because it's not been tested on 0.4 because I can't run 0.4 due to #241. Sorry, but watch this space!