For example:
Accounts Microservice - Handles authentication and stores email, password.
Profile Microservice - Fetched when displaying identity information name, age, gender, address, etc.
Or is this overkill and just a single Users Microservice would suffice?
Related
I'm building an Angular 11 app with AWS Amplify as the backend which uses Appsync, dynamodb and a managed GraphQL API. I'm using the cognito user pools to authenticate. Authentication works neatly, but I am really confused about how to go about doing role-based authorization. I haven't done this using cognito before but I have a strategy in mind that should theoretically work out. I would like advice on if there is a better way to do this:-
Requirements:-
The app will be used by members of organisations that we are partnering with. Every member will be tied to an organisation. So organisations have their own table and so do members. Members of an organisation can only access content related to their organisation. So right after authentication, the client app has to get the id of the organisation the current user belongs to and also the role they play in that organisation to show/hide UI resources and filter data. Which UI resources they can access depends on the role they play in that organisation and of course the data they see there has to be restricted to what is related to their organisation.
This is a controlled beta release of our application, so Cognito user pools uses email and password to login. No other login option is provided for the sake of keeping things simple. User sign up is not possible. Only admins can add new users for now.
How I plan to do this:-
Cognito API is integrated to the client and the admin will add the
new members from the client UI and the client will add them to the
cognito user pool via the Cognito API
While adding the new members, the admin will specify which
organisation they belong to and what role they play in it. But the
organisation and role are not details that are stored within the
user pools. There is a separate dynamodb table called "members"
which stores these information because these can change frequently
and need to be flexible.
Additions made to the Cognito user pool trigger a lambda function
that automatically syncronizes the "members" table in the amplify
backend in a dynamoDB table with the new additions to the user pool.
So when the admin adds a new user from the client UI, they
fill out a form with the email ID, name, organisation and role of
the new user, and the client UI will create that user with the name
and email ID in the user pool via the cognito API. Once that request
returns the user's ID (remember it will also trigger the creation of
a record in the member's table via the lambda funciton), we create a
mutation to the member's table adding the organisation and the role to the user's record in the member table.
Cognito user pool only has the email ID, name and user ID and
nothing else, all other information is stored in the members table,
which also has the ID, and name (for human reference) but not the
Email ID. We will not be holding the same information in
these two tables to avoid redundancy.
Updates to the email ID can be made by individual users via the
client app which will do it in the cognito user pool via the cognito
API. And no updates need to be made to the member table after email
update since the member table doesn't have the email ID. All other
member details can be made to the members table via the client app.
When the user logs in, as soon as the cognito UI authenticates the
user and sends over the email ID and user id, we fetch the member
details from the member table using the user ID and get details such as their name,
organisation they belong to and their role. And using the
information on their role, we can restrict UI resources using flags
in the UI Code. To achieve this, there will be a separate table that
will let the admin user modify access to the UI resources for each
role. So we'll need to fetch the role and the associated UI tags
right after authentication as well.
And as for how data is filtered as per the organisation, I am not
sure yet, but I would like to use an authorizer that will be
specified using a function in the graphql schema itself, that will
get the organisation ID with each request and use that to filter the
data before returning to the client.
Not sure if this process is solid, but this is what I was able to fathom. Please let me know if I am doing this in a sensible way or if there are better ways to achieve what I am doing.
I am pretty new to Microservices and I am confused how to easily manage different type of user through all microservices.
Let start with thee Idea:
I have a list of UserType like : SiteManager, Driver, Owner, SupportPerson- this user types had specific properties each and using a single type [USER] is not relevant, but I can use roles to manage authorization for specific microservice - this can be achieved using role manager. I would like to have different user types and Link Models to an IdentityUser like:
Driver [UserId, LocationPoint, CurrentVehicle,LicenseNumber].
Owner [UserId,Email...]
SiteManager[UserId,SiteId,Email,LocationPoint]
This 3 Types of User will handle 3 different Mobile Applications, and each application will bind to an API, or an AggregatorAPI
Identity.APILogin (create user token and pass across Services). Register -> Register a USER and return USER_ID
Driver.API Register a Driver (Call to Identity.API and get a valid User ID then create a Driver Entity), Do stuff on Driver.API
SiteManagerAPI Register SiteManager(Call to Identity.API and get a valid User ID), create order for drivers
Identity User should be a separate DB
So my questions is: Can I call my IdentityAPI microservice to create and save a new User, then I can use this
UserId to link to a new Driver Or SiteManager or SupportPerson, and in the same time using Identity microservice to Manage Authentification and Authorization? Or maybe someone has any ideas how to handle a multi-user type scenario when for each user type we need a separate table.
I have an agent authentication and there are lots of users under each agent. We want to authenticate with "Oauth" and with an app the agent can login beside an user. we want to login both (user and agent) from the same apps at the same time with "Oauth". What is the suitable way to do this.
You can use one user table for storing user's info (username, password, ...) and you should authenticate based on this table, for many types of user you can use plymorhipc-relationship, for example, you need three tables users, agents, regular_users and users table know type of each user.
How could I implement switching accounts like Facebook ( Private Account -> Page Account ).
The case would be identical to Facebook scenario:
User logs in , create eg. a business account, and then he can switch to that account and continue as a company ( in order to change settings etc. ). Then he can switch back on personal account.
One company account could access multiple users (eg . Employees )
I would add that the only way to switch to the company account, is the earlier log in as user (no logon directly to the company's account - no password).
How could I implement that in Spring? Maybe spring security has similar functionality?
Use Spring Session. It supports multiple account logins in the browser.
Multiple Browser Sessions - Spring Session supports managing multiple users' sessions in a single browser instance (i.e. multiple authenticated accounts similar to Google).
Docs here: http://docs.spring.io/spring-session/docs/1.0.2.RELEASE/reference/html5/
We have developed an app that let user login with facebook. The app has been granted all required permissions to retrieve name, email, gender and age range etc. But our app developer stored only id,name and email while user login. Now we need to retrieve gender and age range of all those users who have logged in the app.
Is there a way to rerun user query to retrieve those data? I am looking to develop an program using Spring-social and RestFB but it needs user login action to retrieve required data which is problem in our case since we cannot recreate login action again.
As long as the user granted public_profile permission to your app, and you have their app-scoped user id, you can make the API call using your app access token.
And if you are looking to request this data for a lot of users, then you should optimize your requests in the following ways:
request the fields you need only: /user-id?fields=id,gender
request data for multiple users in one go: /?ids=user-id-1,user-id-2,user-id-3&fields=fields=id,gender – https://developers.facebook.com/docs/graph-api/using-graph-api/v2.5#multirequests
perhaps even use Batch Requests if necessary, https://developers.facebook.com/docs/graph-api/making-multiple-requests/