I have question about the separation of the publishers.
If we want the publishers to manage only their own API, can we restrict them to see/update APIs published by other publishers? Or do we need to create a separate tenant?
In theory - there's possibility to restrict API visibility to a specific role, but there's a way around. If a publisher is displaying statistics - the statistics shows records for APIs which should not be visible to the user without the specific restriction role. Clicking on a statistics records (e.g. number of subscriptions) the user will gain access to edit API which should not be seen. So - now we have security by obscurity.
For the store and gateway - indeed the role is checked. Here I'm considering the publishers
By design, all APIs in a single tenant is visible to every publisher in that tenant. Role-based visibility is applicable only to the store.
If you create multiple tenants, you can isolate APIs. If you want to access all of them in the store, you can set the API visibility to "public".
Related
Users have different permissions on different resources(They are called sites in our app) (which can grow over time). Also, there is a separate microservice that stores sites information in a separate dynamodb table. Permissions are calculated based on the groups a user is in. The backend will need to check for permissions always before an action is performed. I am looking to find the most efficient way to store permissions so that the permission check won't be redundant/taxing on the application.
So far our backend is all REST microservices. These are the options I have considered:
JWT Token: Do not wish to store permission on each resource in JWT token because the resource list will grow and it may hit the 8Kb header limit. That is risky.
DynamoDB: If we were to store permissions of each user in a DynamoDB table that is owned by the User microservice, that will mean a REST call to the endpoint from every other microservice which creates tight coupling between other microservices and user microservice and also adds an additional network trip.
DAX: Same issue as above
Elastic cache: Is it not managed so we will need to introduce a VPC in the application which I personally don't like.
API gateway caching: I guess it will do Authorization caching i.e requests with the same JWT token will be able to leverage the cache. Our JWT tokens are only cached for 5 minutes though so I am guessing it will hit the DB and calculate every 5 minutes. Also, this will again mean a REST call to the endpoint from every other microservice which creates tight coupling between other microservices and user microservice(that will have this endpoint) and also adds an additional network trip
Custom authorizer: Caches the policy for 5 minutes but we want the change in permissions to be real-time. Also, we have a strict policy that DynamoDB tables are owned by their respective microservices and that we do not read/write to DynamoDB from outside of the service. Since the authorizer is not going to be writing to the table, it will not be the owners and thus becomes dependent on a microservice that owns the table.also leads to cyclic dependency because all our microservices depend on the custom authorizer.
Am I missing something? What's the best way to handle this?
I am considering creating a user pool per tenant based on the recommended multi-tenant architecture (for ex: https://aws.amazon.com/quickstart/saas/identity-with-cognito/)
The rest of the resources in the application are going to be using pooled resources (for ex: API gateway, dynamoDB tables). Considering the silo model just for the Cognito/auth part of the application.
Application requirements:
Subdomain per tenant i.e. tenant1.company.com an tenant2.company.com
A user can belong to multiple tenants(Forex: User A can be in tenant1 and tenant2)
Need to be able to list all users for a particular tenant
Data residency restrictions for personally identifiable information
I believe If I was to use the same Cognito user pool for all tenants, I could force users to use a different email for a new tenant i.e abc#tenant1.com for Tenant1 and abc+tenant2#tenant2.com for Tenant2.
But to list all users for a particular tenant, I imagine the same user pool for all tenants will not work as tenant_id will be a custom attribute.
I could also ensure data residency restrictions by creating a user pool per tenant. However, how do I handle regional failover in this case?
Also, Is subdomain per tenant supported with this approach?
I hear that the user pool per tenant is constant pain and should be avoided. What are some of the pain points?
For my use case, Does it look like that I should opt for an AuthZ provider instead like auth0 or authress?
I am new to AWS and making some large application with microservice architecture. I am using Cognito user + identity pools for authorization. Organizations have branches, branches have positions, e.g Project Manager, Financial Manager, and a user belong to one of these branches and positions. Users are stored in the Cognito User Pool. I've EC2 and RDS for organization microservice and I'm going to use AWS API gateway with IAM Role-Based Access Control to communicate between microservices but how can I make a relationship between the organization and user microservices?
I was going to use Cognito custom attributes, e.g custom:branch=branchId but if I needed to get the users of this branch that would be impossible. From Cognito docs:
Custom attributes are not searchable.
Should I use DynamoDB table, for relation cognito_user_id | branch_id, or what's the better approach?
How to get single branch users, how to get single organization users and where to write this code ? AWS lambda with DynamoDB ?
If you have no restriction to add table on RDS at organization micro-service, I will say do not use dynamodb as it is an extra component and your system supports relational better than NoSQL. Besides, one more prerequisite for dynamodb is one must be aware of data access pattern.
Create Organizations and Branchs table having one-to-many relation as seperate micro-service. User will be assigned to Branch.
You should write those shared logic to lambda as a service and that lambda will be called by both org and user services. I know that will cost extra integration effort. However, it is far better than adding new service like dynamodb.
I am reading about multi-region architecture considerations.
Our reasons for moving to a multi-region architecture are pretty much the same as everyone else's:
Reducing latency for customers that are in different continents (EU, US, Asia, Africa)
Being in compliance with their data storage needs
Enable regional failover
We will be using Cognito pools and dynamo DB for data storage. Global Cognito pools do not seem to be a thing as Global DynamoDB tables. For a multi-tenant system SAAS system with tenants in different continents, Should the user pool be generated per region or per tenant? In this video here, https://www.youtube.com/watch?v=kmVUbngCyOw&feature=emb_logo&ab_channel=AmazonWebServices , it is recommended to have a pool per tenant. I fail to see many advantages for it though.
Is it instead a good idea to have a user pool per region instead?
The video also suggests having identity pools in addition to user pools. Why should that be the case in a multi-tenant system?
if I was to ensure data residency in the same region as the tenants in dynamodb as well, how should that be handled? and how should active-active architecture
We also need to host the application URLs like tenant1.companydomain.com for all of the tenants. what's the best way to go about it?
This question is too large, but anyway.
1. Reducing Latency
Unless you are calling Cognito APIs often Authentication is really the main concern here, but if you are using a long lived refresh token they shouldn't have to authenticate all the time so it wont be a massive problem. However a bigger problem is if you only use the one pool, you will have to consider that you sometimes need some Cognito Integration to be in the same region, such as a Cognito Authorizer on an API gateway. But you could write your own Lambda Authorizer to get around this.
2. Being in compliance with their data storage needs
This may force your hand in the User Pool decision, although you can always do the option of keeping your identity and your details in separate storage, making use of Lambda Triggers in the User Pool to sync data.
3. regional failover
I don't understand this in regards to your question about how many User Pools to use. If you use one in each region, then you will need to duplicate it in another region if you wanted to add your own failover capability. If you had only 1 User Pool you would have to duplicate only 1. I've never heard of anybody duplicating a User Pool to another region, this conflicts with what you wanted in 2.. If you've used integrations too, you cannot default to another User Pool you'd have to default to a whole new instance of the website, not just the User Pool. You'd have to also create your own Triggers which would do this for you.
Should the user pool be generated per region or per tenant?
This honestly is a large question in itself, we build a multi-tenant SAAS platform and I can honestly say User Pool per tenant would be a nightmare. 1 User Pool is easiest (as for example with the API GW Integration you cannot select multi user pools). You can use an app client per tenant and customize the signin for that tenant and give each tenant their own sub-domain.
4. Is it instead a good idea to have a user pool per region instead?
Other more meaningful questions are maybe? Do I want users to have the same identity in different regions? Do I want a user to be able to use more than on region? etc. Think about different websites that have this feature. For example Amazon you have a global identity and you can switch your store you are visiting, you need to specify requirements.
5. The video
Sorry not going to watch the video, but you can have an identity pool select permissions from the token (i.e. the group permissions for that user in Cognito). That covers 99% of use cases start from there.
6. if I was to ensure data residency...
Out of the box this is how the cloud is unless you specify a global resource everything is per region so you do nothing. You cannot have both data residency and regional failover at the same time.
I'm building a Django rest framework based service which has some complicated permissions. So far, my microservices stack looks like this:
/auth/ JWT authentication service
/users/ - adding users, adding them to different services
/new-service/ - needs authorization
Users database is shared by auth and users read-only, and read/write respectively. new-service has no access to this database but the challenges consist of:
user can be in multiple groups specific to that service
user could have read-only access to one item in one of the groups
user could be allowed to create new users with access to one of the groups
users have different roles in the service, but we still need to allow for access like the read-only one listed
Groups are used not to manage users, but to provide access to things. Like GitLab groups provide access to GitLab projects.
If I put all the permissions in the users service, my new service has to talk to that one and it will get chatty. It seems like there has to be a data divide, but I'm not sure exactly where to put it. Conversely, should the django-rest-framework service even have a shadow entry of the user account in it's db? Advice appreciated. I'm feeling like I'm having a slow day.