Introduction
I hope you are doing well. In this article, we are going to understand how more than one application connects with a common interface application using Single Sign On. In this case study, we are using Cognito for authentication and authorization. This scenario is used mostly in most enterprises to avoid sign-in the application and to keep the common guard rails.
In today's world, each application has its own subsystem, and the enterprise has to manage multiple applications for daily routine business cases.
For example, Enterprise has HRMS, IT ticket system, and Code Repo, etc., In earlier days, we maintained credentials in each system, and the user also had to keep the same credentials in all systems, or else he needed to remember all off the top of their head.
On top of that, we are going to look at how to avoid redundant logic in multiple applications so that we can avoid engineering and maintenance work.
Scope
- Implementation of a Common Interface which can be accessible to more than one application.
- Applying AWS Cognito (User Profile and Identity Profile) for authentication.
- Cognito Cache Mechanism
- Creation of a microservice approach
- Implementation of a common interface as a standalone product.
- Since the common interface is a standalone and plug-and-play product, this interface should have any consumer-related data.
- AWS Code Commit
- AWS Amplifier
Problem Statement of Common Interface Architecture with SSO
Currently one of the real-time business cases, we have multiple applications in which we need the same sort of functionality in more than one application, and the data is also somewhat the same. In the case of following the legacy approach, we have to make a development effort in both the application for the same piece of work. The drawbacks of this approach which we are facing as rightly bindied with application, follow the same sort of legacy approaches.
Solution
- In this strategy, we are going to create a new application that acts as an interface between multiple consumers so that we can avoid duplicate engineering work.
- For Authentication and Authorization, we are adapting AWS Cognito Service, which is internally called IAM; this feature is used to generate tokens, validate, and grant resource access.
- Auth token generated using Cognito User Pool and Authorisation granted using Identity pool.
- Each consumer has its own tracking or consumer ID, which is generated while subscribing to a common interface application; further call or interaction between the consumer and the common interface occurs based on this tracking ID.
- This current design is a lightweight application or proof of concept kind of activity, so I planned to opt for AWS Amplifier. Eventually, we deploy this static and back end as a separate target.
High-Level Architecture
Low-Level Components Design
Process flow Common Interface Architecture with SSO
- User Sign-in the app through legacy application(one or two).
- While connecting the first time, the common interface application generates a tracking ID against the user and shares it with the consumer application.
- Consumer applications first authenticate using Cognito and receive the token.
- while connecting the consumer application to the common interface application, the consumer application will share the token. Then the common interface application validates the token using the identity pool with the help of the OAuth mechanism.
- Once the validation passes through, the application will call the interface application.
- The AppSync acts as a single point of contact for all low-level modules, such as lambda, dynamo, and microservices.
- A single database that contains multiple consumer data against respective tracking IDs.
- The Amplify studio is used by developers for their development activities.
- Amplify will connect with GitHub for code repository and to do CI/CD activities.
- The Cloud front is used to store cache based on the region so that we can increase response time.
Join the conversation! Your thoughts help the community grow.