Meandering Our Way Though the Microservice Architecture: Case Study

The Challenge

The CEO got up in front of the entire company and said, “Product XYZ is the future of this company; and we are going to ship V1 by the end of the year”. As the designs began to sure up, it became clear an authentication microservice was needed. The challenge was made.

“IcedPenguin, you shall lead the team that builds the Security Token Service (STS).”

Project Kick-Off

I chatted with the architecture team, the implementation team, and the product owner of the overall application and established the STS charter. We had three months to deliver a beta service (needed to start service integrations) and an additional month before we had to be hardened. This will be fun.

The Purpose of the STS

The primary responsibility of the STS was to handle authentication with our cloud product. This handled all web-traffic to the console. We replaced the existing weak cookie implementation with a JWT implementation and rev’d the core application to be able to understand the structure of the JWT, to perform authorization based only on the contents of the JWT instead of having to reach back to a centralized point (the power of digital signatures). Additionally, we designed and built a revocation mechanism so that the web-servers could be notified when a token had been revoked (as opposed to simply expiring).

The second main responsibility, and the primary need for Product XYZ, was to facilitate federated authentication for our end-points to a third party cloud service. The end-point would reach out to the STS to kick off the authentication processed. The STS would perform the handshake with the 3rd-party, and return to the end-point, the 3rd-party access token generated specifically for them.

Infrastructure

The core service was built upon Spring Boot utilizing stateless REST APIs. The ability to scale horizontally was defined on day one. We would need it to scale, ensure high availability, and as seamless upgrade mechanism (bring up new nodes, get them stable, take down old nodes).

Result

After four months of effort (plus testing), we accomplished our goal. We extracted the authentication code from our monolith and shipped it as a microservice. Additionally, we added the 3rd-party federated authentication functionality that was needed for Product ZYZ.

Microservice Discussion: I Thought Microservices Were Suppose to be Light Weight, Why Did it Take Several Months to Build?

Great question! The STS was the first microservice to be built by the company, so we were in uncharted waters. Along the way, we hand a lot of “overhead” tasks that had to be tackled and overcome:

• Containerize the Sprint boot instance and dependencies for development
• Build pipeline to auto-create the container
  • Run the unit tests
  • Publish artifacts to artifact repository
  • Integrate automatic running of tests with our pull-request review tool
• Built a pipeline to deploy the node swarm to qa, staging, and production
• Update automated test framework to run against containers
• Management of configuration settings for development, QA, and production
• Run reviews with corporate security department to approve the approach and architecture of the STS swarm.
• Preliminary monitoring tools put in place

In addition to the product integrations: * Complete audit trail in place for user authentication actions * Updating clients to interact with the STS