Auditing task

[jeroenvisser101]

While working on this, I was thinking of a possibility of having a command that outputs all the objects/queries that a role has access to. This might not be completely possible, because some rules might be dependent on the object/scope/actor. Do you internally have a way to audit roles and authorization?

[gabrielpra1]

That's a great idea! We don't have nothing like that internally, we pretty much rely on our tests, so for example for a query that is admin only we have tests asserting it succeeds for admins and fails for regular users.

However, we did some pen test preppings already and it was a manual process, where I think a command like that would help.

I agree with you that the output may not be 100% accurate, because in the end it's up to the functions role_authorized? and has_user_access? to implement your authorization logic, which may involve scoping. This makes it a bit harder to output all objects/queries that a role has access to, but shouldn't be impossible.

One way I can think of doing that is using https://hexdocs.pm/absinthe/Absinthe.Schema.html#types/1 to list all the types defined in the schema and then using the ObjectAuthorization functions on them for each defined role.

It would be trickier for QueryAuthorization, because the authorization rule is not a property of the queries, but rather a middleware. Any ideas here?

[jeroenvisser101]

I agree with you that the output may not be 100% accurate, because in the end it's up to the functions role_authorized? and has_user_access? to implement your authorization logic, which may involve scoping. This makes it a bit harder to output all objects/queries that a role has access to, but shouldn't be impossible.

For this, I thought it might be good to output them separately, but with the rule or the callback that would be executed. It would then be up to the auditor to decide if that is desired or not.

One way I can think of doing that is using https://hexdocs.pm/absinthe/Absinthe.Schema.html#types/1 to list all the types defined in the schema and then using the ObjectAuthorization functions on them for each defined role.

Yeah, this sounds like a good idea, optionally showing (all fields) or (has private fields)

It would be trickier for QueryAuthorization, because the authorization rule is not a property of the queries, but rather a middleware. Any ideas here?

The field types do have a list of middleware, and we already use them to check if the middleware is added correctly. We could use this to check any configuration added to it too, although it probably won't be trivial at all.