Challenge Overview
CHALLENGE OBJECTIVES
-
Build the following microservices
-
Authentication
-
Event Subscription Filtration
-
TECHNOLOGY STACK
-
Java 11
-
Spring 5.2.8
-
Spring Boot 2.3.3
-
Spring Security 5.3.5
-
Spring GCP Cloud
-
Istio (Discovery Service)
-
APIGEE
-
Log4j/Slf4j
-
JSON (gzipped)
-
REST
-
Microservices
-
Docker
-
Kubernetes
-
Open Api Spec 3.0
-
SMTP
-
MySQL 8.0
-
JPA
-
Junit
REQUIREMENTS
Please note in the provided base code, there’s already an authentication service but that’s more of a mock or seed project for you to understand how the services are structured. We need to build the real authentication service based on the provided spec in this challenge.
The following common and generic requirements must all be followed:
-
Implement the authentication microservice
-
Follow the same structure and practices that we have implemented in the existing microservices, make sure you set up the same code style check and format commands like the existing ones
-
All Data being Ingress or Egress from Spring Boot Application needs to be GZIPPED (see https://www.javainuse.com/spring/boot-zip for an example)
-
Each of the microservices need 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, and it must be possible to deploy them to different servers.
-
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
-
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 (this is already done via Istio in the existing code, so you can just follow the same approach)
-
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
-
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. Sensitive configurations will be put in Secrets instead.
-
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. Please add common code to the existing cyn-common package.
-
MySQL will NOT run inside Kubernetes, it’ll be MySQL SaaS in production but each microservice will have its own / separate schema.
-
Service to service trust establishment mechanism must be implemented in the same way as the provided microservices.
-
Please note we consider requirements and client guidelines mentioned above to be major requirements.
Authentication Microservice
-
This service is responsible for authenticating the user credentials provided by the customer on any of the channels provided.
-
This service will eventually use OAuth2-OpenID Connect of WSO2, but since we don’t have a WSO2 environment ready yet, we’ll have to simplify this a bit for now and skip the WSO2 part. Instead we’ll rely on a MySQL database table to verify the provided user credentials in this challenge.
-
Please use com.cyn.ccds.authentication as root package name for this service
-
Please check CYN-AuthenticationService-250920-1610.pdf for the service details
-
This service has dependencies on OTP / Email / SMS services, which is provided t othis challenge
-
Ignore the dependency on the Caching service and always get the necessary info from the database, but please add a TODO comment in the code for this.
-
The security requirements must be followed
-
-
Please check CYN-AuthenticationService-API-250920-1611.pdf for the API signature, but a few notes:
-
The /resetpassword endpoint should accept an additional OTP request parameter and a password parameter. If OTP is not provided, it will call OTP service to send an OTP to the user; if OTP is provided then password must also be provided, the service will call the OTP service to verify the OTP and based on the result it will either turn an error or save the new password.
-
The /recoverusername endpoint should accept an additional OTP request parameter. using the provided parameters it should find the customer’s profile from database or local json files. If OTP is not provided, it will call OTP service to send an OTP to the user; if OTP is provided, it will call OTP service to verify the OTP and based on the result it will either return an error or return the user’s username in the response.
-
Both the /questionnaire and /answers endpoints should include the user’s password and the OTP in the request parameters. Similar to the way OTP works above, when OTP is not provided, these endpoints will only use OTP service to send OTP and finish; when OTP is provided and passed verification, it will proceed to get the user’s questions or verify answers.
-
Ignore the /accredit endpoint for now (i.e. no need to implement it)
-
-
Proper configuration & logging should be implemented
-
Provide a docker file for this microservice so we can build it into a docker image
-
Junit tests are required for the service methods
Event Subscription Filtration Microservice
-
This service is responsible for customer registration
-
Please use com.cyn.ccds.event.subs.filter as root package name for this service
-
Please check CYN-EventSubscriptionFiltrationService-250920-1622.pdf for the service details
-
Please check CYN-EventSubscriptionFiltrationService-API-250920-1622.pdf for the API signature
-
The logic of the /evaluate endpoint is very simple, it just checks if the CYN_EVENT parameter starts with the SECURITY_EVENT: prefix, if yes it returns SUCCESS, if not return failure
-
-
Proper configuration & logging should be implemented
-
Provide a docker file for this microservice so we can build it into a docker image
-
Junit tests are required for the service methods
Final Submission Guidelines
FINAL DELIVERABLES
-
Full code that covers all the requirements including unit tests
-
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 each project into separate packages that can be deployed independently
-
Build each project into separate docker images
-
Run unit tests
-
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).