Hacker News Reader

> This becomes especially tedious when you're fetching objects and lists of objects and the "resolvers" to fetch those objects need to mix in authorization rules in each resolver.

That largely depends on your existing architecture. Some of us have authorizations services, others have a separate database to store policies and others have authorization rules deep into their existing code base.

However, as I mention in the post, Hasura is great if you make the decision to use it early for a project, but it's not a luxury everyone has, and not a decision everyone will want to make even starting a new project.

> because it's not just about creating the right query to fetch data optimally, but it is also about making sure that it's handling data with the right authorization context of the current end-user.

You're absolutely right that its tricky. (A good example of this is Facebook building a viewer-aware entity layer for some of these reasons). Hasura makes this great as well, but again, many are not in a position so "simply use Hasura". That's why I quickly mention that the post will focus on existing/mature/complex codebases.

Thanks, this helps! (Also, hi Marc!)

Even though authorization systems or database policies exist outside the "data" database, quite often that information is used during the data fetch right? Let's say the user has certain properties and then those properties of the user and attributes of the data are used to define a constraint which is usually applied as the data fetch query is made.

For example, our goal at Hasura is to allow developers to bring values from external systems as well in their rules, so that the authorization rule doesn't exclusively depend on values coming in from the same database. This is what makes Hasura useful on existing systems (alongside your existing complex codebase), especially when you're looking for extremely high read performance or subscriptions for example. I do want to emphasize that Hasura is far more valuable (in a business sense) for our users on existing systems that for new systems!

I'd love to hear examples from your experience about the ratio of authz where it could be declarative vs where it was necessarily imperative in code. The "values" in the constraint specification can come from anywhwere, the viewer entity, another database, but the constraint is declarative.

What's it been like at GraphLQ API for github? Specifically, do you have a sense for how complex the authorization for the data models is beyond "declarative" properties of the data and the viewer itself?

> Hasura tackles this by providing a model level authorization layer

Why does Hasura need to know about the authorization model? Graphql.org's best practices guide[1] says authorization should be in the business layer and should be a single source of truth. In other words, GraphQL responses should be going through the same authorization module as REST or RPC responses.

[1] https://graphql.org/learn/thinking-in-graphs/#business-logic...

Hasura is designed to implement the entirety of the Business Logic Layer - it provides an interface directly on top of Postgres. Certainly this isn't appropriate for certain applications, though https://hasura.io/blog/custom-business-logic/ makes it very versatile. But for many line-of-business applications it's ideal.

That only works if your API access is all or nothing. The existing authorization tooling will just see everything as requests to `/graphql`. If you want per-query or even per-field permissions you need to do something inside the GraphQL layer.

What I didn't find out while trialing Hasura is if it's possible to declare your GraphQL API using code rather than the Hasura web GUI. I eventually gave up on it because I figured I couldn't store the configuration I was making as code in a git repo.

Your comment makes me think I was maybe wrong about that? Could you confirm and/or link to some docs about this aspect?

Everything in Hasura is configured declaratively. The web GUI is essentially just updating that configuration. There are a few options:

1. You use the GUI and then export/import the metadata

2. You can use the GUI and as you do, the GUI will keep incrementally updating the metadata configuration file and even create database migrations for you in your folder on your machine, kind of like an IDE

3. You can stop using the UI altogether, and just write the configuration by hand

Docs: https://hasura.io/docs/1.0/graphql/manual/migrations/index.h...

Also, feel free to ask around on our discord if you need help: https://discord.gg/hasura

This approach means one’s own deployments of Hasura can’t be immutable?

There's a docker image that can take a configuration file as input.

https://hasura.io/docs/1.0/graphql/manual/migrations/advance...

You can choose to bring in that configuration via a Kubernetes configmaps type thing, or by baking a new image for a release (like you would have done with your source code say).

Yep, that’s what I’ve been doing for my experiments with Hasura so far :) It just feels a little “off-piste”.

I’m experimenting with Hasura for an MVP. Like you I wanted to have the schema config in code and version controlled. The docs are very lacking for this use case.

However I think I’ve worked out a decent compromise:

- I start configuring the basics of my Hasura setup through the Admin GUI.

- I then use the CLI to download the metadata with the command `hasura metadata export`.

- Commit that to my repo.

- Using the existing metadata files as a template, make any changes when required.

- Use the cli-migrations docker image to apply my metadata on each deployment of Hasura (as detailed here: https://hasura.io/docs/1.0/graphql/manual/migrations/advance...)

Not sure if that’s the most efficient way to do it but it seems to work and it was pretty quick to setup.

All your configuration is stored in a YAML file (https://hasura.io/docs/1.0/graphql/manual/migrations/index.h...). You can do your work in the UI, and then export the YAML file to see what you did. You can/should commit that file. I don't believe its data structures are documented (perhaps at https://hasura.io/docs/1.0/graphql/manual/api-reference/inde...), but its format is pretty straightforward, especially once you've used the GUI for a while.

Have you looked at Slicknode? Slicknode allows you to declaratively define your application with schema etc. in your local code and then just sync with a CLI. It then does database migrations and updates/provisions a serverless API on AWS (with Lambda, Aurora Serverless).

That way you can leverage proper version control, merge feature branches, do copy paste of parts of models, reuse entire modules across projects, etc.

Slicknode: https://slicknode.com Github: https://github.com/slicknode/slicknode

(I'm from Slicknode)

Initially I was confused about the permissions in data approach, as it becomes harder to declaratively audit the current set of applied permissions. I’m not a massive fan of migrations in yaml generally (I do miss alembic) but it does the job. It occurs to me though that everything in data means you can do migrations atomically, including all the permissions changes.

Internally we have a little tool that dumps the current state of the permissions into a txt file that we commit in the repo. This makes it easier to get a snapshot of the permissions as well as compare what’s changed. The Hasura internal tables are pretty self explanatory so it only took an hour or so to knock up.

Ps, love hasura. I suspect we’ll end up running it in front of all our data layers eventually. If there was an easily hackable admin front end that sits over graphql I’d be interested in hearing about it. Leaning towards Forrest admin at the moment, but I’m still not 100% sold.

Nice to see guys from Hasura here! The product is pretty slick.

I scratch my head on this problem for quite a while. I would love things like database-to-GraphQL or even Datalog solutions.

But eventually, I found I still need to add another web endpoint on top of it to fix all the authorization logic, making things equally verbose like typical Web applications, defeating the purpose of using database-to-GraphQL solutions.

Having RBAC is Okayish for a lot of applications, but also not feasible for others. Usually ABAC or more expressive authorization rules are needed.

Do you have any thoughts on more expressive/powerful ways to tackle this issue?

I do - and I have some good experience on this issue.

I think at a minimum you need authentication, authorization, access controls (some of which are security filters), and of course auditing. You need to support RBAC, and also ABAC, roles/security groups, and then the access controls too.

The solution to row/cell level security (RLS) in most databases comes through projection and predicate-based filters and/or data obfuscation/masking/encryption. These are a form of access controls, and these access controls, in terms of (oversimplified) read/write controls on top of permission objects that are security filters.

These security filters may use attributes from a role, user or be defined within a permission object themselves and then granted to roles, users and/or groups of users.

One simple example - if the ultimate interface to other systems is running a SQL query on a remote system, then RLS would add a condition to the WHERE clause of the query that filtered the rows returned based on an attribute.

To get to cell-level protection (e.g. row/column) in a relational result, you need projection limitations (e.g. filtering the columns returned in a SELECT or obfuscating the data in those rows returned using data masking). The most advanced solutions encrypt the data in such a way as you can still use the data to join, but cannot see the source values due to the security filtering layer.

Hasura seems to be going down the path (I worked for a company that did the same) of integrating "data access firewall" type features into their product. It makes a lot of sense - as it is an interface layer, a lot of additional security can be baked in that goes above and beyond that of the actual DBMS behind it. This is especially needed in federated situations where you have heterogeneous platforms that differ in their security capabilities (as is the case with GraphQL and Hasura, trying to span multiple data sources).

You can even add security rules like.. preventing cross joins, preventing long running queries - basically you can address just about every concern DBAs have about letting people run queries directly against a DB.

Thanks :)

Hasura's authz system is actually like row-level security that can span attributes and values across data sources and "viewer" properties. We're gradually expanding these capabilities, but that's our roadmap.

Is there an ABAC policy that you tried with Hasura that didn't work? Would love to hear!

Does Hasura have any stack recommendations?

For example, here’s one user’s stack: https://news.ycombinator.com/item?id=22787313

Maybe not publicly, but they have really great documentation and examples for using Auth0, Apollo, and React. Made getting started way easier for me.

The Hasura authorization system is fantastic! It's definitely the icing on the Hasura cake.

Thank you! Terrific, helpful comment. Bookmarked.