Implementing Web Policy Agent on with AWS - Part II

We know a Policy Server consists of 2 very important components - Authentication and Authorization.

The following diagram is a typical deployment diagram of a traditional SSO architecture with a Web Policy Agent deployed on a web server, that communicates with a Policy Server on the backend.  

How do we achieve the same in AWS world?

1. Authentication will be performed at the Login Page which integrates tightly with Amazon Cognito. (By the way, the pricing for Cognito is quite attractive!)

2. Authorization will be performed at the "Policy Server", which I discussed in my previous post.

In fact, we can do better than that for the Authorization.

In the modern world, API is everywhere. We can have a API Gateway that exposes a isAuthorized API. The "Policy Agent" will "ask" the API Gateway if a user is authorized or not.

In additional, we can implement fine-grained authorization by building entitlement microservices.

As long as we introduce a clean interface for the entitlement microservice, customers can own this piece of work to implement their own business logic and plug-in to the authorization framework anytime. 

.

Implementing Web Policy Agent on with AWS

In my previous post on Single Sign-On with AWS Cognito, my team successfully demo a way to implement Cross-Domain Single Sign-On with AWS Cognito. 

There are many ways to implement SSO. For a start, since Azlabs is very familiar with how Single Sign-On works, the team chose to minimize the changes required on existing applications that were protected by traditional web policy agents. 

The assumption is that if any of our customers were to port over to AWS, there is minimal impact during migration. 

How can we achieve this? 

Let's take a look at how traditional SSO works. 

1. There is a Policy Server where A+A (Authentication & Authorization) takes place

2. There is a Web Server where a web application (Web Resource) is deployed

3. There is a Web Policy Agent sitting on the same Web Server intercepting traffic to the Web Resource. 

4. The Web Policy Agent queries the Policy Server for A+A decisions.

Illustration 1

Illustration 2

Let's build a "Policy Agent + Policy Server" concept in AWS!

.

Cross-Domain Single Sign-On with AWS Cognito

We have been exploring how to implement cross-domain single sign-on (CDSSO) on AWS platform for a while.

The underlying user store is using Amazon Cognito User Pools. It provide a secure user directory that scales to hundreds of millions of users.

Using Cognito out of the box, Amazon Cognito lets you add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily. Amazon Cognito scales to millions of users and supports sign-in with social identity providers, such as Facebook, Google, and Amazon, and enterprise identity providers via SAML 2.0.

That's it. In fact, it's mostly mobile-centric and support single domain for single sign-on.

To support CDSSO, we need more components from the AWS family to come into play - AWS Fargate acting as Session Validator, AWS Lambda acting as Cookie Generator/Destroyer  and AWS RDS acting as Session Store.

We demo to a customer yesterday and they were impressed.

To speed up the authentication process, Amazon ElastiCache can be used to replace or complement AWS RDS. That would be our next demo.


.