Design for the Auth System
Last updated
Last updated
A comprehensive mechanism to protect our miro-services, and clients.
Support SSO/Single Sign-On
Resource-based permission system, we should be able to define permissions like this: according to policy X, user A in Group B can visit resource C which belongs to Group B, doing action D (the action could be: view, edit ,and so on)
It means the auth system to be able to express different resources, like: capture, species, or in a more detailed level.
be able to express different actions against the resource: view a species, edit a species.
be able to make grant decisions by dynamic variables, for the organizations' resource: GET /organizations/1 here the number 1 is the organization's id, so for different users, the permission result varies, it depends on the visiting organization and the user account.
Support group (like Freetown) and sub-org (like CBO under Freetown)
Consideration of the case of internal visiting between microservices, like the earnings API requests stakeholder API for info.
User profile management: forgot password/reset password/ change user info like name, email.
The permission system should be flexible enough, the best result is that we can adjust/change the rule on the fly without changing too much on the client-side, changing the code in the client. To do so, we need to use Keycloak's policy system to achieve this, in the best situation, we can just make the permission decision by just providing a user account (via access token), and then all the decision logic would happen on the Keycloak side.
Applications like, admin panel can use Keycloak to login
Services that need to be protected will integrate the adapt of Keycloak to do the authentication when clients want to visit resources, e.g. http://dev-k8s.treetracker.org/earnings/captures/1234
Keycloak can also provide pages for functionalities like: login, account management, forgot password, we can customize the theme/template of these pages to adapt to Greenstand's brand.
Considerations of this implementation:
Use role-based rule in Keycloak to grant the user permission to some resources in the system, to do so, we need the credential type of client on Keycloak (the name api-services on the image) to define the resources, and action (term scope in Keycloak), and use policy to define the rule.
Every front-end client like the admin panel needs to register a Keycloak public client to be able to log into the system.
For the front-end client, we need to install the keycloak authentization library, then the client is able to fetch the permission list from Keycloak, so the client is aware of what does the user can do on this client, so that we can set up the UI for the user correctly.
For the case of communication between microservices, we can use the client-based rule on Keycloak, so that we can grant microservice A to have permission to visit microservice B.
For the case of organizations, like Freetown, we need to set up the group structure for the user/role, then, use the javascript-based rule on Keycloak to resolve the permission:
