While GraphQL mentions security should be delegated to underlying business logic, the nature of GraphQL lends itself very well to security.
In GraphQL the Query can have a resolve method, also each field can have a resolve method. In a way we are traversing the graph, if we provide resolvers for each query and all fields of their results.
Now "Attribute Based Access Control" is gaining popularity with its ways to define security policy across
Subject
Resource
Action
Environment
One way "Attribute Based Access Control" is implemented is, that it modifies the query being fired to only fetch eligible data. This could be done by a wrapper resolver.
Second way "Attribute Based Access Control" can be implement in GraphQL, is to use field level resolvers to decide whether to expose that field or not.
The question I have to the community is what are the various ways to implement "Attribute Based Access Control" in GraphQL, especially leveraging the strengths of GraphQL
Cheers,
Rohit
There are 2 ways ABAC could be used to secure data - be it GraphQL; SQL; HQL... - like you say:
Either you modify the incoming query so that the modified query only retrieves the entitled data. This is for instance how some database proxies work. It intercepts 'SELECT a, b, c FROM t' and converts it into 'SELECT a, b, c FROM t WHERE...' Axiomatics does that with its Data Access Filter.
Or you configure the underlying system so that it only allows access under the right circumstances. We call that provisioning. Years ago, for instance, MySQL had a feature called FGAC - fine-grained access control that could be used to that effect.
The benefit of 1. is that it is unintrusive. It sits in front of the data source and could in principle work for several types of data sources e.g. SQL, GraphQL... The benefit of 2. is that you do not need the proxy component and the configuration is native to the target system.
In any case, yes Graph databases lend themselves really well to ABAC because of the relationship between the different entities. In a way, relational databases have that too but perhaps not as obvious.
Related
Colleague of mine told me - we don't have a Business logic, we only have CRUD like GetById, GetBySearchTerm, GetByParentID....so I started to wondering about these words.
After reading about DDD, those methods are CRUD, they have a mechanism to fetch data (also store, update, delete...) based on some specific code (usually SQL).
If Business analyst say me: "We need to show data about specific customer".
In my opinion this IS (GetById) a Business process, GetById should be placed inside Business logic part of the application and it contacts repository to fetch a data. Repository with CRUD methods is responsible to persist data based on some criteria.
I Know this question can lead to debate to have repository with atomic methods (GetById, GetBySearchTerm, GetByParentiId...) but my question is only simple - are those methods are CRUD or Business logic methods.
The short answer is that you should not be querying your domain model for any reason other than domain operations that are part of the write / transactional side of things. This side of things is more interested in commands issued at your domain in order to do / perform operations.
Anything related to displaying data should come from as simple a query / read model as is possible.
If you find that your queries require domain interaction you probably have a scenario where you may need to tell your domain to do something and, once completed, you can request the data through the query side.
Not every application is a DDD application. Some applications are just simple CRUD
The business logic would be the part of the application where you validate inputs (like get by id and id is a number between 1 and 99999). This then is passed on to the repository for the actual query.
But if your application is really a crud application then trying to apply DDD isn't going to help you.
Those methods can't be the business methods at all. As a CQRS practitioner i would suggest you to have different models for command and query side. May be you create a different bounded context that serves the whole reading (Query) process (You can create anemic /DTOs here) and another domain model that serves pure business logic purpose.
You can take a look at my blog for command and query separation.
https://aspxsushil.wordpress.com/2015/10/18/command-and-query-object-pattern/
I wish to implement security on the data contained in a Neo4j database down to the level of individual nodes and/or relationships.
Most data will be available to all users but some data will be restricted by user role. I can add either properties or labels to the data that I wish to restrict.
I want to allow users to run custom cypher queries against the data but hide any data that the user isn't authorised to see.
If I have to do something from the outside then not only do I have to filter the results returned but I also have to parse and either restrict or modify all queries that are run against the data to prevent a user from writing a query which acted on data that they aren't allowed to view.
The ideal solution would be if there is a low-level hook that allows intercepting the reads of nodes and relationships BEFORE a cypher query acts on those records. The interceptor would perform the security checks and if they fail then it would behave as though the node or relationship didn't exist at all. i.e. the same cypher query would have different results depending on who ran it. And this would apply to all possible queries e.g. count(n) not just those that returned the nodes/relationships.
Can something like this be done? If it's not supported already, is there a suitable place in the code that I could add such a security filter or would it require many code changes?
Thanks, Damon
As Chris stated, it's certainly not trivial on database level, but if you're looking for a solution on application level, you might have a look at Structr, a framework on top of and tightly integrated with Neo4j.
It provides node-level security based on ACLs, with users, groups, and different access levels. The security in Structr is implemented on the lowest level possible, f.e. we only instantiate objects if the querying user has the approriate access rights.
All higher access levels like REST API and UI see only the records available in the user's context.
[1] http://structr.org, https://github.com/structr/structr
Consider a typical Breeze controller that limits the results of a query to entities that the logged in user has access to. When the browser calls SaveChanges, does Breeze verify on the server that the entities reported as modified are from the original set?
To put it another way, does the EFContextProvider (in the case Entity Framework) keep track of entities that have been handed out, so it can check against malicious data passed to SaveChanges? Or does BeforeSaveEntity need to validate that the user has access to the changed entities?
You must guard against malicious data in your BeforeSaveEntity or BeforeSaveEntities methods.
The idea that the EFContextProvider would keep track of entities that have already been handed out is probably something that we would NOT want to do because
The EFContextProvider would no longer be stateless, which was a design goal to facilitate scaling.
You would still need to guard against malicious data for "Added" entities in the BeforeXXX methods.
It is actually a valid use case for some of our users to "modify" entities without having first queried them.
I am using nodejs, and have been researching acl/authorization for the past week. I have found only a couple, but none seem to have all the features I require. The closest has been https://github.com/OptimalBits/node_acl, but I don't think it supports protecting resources by id (for example, if I wanted to allow user 12345 and only user 12345 to access user/12345/edit). Hence, I think I will have to make a custom acl solution for myself.
My question regarding this is, what are some pros and cons to storing roles (user, admin, moderator, etc.) under each user object, as opposed to creating another collection/table that maps each user with their authorization rules? node_acl uses a separate collection, whereas most of the other ones depend on the roles array in user objects.
By the way, I am using Mongodb at the moment. However I have not researched the pros and cons yet of using relational vs. nonrelational databases for authentication yet, so if let me know if your answer depends on that.
As I was typing this up, I thought of one thing. If I store roles in a separate collection, it is more portable. I would be able to swap out the acl system much more easily. (I think?)
The question here seems like it could be abstracted from "where should I store my roles" to "how should I store related information in Mongo (or NoSQL in general)". It's a relation vs non-relational modeling issue.
Non-Relational
Using Node + Mongo, storing the roles on the user will make it really easy to determine if a user has access to the feature, given that you can just look in the 'roles' property. The trade off is that you have lots of duplicate information ('user_read' could be a role on every user account) and if you end up changing that property, you'll need to update it inside every user object.
You could store the roles in their own collection and then store the id for that entry in the Roles collection on your User model, but then you'll still need to fetch the actual record from the collection to display any of it's information (though arguably this could be a rare occurrence)
Relational
Storing these in a relational DB would be a more "traditional" approach in that you can establish the relationships between the tables (via FKs / join tables or what not). This can be a good solution, but then you no longer have the benefits of using a NoSQL database.
Summary
If the rest of your app is stored in Mongo and has to stay there (for performance or whatever constraint) then you are probably better off doing it all in Mongo. Most of the advice I've come across says don't mix & match data stores, e.g. use one or the other, but not both. That being said, I've done projects with both and it can get messy but sometimes the pros outweigh the cons.
I like #DavidWelch answer, but I'd like to tackle the question from another perspective because the library mentioned gives the option to use a different data store entirely.
Storing roles in a separate data store:
(Pro) Can make the system more performant if you are using a faster data store. (More advantageous in distributed environments?)
(Con) You will have to ensure consistency between the two data stores.
General notes:
You can add roles/permissions such as 'blog\123' in acl. You can also give a user permissions based on verbs such as put, delete, get, etc..
I think it is easier to create a pluggable solution that does not depend on your storage implementation. Perhaps that is why acl does not store roles in the same collections you have.
If you choose to keep the roles in your own collection, consider adding them to a token (JWT). That way, you will not have to check your collection for every request that needs authorization.
I hope that helped.
I'm rather new at this, but I've come to understand the security risks of using Breeze to expose an IQueryable<>. Would someone please suggest to me some best practices (or merely some recommendations) for securing an IQueryable collection that's exposed in the JavaScript? Thanks.
I would not expose any data via IQueryable that should nto be sent to the client via a random query. So a projection could be exposed or a DTO.
I'm not sure if this answers your question tho ... What "security risks" are you worried about?
I second this question, too. But to add some specifics along the questions that Ward asked:
In securing queryable services, two traditional issues come to mind:
1) Vertical security: Which items is the currently logged in user (based on user identity or roles) NOT allowed to see in the UI. Those need to be removed from the queryable list. IMO, this can be done as part of the queryable ActionFilter magic by chaining some exclude logic on the returned IQueryable.
2) Horizontal security: Some models contain fields that are not appropriate for the logged in user to see (and/or edit). This is more difficult to handle as it's not a matter of just removing instances from the returned IQueryable. The returned class has a different shape and therefore can be handled either by the json formatter omitting the fields based on security (which AFAIK screws up breeze meta data) or you return a DTO in which case since the DTO doesn't exist in the metadata it's not a full life cycle (updatable) class? (I am asking this not stating it)
I would like to see either built-in support or easy to implement recipes for number 2). Perhaps some sample code to amend the client side metadata to make DTOs work perfectly fine comingled with model objects. The newset VS 2012 SPA templates (in the TodoList app) seem to push DTO variants of the model object both on the queryable and insert/update side. This is similar to the traditional MVC modelviews...
Finally - I'd add a request to auto-handling of the overposting security issue for inserts and updates. This is the reciprocal aspect of 2). Some users should not be able to edit certain fields.