Odyssey Online and Mobile Banking Microservices Infrastructure

 

CHALLENGE OBJECTIVES

• Build the backend infrastructure based on the microservices architecture.

 

TECHNOLOGY STACK

• Java 8 to Java 11

• Spring 5.2.8

• Spring Boot 2.3.3

• Spring Security 5.3.5

• Spring GCP Cloud

• Istio (Discovery Service)

• Apigee (API Gateway)

• Log4j/Slf4j

• JSON (gzipped)

• REST

• Microservices

• Docker

• Kubernetes

• Open Api Spec 3.0

 

REQUIREMENTS

The following common and generic requirements must all be followed:

• Use com.cyn as the root package name

• Follow the coding standards provided in the forum, please include a command in maven script to run code style checking, likely using the Maven Checkstyle Plugin

• Implement an authorization microservice

• Implement an authentication microservice

• Implement an account microservice

• Implement an API Gateway

• Each of the microservice and API gateway needs to be buildable and deployable on its own, i.e. there should be no direct build dependency between any of them so we can have them in separate repos.

• Licenses to be followed in development:

  • Apache License 2.0

  • MIT License

  • Common Development and Distribution License

  • Eclipse Public License version 2.0

• Service should follow Spring Slueth Tracking (check the Server Side Request Tracking document shared in the forum)

• Implement logging properly for each service and api gateway

  • Please follow the requirements in the Server Side Logging document shared in the forum

  • You must use Aspect Oriented Programming (AOP) for Trace Logging

• Exception handling should be implemented as described in the Service Exceptions Coding Convention document shared in the forum

• Service Registration and Service Discovery must be implemented

• Data traversal between the logical layers in microservice architecture should follow the scope bounding rules for application entities and domain entities, separation of concerns needs to be adhered to strictly:
  

• Other guidelines mentioned in the Guiding Principles document shared in the forum must be followed, this is also considered a major requirement of this challenge.

• Service configurations must be done in key=value format so that it’s compatible with Kubernetes’s ConfigMap, and should support environment variable based configuration as well.

• Reusability as much as possible. Please build common components in order to delegate basic activities like Encryption, decryption, masking, hashing etc. These components can be packaged into its own common components archives, reusable by all the microservices being developed. This is considered a major requirement of this challenge.

 

Authorization Microservice

• The authorization microservice should take a list of roles as input, and return a list of permissions to the caller

• Service registration and discovery must be implemented for this service

• This service should not be exposed via the API gateway

• Proper configuration & logging should be implemented

• Provide a docker file for this microservice so we can build it into a docker image

 

Authentication Microservice

• The authentication microservice will accept username and password from the caller and authenticate that against user data configured in the configuration file or a json file

• The user data in the file should include the following fields at a minimum:

  • User Id

  • Username

  • First Name

  • Last Name

  • Hashed Password

  • Roles

• If the provided user credentials are valid, this service will invoke the authorization microservice to get the list of permissions, then it will generate a JWT token that’s returned to the caller. The JWT token should at least include the following:

  • User Id

  • Username

  • First Name

  • Last Name

  • Roles

  • Permissions

  • Token expiration time (please make this configurable)

• JWT token has to be combined with JSON Web Signature (JWS) and JSON Web Encryption (JWE). Together these specs provide not only all the information usually needed for an authorization token, but also a means to validate the content of the token so that it cannot be tampered with (JWS) and a way to encrypt information so that it remains opaque to the client (JWE). Make sure reusable functionality is implemented in a common library that can be used by all the microservices.

• Service registration and discovery must be implemented for this service. The authorization service should NOT be hardcoded into this service. Instead, it should be found and invoked via service discovery. 

• This service should be exposed via the API gateway

• Proper configuration & logging should be implemented, for this specific service, we must include the following in the logs:

  • Record IP Address, time of login, the channel of login, geo location for each user logging into the system

  • Record the geo location from which the request is being made

  • Record last login date and time in persistence storage

  • Do not log any personal information of the customer

  • Do not log the password or any other sensitive information in the logs

• Provide a docker file for this microservice so we can build it into a docker image

 

Account Microservice

• An account will have the following fields:

  • User Id

  • Account Number (string)

  • Alias (string)

  • Currency (string)

  • Amount (float)

• When the account microservice receives a request, it needs to get the JWT token from the Authorization header and verify that the token is valid and that the user has permissions to the actions, otherwise it should return 401 error

• The account microservice should support the following operations:

  • Create account:

    • allowed if permission “account.create” exists

  • List accounts:

    • Returns the current user’s accounts

  • List accounts by user id:

    • Allowed only if permission “account.list” exists

  • Update account:

    • Updating the alias is allowed if permission “account.update” exists or the user id in the JWT matches the user id in the account to be updated

    • Updating the amount is only allowed if permission “account.update” exists

  • Delete account:

    • allowed if permission “account.delete” exists

• All such data will only be saved in memory for this service

• Service registration and discovery must be implemented for this service

• This service should be exposed via the API gateway

• Proper configuration & logging should be implemented

• Provide a docker file for this microservice so we can build it into a docker image

 

API Gateway

• This serves as an entry for access to all the underlying microservices that need to be exposed

• When the API gateway receives an authentication request, it invokes the Authentication Microservice to do the authentication, and if that succeeds the gateway will:

  • Generate a unique opaque access token

  • Save the opaque access token along with the JWT into the memory

  • Return the opaque access token to the caller

• When the API gateway receives other requests with an access token in the Authorization header, it will:

  • Look up that access token in the storage

  • If the token doesn’t exist, this is an invalid request and the gateway will return 401 error

  • If the token exists, get the JWT and check if it’s still valid, if not the gateway will also return 401 error and remove the (token, JWT) tuple from the storage

  • If the JWT is still valid, it will forward the request to the corresponding underlying microservice with JWT included in the Authorization header

• The API gateway should not hardcode any of the underlying microservices. Instead, they should be found and invoked via service discovery

• Proper configuration & logging should be implemented

• Provide a docker file for the API Gateway so we can build it into a docker image

Final Submission Guidelines

• Full code that covers all the requirements.

• A detailed README file including information on how to configure, run, and verify your application.

• Maven script(s) that at least cover the following:

  • Run the services locally

  • Build the API gateway and each microservice into separate packages that can be deployed independently

  • Build the API gateway and each microservice into separate docker images

  • Generate a sitemap for the project using Maven Site Plugin (mvn site)

• Postman collection file to properly test the API (covering positive and negative cases).