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.


.

Install OpenDJ Directory Server With a Properties File

We were working with some AWS engineers on creating puppet scripts for a Open Identity Stack installation.

OpenDJ installation with a properties file was what we tackled first since it is fairly easy to get OpenDJ up and running, with command line.

There is a section in ForgeRock Documentation that describes how to Install OpenDJ Directory Server With a Properties File.

A sample properties file was given, but it was unclear what is the use of ldifFile?

As I didn't know what was that ldifFile parameter for, I commented it during installation. All went fine and the installation was completed successfully. But ...

When we started to configure OpenAM, we encountered error - "Invalid Suffix".

So I fired up OpenDJ Control Panel to take a look, and I discovered why. 

There was no entry at all. 

Usually when I install OpenDJ via command line, I would be given an option to choose like the following:

And I usually choose Option 1. I needed an equivalent via the Properties File installation method.

The documentation was not clear enough what we should do in such a situation. So I played around with the ldifFile parameter. I should define a base entry in the ldif File. And that will do.

dn: dc=cdemo,dc=sg
dc: cdemo
objectClass: top
objectClass: domain

And that really solved the issue! A check with OpenDJ Control Panel showed everything was in place after the successful configuration of OpenAM.

Nice!

.