SaFi Bank Space : IAM Domain

Scope

Online identity and access management
User credentials and authentication device management
Multi factor user authentication
Rule based authorization of access to protected resources and transactions
Authorization rules triggering step-up authentication for high-risk use cases and scenarios

Definitions

Term	Definition
Identification	The process of getting a user’s identity.
Authentication	The process of validation of a user's identity by asking the user to provide a set of credentials.
Authorization	Assuming a user is eligible (has a right) to access a resource or a function, the authorization process is about making a decision to grant or deny access of the user to the requested resource or function. The authorization process is also responsible for ensuring the user’s will to execute is expressed properly and is sufficiently credible.
Step-up authentication	The authorization process asks the user to express her will to execute required action by means of additional authentication with a stronger authentication device.

Generic vs domain-specific authorization rules

There are multiple of rules to be evaluated in order to authorize user access. IAM domain is mainly responsible for generic or business domain-agnostic rules such as credentials and multi factor security device management and verification, end user session inactivity duration, device fingerprinting, IP addresses, GEO location, etc. On the other side of the spectrum there are business domain specific rules which are related to evaluation of the customer-to-product role (e.g. account owner), checking of different kinds of limits, etc. These are in the responsibility of the particular business domain’s services.

However, there is kind of a grey zone between these two groups, where a probability of fraudulent transaction is evaluated. This area includes rules such as

Multiple transactions in a short time period should trigger additional verification
Multiple transactions with a high amount should trigger additional verification
Changing multiple account details within short period of time should trigger additional verification
Triggering of back office action in certain circumstances
Etc

To implement these rules the responsible system needs to understand the semantics of the relevant actions and maintain a set of counters and/or other mechanisms.

To further enhance the effectivity of the authorization rules while keeping a high level of the UX, it would be natural to introduce a ML mechanism with capabilities to maintain user’s behaviour profile that can be used for adaptive risk assessment of the user’s activity.

Note: See ADR: Domain specific user authorization rules

Overview

Component	Description
Client App	Client apps uses VIDA SDK to implement user authentication based on PKI based message signatures.
Backoffice App	Backoffice app uses OAuth based authentication solution with JWT tokens.
Domain Manager	Domain Manager is responsible for the overall authorization process for endpoints consumed by Client app. It validates the message signature using IAM SDK and executes all domain specific authorization rules it needs to ensure the customer is only allowed access to his owned products. Domain Manager integrates with the Fraud System (Slacker) in cases where there is a need to evaluate risk of fraud. Domain Manager also exposes endpoints to be consumed by Backoffice Manager. In this case the Domain Manager ensure that the request is coming from the Backoffice Manager and does not execute any other authorization rules.
IAM Manager	IAM is responsible for the management of user’s credentials and authentication factors. It integrates with AAI OSP if needed. IAM provides SDK libraries for frontend and backend apps to simplify their development.
Slacker (Fraud System)	Fraud system is responsible for evaluation of probability of fraudulent operations. It can block or approve the operation or request additional verification aka step-up authentication with appropriate authentication factor.
Advance AI One Stop Platform	Advance AI Platform responsible for biometric based authentication factors such as selfie matching identity document.
Domain Data Store	Each domain is responsible for the persistence of operation specific data during the authorization process.
Backoffice Manager	Backoffice Manager acts as a backend-for-frontend for the Backoffice App. It is responsible to execute all necessary role-based authorization rules to ensure only authorized users are allowed access to the requested resources. It also implements the maker-checker model checks.
Okta (IAM for backoffice)	Okta is an IAM for internal backoffice users. It also manages organization structure needed for the maker-checker process model with the help of IAM Manager.
Ticketing Manager	Ticketing Manager enables Domain Manager to create a ticket for manual approval of the operation.

Solution Design for Customer App

Domain MS
- Acting as policy enforcement point and partly as policy decision point.
- Domain MS executes the necessary permission checks e.g. only account owner is allowed to submit a payment order for the account, etc.
- For defined operations it integrates with slacker providing all necessary data for the given operation for slacker to respond with required authorization level.
- Based on the authorization level, domain MS will reject, approve or postpone the operation until manually reviewed or step-up authentication is successfully proceeded.
- In situations where the operation needs to be manually reviewed, the operation (e.g. payment) will be persisted in the domain MS until approved or rejected. Domain MS will expose API for backoffice FE to enable this.
- In case that step-up authentication is needed, the domain MS will delegate it to the IAM service.
Slacker
- Provides synchronous API for domain MS to risk-score respective operation and decide what authentication level is required to proceed with the operation or provide authorization directly. For different operations different input parameters are required to analyse the risk.
- Authorization have defined semantics such as deny operation, approve operation, require additional authentication (e.g. step-up) with appropriate credentials, manual review required, etc.
- Slacker uses data received as parameters from domain MS via API call and also data received via domain events.
IAM
- IAM is responsible for execution of step-up authentication. This includes the communication with frontend app and the selection of appropriate authentication factor covering all authentication factors including credentials, face check, security questions, etc.
- The authentication factor will be chosen according to the required authentication level requested by slacker.
- IAM will be integrated with AAI platform for the “face check” authentication factor.

Low-risk scenario

High-risk scenario

Medium-risk scenario with step-up authentication

High-risk scenario with manual approval

Solution Design for Backoffice App

Backoffice Manager
- Acting as policy enforcement point and partly as policy decision point.
- It executes the necessary permission checks ensuring the backoffice user is only allowed access to proper resources and is allowed to executed proper actions based on user roles.
- Retrieves user roles from Okta.
- Delegates execution of domain specific business logic to the individual Domain Services.
Domain MS
- Trusts the Backoffice Manager in a sense that it only ensures the request is coming from Backoffice Manager by infrastructure level request authentication (Istio).
- Executed requested business logic and/or provides requested data to the Backoffice Manager.
Okta
- Manages identity and roles for internal/backoffice users.
- Acts as an authorization server according to the OAuth2 protocol.

Authentication and authorization logic in Domain Managers and Backoffice Manager

Definitions

External user = customer using the banking app.
Internal user = backoffice application user, typically an employee of the Bank.
Technical user = user representing a backend service

Assumptions

Domain services provide APIs for internal and Backoffice Manager provide APIs for external users.
There are two different IAM solutions being used for external and internal users with two different authentication mechanisms. PKI for external users (Vida) and OAuth2 (Okta) for internal users.

Request authentication for External user - PKI

Custom headers containing the:
- customerId
- timestamp
- signature
- credentialId (mapped 1-1 to customerId)
The domain service will receive the signed request and verify the signature of it by fetching the public key to the customerId (credentialId) either from VIDA or its cache.
- User’s identity (customerId) is extracted from the request headers if the signature matches.
- The process will be abstracted in the library provided by IAM

Request authentication for Internal user - OAuth2

JWT bearer token presented in HTTP header Authorization of all requests from Backoffice App to Backoffice Manager
Token signature verification based on JWKS downloaded from Okta regularly according to the rotation policy
Validation of audience parameter (e.g. https://api.safibank.online)
User identity is presented as a sub claim in the JWT
User’s roles presented as a https://safibank.online/roles claim in the JWT

Request authorization

Internal user
- Access management for the internal users uses role-based approach
- Backoffice Manager allows to execute an operation or grants access to data according to the roles the authenticated users is assigned to
- Each API operation provided by a Backoffice Manager is configured to only allows access to white-listed roles
- If the API operation is part of the maker-checker schema it also validates the identity of the ‘checker’ user for the ‘check’ step of a use case by retrieval of the user-manager mappings from Okta via API (this information can be cached as it does not change frequently)
External user
- Authenticated user represents a bank’s customer
- Bank customer owns a set of products/accounts
- Domain service allows to execute an operation or grants access to data for the user representing the account’s owner only
- Domain service evaluates any other business rules defined for a given API operation as part of the authorization logic (e.g. checking of account balance, account state, etc.)

Machine-to-machine requests

JWT tokens of internal users nor PKI signatures of external users will not be propagated within service-to-service requests
Authentication of a request with a technical user’s identity will be based on mTLS and provided by Istio

TBD design of API for integration of domain service with IAM

TBD Norbert Bérci (Unlicensed) pls let’s sync and provide more details here

SaFi Bank Space : IAM Domain

Scope

Definitions

Generic vs domain-specific authorization rules

Overview

Solution Design for Customer App

Low-risk scenario

High-risk scenario

Medium-risk scenario with step-up authentication

High-risk scenario with manual approval

Solution Design for Backoffice App

Authentication and authorization logic in Domain Managers and Backoffice Manager

Attachments: