I have been working with a US client to build a first-of-its-kind app for managing medical consents. It falls under HIPAA compliance and it’s paramount that we do not allow unauthorized access to user data. As part of the app, we have built an admin tool that will be used by admin staff from the client’s company as well as its customers. Essentially, we have three roles in the admin tool: : these are admin staffs from the client’s company. This group of user have access to all the functionalities, including adding new tenants. Admin : these are admin staffs from the client’s customers which are typically Health Information Exchanges (HIEs). An HIE would collaborate with multiple healthcare providers (e.g. hospitals, pharmacies) to facilitate data exchange between them. An HIE’s admin staffs should therefore have access to information related to their own organization as well as any healthcare providers that it collaborates with. Tenant : these are admin staffs from the healthcare providers that collaborate with the HIEs above. They only have access to information related to their own organization as well as its patients. Service Area This is a drastic oversimplification of the entities that are involved, but it serves to illustrate the different tiers of access that we need to model: users can access everything. Admin users can access its own data plus data that belongs to its subsidiary service areas. Tenant users can access only its own data. Service Area The good news is that AppSync makes it easy to implement group-based authentication with Cognito. Which is why we decided to go with AppSync over API Gateway for this project. one of the reasons However, modelling these overlapping actions in the GraphQL schema was still a big challenge in and of itself. The problem The root of the problem is that there are many overlapping actions that each group can perform. For example, users can add new service areas and associate them with any . A user can also add new service areas, but cannot associate the service area with anyone but itself. Admin Tenant Tenant As such, we need two separate mutations with different inputs and lock down their access to different Cognito groups. As you can see from below, as a user, I only have access to the mutation where I cannot override the the service area is associated with. Tenant addServiceAreaAsTenant tenantId Mutation {
  add : ServiceArea!
  @aws add : ServiceArea!
  @aws } type ServiceAreaAsAdmin( : ID!, : String!) tenantId name _auth( : [ ]) cognito_groups "Admin" ServiceAreaAsTenant( : String!) name _auth( : [ ]) cognito_groups "Tenant" As we add more and more queries and mutations this quickly becomes messy. There are a lot of duplications for the clauses, and it’s not easy to see at a glance what each group of users can do. Also, we have to get increasingly creative about how we name these queries and mutations in order to distinguish them from one another. @aws_auth(cognito_groups: …) Copy-and-paste errors can easily creep in (it almost did), and it’s also confusing for the frontend developers to keep track of which queries and mutations they should use for which users. { : Query : Mutation
} { ( : ID!): !
  @ ( : [ ]) ( : ID!): !
  @ ( : [ ]) : !
  @ ( : [ ]) ( : ID!): !
  @ ( : [ ]) : !
  @ ( : [ ])
} { ( : String!): !
  @ ( : [ ]) ( : ID!, : String!): !
  @ ( : [ ]) ( : String!): !
  @ ( : [ ]) ( : String!): !
  @ ( : [ ]) ( : String!): !
  @ ( : [ ])
} { : ID! : String!
} { : ID! : String! : ID!
} schema query mutation type Query getTenantById id Tenant aws_auth cognito_groups "Admin" getServiceAreaById id ServiceArea aws_auth cognito_groups "Admin" getMyProfileAsTenant Tenant aws_auth cognito_groups "Tenant" getMyServiceArea id ServiceArea aws_auth cognito_groups "Tenant" getMyProfileAsServiceArea ServiceArea aws_auth cognito_groups "ServiceArea" type Mutation addTenant name Tenant aws_auth cognito_groups "Admin" addServiceAreaAsAdmin tenantId name ServiceArea aws_auth cognito_groups "Admin" updateMyProfileAsTenant name Tenant aws_auth cognito_groups "Tenant" addServiceAreaAsTenant name ServiceArea aws_auth cognito_groups "Tenant" updateMyProfileAsServiceArea name ServiceArea aws_auth cognito_groups "ServiceArea" type Tenant id name type ServiceArea id name tenantId Using nested Query/Mutation types To make it easier to scale the complexity of this project, we decided to encapsulate each group into its own and types. Query Mutation As you can see below, each group of users gets its own and types. Access is controlled in a single place, and it’s easy to see everything a group of users can do at a glance. Also, we don’t need to rely on naming conventions on overlapping actions anymore. Query Mutation schema { 
  query: Query
  mutation: Mutation
} Query {
  asAdmin: AdminQuery
  @aws_auth(cognito_groups: [ ])
  
  asTenant: TenantQuery
  @aws_auth(cognito_groups: [ ])

  asServiceArea: ServiceAreaQuery
  @aws_auth(cognito_groups: [ ])
} Mutation {
  asAdmin: AdminMutation
  @aws_auth(cognito_groups: [ ])

  asTenant: TenantMutation
  @aws_auth(cognito_groups: [ ])

  asServiceArea: ServiceAreaMutation
  @aws_auth(cognito_groups: [ ])
} AdminQuery {
  getTenant(id: ID!): Tenant!
  getServiceArea(id: ID!): ServiceArea!
} TenantQuery {
  getMyProfile: Tenant!
  getMyServiceArea(id: ID!): ServiceArea!
} ServiceAreaQuery {
  getMyProfile: ServiceArea!
} AdminMutation {
  addTenant(name: String!): Tenant!
  addServiceArea(tenantId: ID!, name: String!): ServiceArea!
} TenantMutation {
  updateMyProfile(name: String!): Tenant!
  addServiceArea(name: String!): ServiceArea!
} ServiceAreaMutation {
  updateMyProfile(name: String!): ServiceArea!
} Tenant {
  id: ID!
  name: String!
} ServiceArea {
  id: ID!
  name: String!
  tenantId: ID!
} type "Admin" "Tenant" "ServiceArea" type "Admin" "Tenant" "ServiceArea" type type type type type type type type This makes the GraphQL schema much easier to maintain as the project continues to grow, without breaking the existing security model. As an user, I’m able to perform the queries and mutations specified in the and types. Admin AdminQuery AdminMutation As a user, the of my organization is captured as a custom attribute on my Cognito user. Tenant tenantId The queries and mutations for a user never accept as an argument, and it’s always taken from . This ensures tenants can only access its own data, without us having to litter our code with custom validation logic. Tenant tenantId $context.identity And since I don’t belong to the group, I’m not authorized to access its queries and mutations. Admin But I’m able to act on my own data, as well as access data for service areas that are associated with my organization. And the same goes to users, whose access will be restricted to its own data. Service Area In addition to this, HIPAA compliance also requires us to have an audit trail of the data a user has accessed. So we also had to implement full request-response logging, which sadly does not come out-of-the-box with AppSync. We’ll dive into this particular topic in a later post. In the meantime, if you want to see how this hierarchical model works for yourself, then check out and try it out. this repo If you want to learn GraphQL and AppSync with a hands-on tutorial then please check out my where you will build a Twitter clone using a combination of AppSync, Lambda, DynamoDB, Cognito and Vue.js. You will learn about different GraphQL modelling techniques, how to debug resolvers, CI/CD, monitoring and alerting and much more. new AppSync course Previously published at https://theburningmonk.com/2020/08/how-to-model-hierarchical-access-with-appsync/

Amazon

Twitter

Ask me for help about serverless

Read My Stories

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Modeling Hierarchical Access With AppSync In 3 Simple Steps

Too Long; Didn't Read

Companies Mentioned

Yan Cui

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Modeling Hierarchical Access With AppSync In 3 Simple Steps

Too Long; Didn't Read

Companies Mentioned

Yan Cui

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES