How to deploy a fine grained authorization model?

[Hideman85]

The application requirements

• Offline first (browser storage ideally IndexedDB, synchronization, conflict detection/resolution)
• Fine grained authorization system (user management)
  • Having organization that contains members & teams
  • A team have some access to company data (read, write, admin)
  • A user inside a team inherits it's right from the team but can be also overwritten
  • A instance is attached to a organization
  • The team rights for a instance is inherited from the company right and can be overwritten
  • (same for user)

There is a sample GraphQL schema:

type User
@model
{
    id: ID!
    firstName: String!
    lastName: String!
    avatarUrl: Url
}

type Team
@model
{
    id: ID!
    name: String!
}

union Entity = User | Team

type Organisation
@model
{
    id: ID!
    name: String!
}

enum OrganisationRoleEnum {
    NO_ACCESS
    READ_ACCESS
    WRITE_ACCESS
    ADMIN_ACCESS
}

type OrganisationRole
@model
@key(fields: ["entityID", "organisationID"])
{
    entityID: ID!
    entity: Entity! @connection(fields: ["entityID"])
    organisationID: ID!
    organisation: Organisation! @connection(fields: ["organisationID"])
    teamID: ID
    team: Team @connection(fields: ["teamID"])
    role: OrganisationRoleEnum
}

type ObjectTypeA
@model
{
    id: ID!
    name: String!
}

type ObjectTypeB
@model
{
    id: ID!
    name: String!
}

type ObjectTypeC
@model
{
    id: ID!
    name: String!
}

# Take in consideration that each object types has different configurations and relations
union Instance = ObjectTypeA | ObjectTypeB | ObjectTypeC

enum InstanceRoleEnum {
    NO_ACCESS
    READ_ACCESS
    WRITE_ACCESS
    ADMIN_ACCESS
}

type InstanceRole
@model
@key(fields: ["instanceID", "entityID"])
{
    instanceID: ID!
    instance: Instance! @connection(fields: ["instanceID"])
    entityID: ID!
    entity: Entity! @connection(fields: ["entityID"])
    organisationID: ID
    organisation: Organisation @connection(fields: ["organisationID"])
    role: InstanceRoleEnum
}

Investigations
From what I've seen in the web we have two worlds, the first one is Apollo Client and the second one is DataStorage.

Apollo Client comes with lot of issues, if you use the out of the box appsync client you are stick to Apollo 2.X and can't use react hook. If you migrates to Apollo 3.X to have hooks support you only takes the two links from appsync (HTTP & WebSocket) but you face to offline capabilities issues.

DataStorage is relatively new but really promissing. It comes with a new way to sync data with the appsync, use IndexedDB as local storage and have a really easy syntax to use.

In terms of backend deployment we have AWS CDK and Amplify CLI.

AWS CDK you can programmatically generates the cloudformation stuff. You go through your folders architecture and you generates Table, AppSync, DataSource, Resolver... (everything).

Amplify CLI come with GraphQL transformations that take the job of generating the stuff for you. A good collection of directives but a very basic authorization system.

The two solution that I really like and would use for our team because it's easier to use would be DataStorage with Amplify CLI because once you setup your stuff you don't need to care about the needed stuff for deployment but I encounter some lack in terms of authorization.

How to deploy a fine grained authorization model?
From what I've seen I can use either a Lambda authorizer or a Pipeline resolver for doing the needed check for the authorization.

The use case is I need to check the access right for each items in a query list, for a desired mutation and provide the uacpdate to only the subscribers that have the right to see the object.

My question is how do I do that with Amplify CLI? can I use the actual @auth? can I write a custom one? how do I do for the subscriptions? and which of Lambda authorizer or pipeline resolver is the most optimized with appsync?

[renebrandel]

Hi @Hideman85 - I think you're looking for the @auth directive: https://docs.amplify.aws/cli/graphql-transformer/directives#auth

And in particular around authorizing subscriptions, check it out here: https://docs.amplify.aws/cli/graphql-transformer/directives#authorizing-subscriptions

In addition, the way that these directives work, is that they get translated into resolvers, which you can learn on how to customize or overwrite here: https://docs.amplify.aws/cli/graphql-transformer/resolvers

LMK if this answers all your questions. Feel free to re-open this issue if this doesn't fully address your concern.

[Hideman85]

Whoua a directive @auth existe very nice... of course I made a long explanation just because I'm not able to read a doc.

To let you know at the best what you can do with the @auth is authenticate your user with cognito but not the fine grained user management.

@renebrandel I've also seen that we can override mapping templates (or even resolver if you also override the cloudformation template) but the question is how can I do it automatically/generated because of course firstly I don't really want to rewrite the DynamoDB stuff that has been generated nor copy paste my authorization stuff to all mapping templates because what would be the value to use Amplify CLI if I need to override everything myself.

Last point, it is completely useless to close that topic as quickly like you did just because you partially replied to my post, I just want to let you know that there is a lot of questions how to manage the case of multi tenant app but there is no reel response not guide or documentation.

So to conclude please take the time before replying because I took time to explain and provide a sample for my case that would also be useful to others.

[renebrandel]

Happy to re-open the issue. From the issue itself, it wasn't clear to me if you've had the chance to take a look at @auth. I think I misunderstood your question on this then.

I believe I missed the fact that you want to have the "enabled operations" also be dynamic? Am i correct?

If not, then these scenarios:

Having organization that contains members & teams
A team have some access to company data (read, write, admin)
A user inside a team inherits it's right from the team but can be also overwritten
A instance is attached to a organization
The team rights for a instance is inherited from the company right and can be overwritten
(same for user)

should be addressed by Dynamic Group Authorization and having the organizations be Cognito User Pool groups.

[RossWilliams]

i Don’t think dynamic group auth works with the requirement for subscriptions

[Hideman85]

HI @renebrandel no problem then I can try to reformulate.

In my case we have kind of sensitive data and the authorization on that data is managed by the users itself. So let's take that case:

I'm a UserA member of the TeamA inside the OrganizationA
I start a new document and dependently of that document I would authorize:

• my whole Team in Edit access (attach EDIT role to this instance and the team instance)
• my Organization to have Read write.

For a second document I can decide something else:

• disallow my Organization to see that document
• my Team wouldn't have access too
• but UserB from my Team will collaborate with me and have EDIT access

So at the end the authorization for a object is not static and can also evolve.
I've seen Cognito groups but I don't really think that could solve my issue due to the dynamic aspect.

Currently the roles are saved in DB because it's more convenient and to authorize a action I need to fetch multiple roles to determine is the user has access or not.
The good point of using a Table for that is that this table can also be sync in frontend for viewing the persons that have access to a document.

So from what I've seen for doing my check with AppSync I have two options either a custom Lambda Authorizer (that I should be able to parametrize by giving the action type Read/Edit and the Type) or generates Pipeline resolvers.
The best I think would be to have a custom directive like @autorize(level: READ) and inject the needed stuff into the current generation (because @auth "mainly" give the feature to authenticate a logged in user but in that case does not permit to authorize the action).

And the last point is also how to proceed with subscriptions because it can be a bit tricky for example:

You have already sync a ObjectA because you have Read access. Now the owner do the update to remove your access.
The consequences would be:

• For all user that have still access to the document they should get the information that a user access has been removed
• The user that just be denied should get the information remove from your store the ObjectA and attached roles
• And of course that information should not be sent to other subscribers that don't have any access to that object

Let me know if this helps you to get my case and so why I'm stuck.

[Hideman85]

I think the best way is using pipeline resolver. I made a try to implement generic functions for my role checking (https://github.com/Hideman85/TestApp/tree/master/RoleCheckPipeline) the issue is how can I wrap current generated mapping templates inside a function in order to use them inside a pipeline?

Because this role checking is recurrent on my model I would prefer if this can also be generated with GraphQL transformer.

[Hideman85]

Okey I made some progress on this by starting creating a custom GraphQL transformer there is the detail on my experimental testing app: https://github.com/Hideman85/TestApp#investigations--tries

I have still the open questions about managing subscriptions and having efficient way to list items that the user has access to.

[Hideman85]

I don't understand how everything works together...

I made a lot of progress by making a custom GraphQL transformer for applying deeper transformations. I now able to build pipeline revolvers for having different pipeline functions doing role checking.

And now becomes the time to finally deploy my stuff:

CREATE_FAILED AWS::AppSync::Resolver The Pipeline resolver cannot have datasource.

Okey let's delete the datasource...

CREATE_FAILED AWS::AppSync::Resolver Data source name must be provided when specifying SyncConfig on the resolver.

But if I understand well SyncConfig configure the conflict resolution and this is use by DataStore right?

The doc is completely unclear on that stuff and does not even mention the mutual exclusion.

Does any one has an understanding of how everything works together?

For an external point of view it's look like there is several teams working on different features but no communication (nor explanation/documentation) for having everything working together. I have to myself deep dive in the code of both amplify-cli and amplify-js doing tries with CloudFormation to get pieces of information. This is very frustrating and loss of time.