2018-06-27 16:11:32 +03:00
|
|
|
module Hasura.RQL.DDL.Permission.Internal where
|
|
|
|
|
2020-08-27 19:36:39 +03:00
|
|
|
import Hasura.Prelude
|
|
|
|
|
2020-11-02 14:50:40 +03:00
|
|
|
import qualified Data.HashMap.Strict as M
|
|
|
|
import qualified Data.Text as T
|
2020-08-27 19:36:39 +03:00
|
|
|
|
2020-11-02 14:50:40 +03:00
|
|
|
import Control.Lens hiding ((.=))
|
2018-06-27 16:11:32 +03:00
|
|
|
import Data.Aeson.TH
|
|
|
|
import Data.Aeson.Types
|
2021-06-09 22:42:37 +03:00
|
|
|
import Data.Kind (Type)
|
2020-10-21 19:35:06 +03:00
|
|
|
import Data.Text.Extended
|
2020-10-27 16:53:49 +03:00
|
|
|
|
2020-11-02 14:50:40 +03:00
|
|
|
import Hasura.Backends.Postgres.Translate.BoolExp
|
2021-05-11 18:18:31 +03:00
|
|
|
import Hasura.Base.Error
|
2018-06-27 16:11:32 +03:00
|
|
|
import Hasura.RQL.Types
|
2020-10-21 19:35:06 +03:00
|
|
|
import Hasura.Server.Utils
|
|
|
|
import Hasura.Session
|
2018-06-27 16:11:32 +03:00
|
|
|
|
|
|
|
|
2021-02-14 09:07:52 +03:00
|
|
|
convColSpec :: FieldInfoMap (FieldInfo b) -> PermColSpec b -> [Column b]
|
2018-06-27 16:11:32 +03:00
|
|
|
convColSpec _ (PCCols cols) = cols
|
2019-09-19 07:47:36 +03:00
|
|
|
convColSpec cim PCStar = map pgiColumn $ getCols cim
|
2018-06-27 16:11:32 +03:00
|
|
|
|
|
|
|
permissionIsDefined
|
2020-10-22 23:42:27 +03:00
|
|
|
:: Maybe (RolePermInfo backend) -> PermAccessor backend a -> Bool
|
2018-06-27 16:11:32 +03:00
|
|
|
permissionIsDefined rpi pa =
|
2018-08-27 14:50:18 +03:00
|
|
|
isJust $ join $ rpi ^? _Just.permAccToLens pa
|
2018-06-27 16:11:32 +03:00
|
|
|
|
|
|
|
assertPermDefined
|
2020-12-01 18:50:18 +03:00
|
|
|
:: (Backend backend, MonadError QErr m)
|
2018-06-27 16:11:32 +03:00
|
|
|
=> RoleName
|
2020-10-22 23:42:27 +03:00
|
|
|
-> PermAccessor backend a
|
|
|
|
-> TableInfo backend
|
2018-06-27 16:11:32 +03:00
|
|
|
-> m ()
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
assertPermDefined role pa tableInfo =
|
2018-06-27 16:11:32 +03:00
|
|
|
unless (permissionIsDefined rpi pa) $ throw400 PermissionDenied $ mconcat
|
2020-12-17 14:37:16 +03:00
|
|
|
[ "'" <> tshow (permAccToType pa) <> "'"
|
2021-05-18 16:06:42 +03:00
|
|
|
, " permission on " <>> tableInfoName tableInfo
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
, " for role " <>> role
|
2018-06-27 16:11:32 +03:00
|
|
|
, " does not exist"
|
|
|
|
]
|
|
|
|
where
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
rpi = M.lookup role $ _tiRolePermInfoMap tableInfo
|
2018-06-27 16:11:32 +03:00
|
|
|
|
|
|
|
askPermInfo
|
2020-12-01 18:50:18 +03:00
|
|
|
:: (Backend backend, MonadError QErr m)
|
2020-10-22 23:42:27 +03:00
|
|
|
=> TableInfo backend
|
2018-06-27 16:11:32 +03:00
|
|
|
-> RoleName
|
2020-10-22 23:42:27 +03:00
|
|
|
-> PermAccessor backend c
|
2018-06-27 16:11:32 +03:00
|
|
|
-> m c
|
|
|
|
askPermInfo tabInfo roleName pa =
|
2020-12-01 18:50:18 +03:00
|
|
|
(M.lookup roleName rpim >>= (^. permAccToLens pa))
|
2020-11-26 16:57:03 +03:00
|
|
|
`onNothing`
|
|
|
|
throw400 PermissionDenied
|
|
|
|
(mconcat
|
2021-05-18 16:06:42 +03:00
|
|
|
[ pt <> " permission on " <>> tableInfoName tabInfo
|
2020-11-26 16:57:03 +03:00
|
|
|
, " for role " <>> roleName
|
|
|
|
, " does not exist"
|
|
|
|
])
|
2018-06-27 16:11:32 +03:00
|
|
|
where
|
|
|
|
pt = permTypeToCode $ permAccToType pa
|
2019-07-22 15:47:13 +03:00
|
|
|
rpim = _tiRolePermInfoMap tabInfo
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2021-06-09 22:42:37 +03:00
|
|
|
|
|
|
|
newtype CreatePerm a b = CreatePerm (WithTable b (PermDef (a b)))
|
|
|
|
deriving newtype (Show, Eq, FromJSON, ToJSON)
|
2018-06-27 16:11:32 +03:00
|
|
|
|
|
|
|
data CreatePermP1Res a
|
|
|
|
= CreatePermP1Res
|
|
|
|
{ cprInfo :: !a
|
|
|
|
, cprDeps :: ![SchemaDependency]
|
|
|
|
} deriving (Show, Eq)
|
|
|
|
|
|
|
|
procBoolExp
|
2021-02-14 09:07:52 +03:00
|
|
|
:: (QErrM m, TableCoreInfoRM b m, BackendMetadata b)
|
2020-12-28 15:56:00 +03:00
|
|
|
=> SourceName
|
2021-02-14 09:07:52 +03:00
|
|
|
-> TableName b
|
|
|
|
-> FieldInfoMap (FieldInfo b)
|
|
|
|
-> BoolExp b
|
|
|
|
-> m (AnnBoolExpPartialSQL b, [SchemaDependency])
|
2020-12-28 15:56:00 +03:00
|
|
|
procBoolExp source tn fieldInfoMap be = do
|
2021-04-19 15:16:10 +03:00
|
|
|
abe <- annBoolExp parseCollectableType tn fieldInfoMap $ unBoolExp be
|
2020-12-28 15:56:00 +03:00
|
|
|
let deps = getBoolExpDeps source tn abe
|
2018-11-16 15:40:23 +03:00
|
|
|
return (abe, deps)
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2020-10-27 16:53:49 +03:00
|
|
|
getDepHeadersFromVal :: Value -> [Text]
|
2019-02-11 15:45:30 +03:00
|
|
|
getDepHeadersFromVal val = case val of
|
|
|
|
Object o -> parseObject o
|
|
|
|
_ -> parseOnlyString val
|
2018-06-27 16:11:32 +03:00
|
|
|
where
|
2019-02-11 15:45:30 +03:00
|
|
|
parseOnlyString v = case v of
|
2018-08-29 08:47:13 +03:00
|
|
|
(String t)
|
2020-04-24 12:10:53 +03:00
|
|
|
| isSessionVariable t -> [T.toLower t]
|
2018-08-29 08:47:13 +03:00
|
|
|
| isReqUserId t -> [userIdHeader]
|
|
|
|
| otherwise -> []
|
|
|
|
_ -> []
|
2018-11-16 15:40:23 +03:00
|
|
|
parseObject o =
|
2019-02-11 15:45:30 +03:00
|
|
|
concatMap getDepHeadersFromVal (M.elems o)
|
|
|
|
|
2020-11-02 14:50:40 +03:00
|
|
|
getDependentHeaders :: BoolExp b -> [Text]
|
2019-02-11 15:45:30 +03:00
|
|
|
getDependentHeaders (BoolExp boolExp) =
|
|
|
|
flip foldMap boolExp $ \(ColExp _ v) -> getDepHeadersFromVal v
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2021-06-09 22:42:37 +03:00
|
|
|
data DropPerm (a :: BackendType -> Type) b
|
2018-06-27 16:11:32 +03:00
|
|
|
= DropPerm
|
2020-12-28 15:56:00 +03:00
|
|
|
{ dipSource :: !SourceName
|
2021-02-14 09:07:52 +03:00
|
|
|
, dipTable :: !(TableName b)
|
2020-12-28 15:56:00 +03:00
|
|
|
, dipRole :: !RoleName
|
2021-02-14 09:07:52 +03:00
|
|
|
} deriving (Generic)
|
2021-06-09 22:42:37 +03:00
|
|
|
deriving instance (Backend b) => Show (DropPerm a b)
|
|
|
|
deriving instance (Backend b) => Eq (DropPerm a b)
|
|
|
|
instance (Backend b) => ToJSON (DropPerm a b) where
|
2021-02-14 09:07:52 +03:00
|
|
|
toJSON = genericToJSON hasuraJSON{omitNothingFields=True}
|
2020-12-28 15:56:00 +03:00
|
|
|
|
2021-06-09 22:42:37 +03:00
|
|
|
instance (Backend b) => FromJSON (DropPerm a b) where
|
2020-12-28 15:56:00 +03:00
|
|
|
parseJSON = withObject "DropPerm" $ \o ->
|
|
|
|
DropPerm
|
|
|
|
<$> o .:? "source" .!= defaultSource
|
|
|
|
<*> o .: "table"
|
|
|
|
<*> o .: "role"
|