AWS Public Reference Identity Validator

PROJECT REFERENCE Identity Validator System – Pension Fund Administrator

The Pension Fund Administrator of Colombia is part of a well-known Colombian holding company and is one of the largest administrators of pension and census funds in the country with more than 1.6 million members. This pension fund manager manages three types of funds: unemployment insurance, voluntary pensions, and mandatory pensions.

In 2011, the company acquired the assets of pension funds in other countries of the region, in 2013 the firm completed a merger process with a foreign group adding to its management portfolio of Pension and Unemployment Funds, life insurance, and administration of investments.

The technical difficulty and business involvement.

Currently, this Pension Fund management company has constant development of applications to retain its customers and also to be at the forefront of the business, therefore, currently with a large number of applications, these applications are grouped according to to the users who use it, there are two groups:

Internal applications or internally used applications of the company
Satellite-type applications are used mainly by affiliates who carry out self-management operations in the different existing channels according to their requirements and/or needs.

In satellite-type applications, the administrator must allow operations that by their nature require different security mechanisms such as authentication, identification, and authorization. However,

To achieve authentication, affiliates use the username and password mechanism.
The authorization is carried out through a system of roles, profiles, and permissions, all configured depending on the type of affiliate and the accesses they require to carry out their respective operations.
The identification of the affiliate is a more complex task, bearing in mind that the objective of this mechanism is to ensure that the user is really who they say they are and that they have not been impersonated.

This last identification mechanism is the core of the problem to be solved since it must allow the administrator to ensure that the affiliates carry out the procedures, operations, and/or use of services in a reliable and safe manner with the quality they deserve.

Now, the combination of different security factors adds more layers of security to the authentication procedure, providing robustness to the verification and making intrusion and identity theft by third parties more difficult. For them we introduce strong authentication, which is when combined with minus two factors to guarantee that the user who authenticates is really who he claims to be, all strong authentication is also a multi-factor authentication (MFA), where the user verifies his identity as many times as factors are combined, even if one of the factors fails or is attacked by a cybercriminal, there are more security barriers before the cybercriminal can access the information.

As a result of this, the “identity validator system” arises, which is the system as a service that performs the process of identifying the affiliates in the administrator, which is used by the other systems that require it so that they can decide whether or not they authorize the execution of a procedure.

Solution realized, AWS services, Architecture

To achieve a correct identification of the affiliate, the collection of data becomes evident as a first step, depending on these data, the best decision must be made as to which identification mechanisms should be applied, then these mechanisms must be applied, wait for the Affiliate response and verify it, in parallel the entire process consists of its respective operations and statistics record.

The general architecture of the system is essentially made up of the following components:

Satellite: they are those that consume the services of the identity validator system since they need to validate the identity of their affiliates before carrying out a procedure.
UI: Identity validator system graphical interface. Set of components and libraries developed in React JS that can be used by the Satellites, which contain the connection logic towards the identity validator system services.
APIGateway: Contains the endPoints that the identity validator system exposes
Traceability in Splunk: Components that are responsible for recording the messages it exchanges identity validator system (externally and internally)
Completeness: Component that is responsible for making the necessary calls to services external identity validator system that extract the necessary information from the client to make the decision of what mechanism will be applied.
Validate Pass: Component that is responsible for eliminating the mechanisms to be applied to the client those that have already been validated taking into account a series of configurable criteria.
Mechanism Manager: In charge of executing the mechanism and carrying out the validation through communication with third-party services and interpreting and validating their responses.
Rule Manager: In charge of making the decision of the mechanisms that will be applied to the client.

Architecture flow

The identity validator system is a system made up internally by several micro-services that interact with each other. The general flow of the identity validator system consists of a request for validation of the mechanism for a client which travels through the different micro-services that make up the system. The following is the identity validator system message flow architecture.

The image shows, similar to the logical architecture of the identity validator system, the internal architecture of Micro-services using AWS SQS queues as an intermediate communication channel, which make up the system and the data flow of a request. that is performed at the same. The image flow is a functional flow which means that the request is not canceled.

The flow is described below:

The identity validator system receives a validation request from one of the corresponding channels and which are configured, validates the data sent according to a defined structure and request ID.
Authenticate the request according to the Satellite that is making it.
Register the information in Redis where it will keep waiting for the response for the Request ID (synchronization simulation)
Determines if it is an uninitiated request, validates if the transaction and the channel exist.
The process of completing the request data begins.
They are called the external completeness services of the identity validator system to extract the information required from the affiliate, which will be used in the decision-making of the identification mechanism that should be applied.
The completeness data is sent to the RuleProcessor micro-service, through the fan-out scheme and using SNS and SQS, which will be in charge of orchestrating the rules to determine the list of mechanisms to apply to the client.
They are determined by the data that was extracted in Completeness, plus the data of the initial Request itself, and taking into account a series of rules that the list of mechanisms to apply must be met.
The validations that the client has passed in a given time are determined
The necessary consultations are made to complete the required information
The completeness data and the list of mechanisms to be applied are sent to the ExecuteMechanism micro-service, which searches the list of mechanisms to apply for the first one that has not been validated and calls the external service to the identity validator system that starts the validation mechanism.
The collected data plus the response from the initiation of the first invalid mechanism is sent to SendResponse. This stores the entire request in the Database for subsequent requests.
Push the data into Redis where RestRequest is waiting to send the request-response
A validation request of the initiated mechanism is started. It keeps reading from Redis the answer.
It is validated that the start request has been executed correctly and that the request is valid
It is sent to validate the mechanism, where the validation service corresponding to the same initiated mechanism is called
It is verified that the validation has been successful and the mechanism is marked as valid in the list of mechanisms
Send invalid mechanism response

Low Level Architecture

A lower-level identity validator system architecture shows the complexity of the system and the number of components that intervene and interact with the Request information that travels from one micro-service to another; where each one is enriching and modifying its state.

What are the benefits of this solution for the client?

As part of the implemented solution, the client obtained greater security in the processes of self-management and operations that required verification of the identity of the person who required it. That In this sense, the consumption of the system was implemented in the satellites to make the decision whether to allow or not carry out operations, which brought a greater securitization of operations and prevents in a high degree spoofing. With this, it has gained greater prestige and confidence from affiliates knowing that there are ways to verify their identity when operating with their services and products of your day-to-day.

AWS Public Reference Identity Validator

Renzo Disi