Emojot’s Journey to Robust Authentication and Authorization
Emojot is a leading cloud-based platform, that empowers businesses to design and manage superior customer experiences. Central to this service offering is our robust authentication and authorization mechanism, ensuring our customers' data remains secure and confidential.
Previously, Emojot utilized a self-hosted/ managed service to deliver identity services. This was supporting the SAML-based authorization mechanism and we wanted to transition into OAuth 2.0 and OIDC to align with modern development tools and the nature of our platform. As this was a core issue we faced across our platform architecture we decided to move into a self-managed solution to enhance efficiency and data security.
Based on that decision, we’ve transitioned to WSO2 Asgardeo (WSO2’s SaaS Customer IAM (CIAM) solution). Our decision to migrate our Identity Services provider to WSO2 Asgardeo also aligned with our broader shift to a Multi-API Gateway architecture pattern. This move afforded us the flexibility to concentrate on product development, freeing us from server maintenance and upgrade concerns while still providing robust authentication and authorization mechanisms to our valued clients.
To learn more about our reasoning behind the shift from a self-managed solution to a fully managed setup and overall Multi-API Gateway Architecture refer our previous blog post:
The benefits of this transition extend beyond security and efficiency. With WSO2 Asgardeo, Emojot was able to proudly offer a host of new features designed to enhance user experience and boost data security. In the sections to follow, we will delve into the advantages of Single Sign-On (SSO), the power of Federated Authentication, and the increased security afforded by Multi-Factor Authentication (MFA), all of which are now seamlessly integrated into the Emojot platform. After that, we will go through the process of how WSO2 Asgardeo was used along with AWS API Gateway to provide seamless authentication and authorization flow within the Emojot platform.
The Advantages of Single Sign-On (SSO)
SSO simplifies the user experience by enabling individuals to log into multiple applications using a single set of credentials. Now, users of Emojot and other applications need not juggle multiple accounts. With their Azure AD credentials, for instance, users can sign into Emojot without creating a distinct Emojot account. This capability streamlines the login process, saving both time and effort.
The Power of Federated Authentication
Further simplifying the user experience, federated authentication allows users to log into Emojot using credentials from another identity provider, like Azure AD. This convenience means that even without a native Emojot account, users can leverage their existing corporate credentials to access Emojot, saving time, reducing password overload, and enhancing security.
Multi-factor Authentication (MFA) for Increased Security
By requiring users to validate their identity with an additional code from their phone, MFA provides an extra layer of security during the login process. If a user attempts to access Emojot from a new device, a unique code (OTP) is sent to their phone, ensuring only verified users can access their accounts.
Additional Security Features from Asgardeo also bring an array of features to fortify the security of Emojot accounts and data. These include:
- Password strength requirements
- Password Expiration
- Account lockouts after a certain number of failed login attempts
- Monitoring user activity for suspicious behaviour
These are complemented by Asgardeo’s dedicated team of security experts, who are committed to maintaining the integrity of Emojot’s authentication and authorization system.
Role Based Access Control (RBAC)
Emojot’s authorization system uses role-based access control (RBAC) to control access to resources. This means that each user is assigned a role, and each role is granted specific permissions. For example, a user with the Administrator role can access all of the resources in Emojot, while a user with the Employee role can only access the resources that are relevant to their job function.
Emojot’s authorization system also allows for multi-level access management. This means that users can be granted permission to resources based on their position in the organization’s hierarchy. For example, a user who is the manager of a department can be granted permission to resources that are only accessible to members of their department.
Connecting the Dots: An Architectural Overview
The diagram below provides a high-level view of our current setup, showcasing how we have successfully leveraged the capabilities of the AWS stack alongside WSO2 Asgardeo to deliver our final solution. In this setup, WSO2 Asgardeo is employed exclusively as our Authentication provider, while an internal service and data layer manage authorization. We will delve into the rationale behind this distinctive implementation in the following section.
When a user successfully signs in to Emojot, they are granted an access token from WSO2 Asgardeo. This token is a testament to their authentication information housed within WSO2 Asgardeo’s Emojot Organization tenant. This token is embedded in the header of each subsequent API request to the Emojot platform post-login.
These API requests, upon reaching the AWS API Gateway, trigger a validation process for the token. The Gateway employs a Lambda authorizer, essentially a Lambda function affixed to the AWS API Gateway, to confirm the token’s validity. The Lambda authorizer cross-references the signature of the token with the WSO2 Asgardeo JWKS endpoint, returning a response indicative of the token’s status. After the validation, Lambda Authorizer generates a dictionary-like object comprising the principal identifier (principalId) and a policy document (policyDocument) that contains policy statements which will be returned to AWS API Gateway.
{
"principalId": "yyyyyyyy", // The principal user identification associated with the token sent by the client.
"policyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Effect": "Allow|Deny",
"Resource": "arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]"
}
]
},
"context": {
"stringKey": "value",
"numberKey": "1",
"booleanKey": "true"
},
"usageIdentifierKey": "{api-key}"
}If the token’s signature was identified as invalid, the Effect of the policyDocument in the returned object is set to ‘Deny’, causing the AWS API Gateway to respond with an unauthorized error. Conversely, a valid signature sets the Effect to ‘Allow’, letting the AWS API Gateway forward the request to the API service cluster. You can read more about this by visiting the link below:
Addressing the Challenge: Bridging the User Context Gap
Next, we needed to figure out how to send user context data to the backend using the API Gateway. While WSO2 Asgardeo supports the OIDC method, which allows us to send the ID token with user metadata info directly to the AWS API Gateway and then to the app cluster, our user role metadata object was too large to transfer as a JWT token in the HTTP request header. As a result, we decided not to store user claims in our identity provider and transfer them that way.
Our solution to this hurdle involved implementing an internally managed authorization layer, separate from our identity provider. This layer incorporates a dedicated authorization service and database layer augmented by a caching option.
Once the user request comes to the API service cluster, the API service will then transfer the access token passed as the header to the Authentication service. Within the Authentication service, this token will be decoded and the unique username which is attached to the token will be used to query the user data layer to retrieve user-specific role data. One thing to note here is the service-to-service communication happens internally within our VPCs and is deployed as internal resources.
The caching layer was used to store frequently accessed user role information with AWS Elasticache for Redis. As a result, we were able to swiftly access the user role metadata without making frequent calls to the database, improving the system’s efficiency and responsiveness.
This overall process helped us to bridge the user context gap and the obstacles we faced when implementing this architecture.
Conclusion
In conclusion, our journey towards enhancing security and efficiency via the migration to WSO2 Asgardeo and the AWS stack is a testament to the dynamic nature of software architecture. It’s worth noting that in software architecture, there isn’t necessarily a ‘right’ or ‘wrong’ answer. Each solution comes with its unique set of tradeoffs and is optimized for the specific use case at hand.
We believe our chosen solution delivers enhanced user experience, increased data security, and a streamlined process, which aligns with the current needs of our platform and our clients. However, we also understand that there may be other equally effective solutions out there. If you’ve had a different experience or have alternative solutions, we invite you to share your thoughts and feedback.
I would like to express my sincere gratitude to Ravindu Nirmal Fernando, the Head of DevSecOps at Emojot, for his invaluable support in editing this post.
At Emojot, our commitment to innovation and continuous improvement is unwavering. We have a dedicated tech team consistently working on refining our design and architecture, which is an evolving process. We aim to maintain our platform at the cutting edge of technology, delivering the best possible service to our users.
Stay tuned for future updates as we continue to enhance our platform’s architecture and functionality. Follow us to stay informed about our latest advancements. We appreciate your support and look forward to journeying together into the future of enhanced customer experiences.
