Merge pull request #11 from ADORSYS-GIS/access-control-sys

doc: approach for ACS

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.
+