diff --git a/doc/integrate_access_control_sys/approach.md b/doc/integrate_access_control_sys/approach.md new file mode 100644 index 000000000..cc1b89414 --- /dev/null +++ b/doc/integrate_access_control_sys/approach.md @@ -0,0 +1,51 @@ +To build an access control system using Keycloak based on our resource model, here’s how we can approach this issue: + +### 1. How should the access control system reflect in my APIs? + +The APIs should reflect the access control system through the following mechanisms: + +- **Resource-Based Access Control**: We can define each resource (User, Bank Account, FPAccountAccess, TPOAccountAccess) in Keycloak as a resource. Each resource should have associated scopes (e.g., `POST`, `GET`, `PUT`, `DELETE`). + +- **Scopes and Permissions**: We can implement scopes for each resource. For example, a `Bank Account` resource could have scopes like `view`, `create`, `update`, and `delete`. + +- **Endpoint Protection**: We can use Keycloak to protect our API endpoints. For example: + - `GET /user` should require the `view` scope for the User resource. + - `POST /bank-account` should require the `create` scope for the Bank Account resource. + +- **Token Validation**: APIs should validate access tokens issued by Keycloak. This ensures that only users with the appropriate permissions can access certain endpoints. + +### 2. How do we integrate the following access control schemes: PIN/TAN, API Key / OAuth2, Public key based access? + +- **PIN/TAN**: + - This can be implemented as an additional authentication layer. After the user logs in via OAuth2, prompt them for a PIN/TAN to authorize specific actions (like transactions). + - Store and validate these codes securely, and link them to user sessions or actions. + +- **API Key / OAuth2**: + - We can use OAuth2 for user authentication and authorization. Each client application can be given an API Key which can be validated against Keycloak. + - We can implement client credentials grant type for server-to-server communication where an API Key is used to obtain an access token. + +- **Public Key Based Access**: + - Use JWT (JSON Web Tokens) signed with a public/private key pair. Keycloak can be configured to sign tokens with a private key, and our APIs can verify these using the public key. + - This ensures that tokens cannot be tampered with and provides a secure way to validate the identity of the requester. + +### 3. What policies are great for this scenario? + +- **Role-Based Access Control (RBAC)**: Define roles (e.g., Admin, User, TPP) and assign permissions based on these roles. This simplifies permission management. + +- **Scope-Based Policies**: We could create policies that grant permissions based on the scopes required for each action. For example: + - A policy that allows access to a resource if the user has the `view` scope for that resource. + +- **Attribute-Based Access Control (ABAC)**: If our resources have attributes that affect access (e.g., user status, account type), we could implement policies that consider these attributes. + +- **Time-Based Access Control**: If certain actions should only be allowed during specific times (e.g., banking hours), we could create time-based policies. + +- **Contextual Policies**: We could use contextual information (e.g., IP address, device type) to enforce additional security measures. + +### Implementation Steps + +1. **Define Resources and Scopes**: Set up resources in Keycloak and define the necessary scopes. +2. **Create Roles**: Establish roles and assign the appropriate permissions to each role. +3. **Set Up Policies**: Implement the policies mentioned above in Keycloak. +4. **Configure Client Applications**: Ensure that client applications are set up to use OAuth2 and can handle access tokens appropriately. +5. **Test and Validate**: Thoroughly test the access control implementation to ensure that it meets our security requirements. +