No SSO

Many times during SSO presales or tender presentations, we will be asked the same question again and again - "What if the SSO infrastructure goes down?"

Ting ... Ting ...

Most of us who have been in this field long enough will respond that high-availability has to be in place for such a critical infrastructure. One could go further to elaborate about the the reliability of cloud infrastructure like AWS scale-out, AWS availability zone failover, VM Fault Tolerance etc...

Nothing beats application building its own local authentication as a last option.

It's a fact.

.

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.


.

BeyondTrust Privileged Access Management Platform

I just realized it has been a long while since I last blogged. Have been super busy with new direction with the company and making customers happy.

Today, I tried to source for a PAM (Privileged Access Management) solution for my customer who has his infrastructure on AWS. As such, an appliance-based PAM solution does not make sense.

Then I came across BeyondTrust. Not totally new to me since I have friends working there. But there has been great changes in 2018.

2018 was a game-changing year for the Privileged Access Management market. Lieberman, Avecto and BeyondTrust were all acquired by Bomgar and, in 2019, we will launch the new BeyondTrust. Bringing together these best-of-breed technologies allows us to deliver the most comprehensive PAM solution to date.

Wow! 4-in-1!

Hope to do some businesses with BeyondTrust!


.

SSO Migration in 10 (+3) weeks ... People matters!

I have a long time SSO customer who came back to me after 6 months "ditching" us. Well, the actual fact was a new VP came in and we did not get along well. Anyway, he couldn't deliver after 6 long months and he was out of the game. The old VP called me immediately after she was reassigned  with the SSO infrastructure.

I'm very familiar with their environment and even though there is a lot of customization, I promised the whole migration will only take 10 weeks. Yes, a major jump in software version. A lot of code rewrites. A lot of Java code decompilation as the software has gone closed-source. It was real fun!

I brought in my best team. And we are going live this coming Sunday! (Ok, customer requested to delay go-live for another 3 weeks as there is 1 site that customer would not want to migrate to the new platform. Thus communication with their end-customers is required to shut down that site.)

Last mile and we are talking about Cut-Over Plan yesterday.

I joined in the discussion. Towards the end of the discussion, customer looked at me and asked me if I have any comment. My only request was: "Give me the same set of people who had performed the dry-run weeks before."

It is going to be a real long night this Sunday and a lot of eyes are on the whole team. I told the manager of the application teams not to assign people based on availability (you know, as this is a midnight job, the seniors will always find excuses not to be involved), but based on experience and capability. Don't give someone who has no idea what is going on.

People matters!

One Identity Cloud Access Manager - STS Windows Service

In One Identity Cloud Access Manager deployment, there is a STS host and Proxy host. The proxy host acts as the reverse proxy to protected applications, as well as serving as the Login Page.

On the Proxy host, if you ever need to restart the service, a quick search for One Identity Cloud Access Manager Proxy does the job. Fairly easy to locate.

On the STS host, if you need to restart the service, you are not in luck. It took me a while initially. I just could not locate any service that starts with "One Identity ...".

To do so, search for "Redistributable Secure Token Server" instead.


Weird and inconsistent naming convention indeed!


.

One Identity Cloud Access Manager - Notifications

I found a good feature in One Identity Cloud Access Manager today - Reminder to turn off detailed message logging.

So I was debugging something yesterday and totally forgotten to turn off detailed message logging. I was at admin console a while ago and I saw a new notification on the top right of the dashboard.

Being curious, I took a look and was reminded to turn off detailed message logging as "Keeping detailed message logging turned on impacts performance".

Not a hard feature to implement. But I seldom see this in other products. Good reminder to my team which is currently busy with their little product development.

.

One Identity Cloud Access Manager - Database Snapshot

Cloud Access Manager provides a utility feature for customers to download a snapshot of the CAM database. 

This could be helpful for raising a support ticket. Other products have similar feature to capture a snapshot of the current configuration. However, none is as convenient as this.

Pretty good!


.

Accredited Consultant

ForgeRock Access Management Accredited Consultant

ForgeRock sent me this yesterday. Nice gesture. I take.


Just few weeks ago, I was told by one of my consultant (btw, he is ForgeRock Identity Management Accredited Consultant) that a young punk from another company boasted to him that he is ForgeRock Access Management certified.

Nothing to be great of. Uncle me accredited keeping a low profile here.

When you are capable, you just dig in and work harder. You don't need to show off. Customers have bright eyes.

.

Magic Quadrant for Full Life Cycle API Management (2018)

The latest magic quadrant for Full Life Cycle API Management has been released a month ago. I just received a mailer from CA. 

Well done, CA Technologies remains in the Leaders quadrant. Not sure why Google (Apigee) is so high up, as we don't see much competition from them in this region. As long as you are totally cloud-based in this region, especially Singapore, you're basically out of the game. I'm saying if you are looking for large customers. The game is still very much on-premise.

Interestingly, Tyk has made it to the Niche Players quadrant. That's real hard work for a new player who has been in this market for less than 5 years. Really impressive! Kudo to the Tyk team!


.

What API is not about and about?

My team has been covering a potential customer for a while with regard to a API Gateway deployment. POC done. Presentation done. Then a competitor came in to disrupt ... it's common. Singapore is a saturated market. There are finite number of customers to chase after. If customers don't come to you and you hear that they are looking at a product from your competitor, you quickly go in to disrupt the market. 

If you are the product principal and you have the time and energy and you have a willing partner, then you will do this sort of things. I'm someone that is not too keen to do this. The pie is always big enough for everyone, that's my view. If you go in to disrupt the market, you're usually going into a price war. It's not about product superiority anymore. More importantly, the quality of the consultants are not considered.  

This is a vicious cycle. Nothing good will come out of it. Customers think they are getting a good deal. I say they are mostly blind. Partners/Vendors are not stupid either. If a partner bids with a superbly low price, you think the partner will give you his best consultants? You pay peanuts, you get monkeys. As simple as that. 

Anyway, I went in to make my last presentation. I only showed 2 slides. 

API is really not about Secure File Transfer, Security, Throttling and Message Queues. These are given. If a gateway has no such features, they will never get a chance into the board room in customers' place. 

Honestly, 80-90% of the API products out there in the market have similar features. All are equally good. Why? For most customers (80%), they only use a subset of features (20%). I can confidently say most API products meet the requirements of most customers. 

API is really about People - Customer & Vendor. 

I know that the competitor is partnering with a SI that does mostly systems related work - PAM, Secured File Transfer. 

In our experience, these type of people are only used 20% of the total time spent in a typical API projects. They are utilized during the Build phase and the Maintenance/Patching phase. In Build phase especially, my own experience told me that my API Consultants are of no use here. They simply do not understand networking, firewall, zoning, routing, high-availability, scaling, hardening, vulnerability assessment, security scanning. This is where a trained Systems Consultant is useful. They will be able to work with the Network Security team from the Customers' sides effectively. 

But as soon as the Build phase is over, the Systems Consultants become totally "useless". This is where API Consultants come in. They are there to help Customers with "Discover, Simplify, Transform, Add Values". In short, to provide API Design services. This usually takes up 80% of the total time spent in typical API projects.

API is all about proper thought process. It's not a simple "Oh, let's create a new API and map it 1-to-1 with your backend service". An intern will do! Why spend so much money?

.

SAML-message with NotBefore

I was integrating our corporate JIRA with One Identity Cloud Access Manager via SAML2. I chose the plugin from Resolution GmbH. 

Integration was a breeze. Their wizard is brilliant! I got the whole integration completed successfully within 15 minutes.

One issue I encountered was - "SAML-message with NotBefore xxx is not valid yet."

This was quite easily resolved. Do make sure the IdP (One Identity Cloud Access Manager) and SP (JIRA) are sync-ed with the same NTP server.

The error disappeared as soon as I have NTPd configured on my JIRA server.


.

One Identity Cloud Access Manager - Backend SSO Method

Out of the box, One Identity Cloud Access Manager provides the traditional credential SSO methods like IWA (Integrated Windows Authentication) and HTTP Header. I like that it provides Form Fill, though I would keep this as a "hidden secret weapon" in the event customers have some legacy applications that I have no choice but to perform password replay.

In the same box (yes, same box. some other vendors require you to add-on :>), the trendier Federated SSO Methods like SAML2 and OpenID Connect/OAuth 2.0 are provided. No additional add-on. No additional cost. SAML2 IdP is enabled out of the box. OpenID Connect Provider is enabled out of the box. Very easy to integrate with any 3rd party federated clients. 

I was trying to integrate our in-house JIRA via SAML2 and it took me less than 15 mins for the first try. 

. 

One Identity Cloud Access Manager - Not Authorized

I was playing with One Identity Cloud Access Manager this afternoon and hit into "Not Authorized - Sorry, but it seems as if you're not authorized to access the selected application".

This is what I have observed. If the administrator configured a new protected application after you have logged in to the Application Portal (a one-stop landing portal for you to single sign-on to multiple protected backend applications), the new application link (e.g. Web SVN (Management)) will immediately appear on the portal.

However, as soon as you click on the new link, you'll hit into "Not Authorized" error.

To workaround this, log out and log in again. The new link is now accessible.


Simple!

.

CA SSO Access Gateway

I met with a potential customer today and he was interested to deploy CA SSO Access Gateway in the DMZ, while keeping CA SSO Policy Server in the Intranet.

He was not sure what were the possible integrations provided by CA SSO Access Gateway with his backend applications.

I showed him the diagram below. Self-explanatory.

• SAML (Federation)
• REST/JSON 
• OpenID Connect
• HTTP Header (Web Agent)

.

Password Meter

We have been in the Security & Identity business for a long time. Recently, we have been engaged in a number of Identity Management projects in the Asia region.

In some projects, we build our own Access Request Portal on top of Identity Management products out there in the market.

Reason is simple - To Increase User experience!

From our observation, some IDM products are just too complex, too heavy; some IDM products lack features required by customers.

And since more and more IDM products are exposed by REST, it makes it compelling to build our own Access Request Portal.

We build a Access Request Portal that is lean and fast. No unnecessary features just to make Gartner happy. (You don't agree? Ha! )


In one of our projects, the CIO took a look at the User Profile tab and explore how we build the Password module. He didn't like what we have built. He has a strong view on what is a Strong Password. He even sent my team this to read up - Science Can Help You Choose a Better Password. Complexity isn't as important as you think.

So we stripped the original Password module and incorporated Password Meter.

Password Meter is pretty cool. It will "score" your password quality as you type in and give you advice immediately.

My team did it better! As Password Meter is open-source and published in GitHub, we enhanced it to support multi-languages.  

What's next is for the team to tidy up the sources and offer them back to the community.

That's the beauty of open-source! Some just don't get it. Money is never enough. 

.

One Identity Manager - Access Request History

Having implemented numerous IDM projects and seen multiple IDM products, all will provide a Access Request History view in a table format.

Besides providing the default table format, One Identity Manager provides a timeline view. 

Important feature? No. Wow feature? Yes, indeed. I like it a lot personally.

. 

Tyk API Designer

I was playing around with Tyk API Designer the other day and I noticed there are 2 ways to edit an API - API Designer or Raw API Definition.

  

API Designer View

Raw API Definition View

I'm not too sure you belong to which camp. I have team members who belong to both camps. The juniors will definitely prefer the API Designer view, while the seniors will go for the Raw API Definition view.

When we go to customers' sites, it's quite obvious. Customers will prefer API Designer view, while my team will most likely configure using the Raw API Definition view, especially when there are a lot of APIs to configure.


That's cool!

.

Data-model driven API - Good or Bad?

I came across this blog from Tyk - Your data model is not an API, while I was lying on my bed ready to sleep. 

To me, this is taking a dig at CA Live API Creator. :)

Very insightful article, indeed. This is coming from API consumers' (Customers) perspective, rather than from API developers.

Sometimes, we keep forgetting who our pay-masters are. This is why I keep reminding my team - they have to make our customers happy, not me.


I totally agree with the conclusion:

• Your API consumers want an API that is familiar to them, not to your implementation team 
• Your API consumers want an API that is fast to integrate for them, not for your internal team to implement 
• Your API consumers want an API that is flexible by offering capabilities to get things done, without creating lots of HTTP calls and stitching data together to achieve their desired outcomes 

Finally, it is important to remember that 5 hours saved by your team may cost 10s to 100s of hours by your API consumers. ... A great API design makes it easy for API consumers by hiding internal implementation details, leading to faster integration and happy developers.

It is definitely not easy to design an API.

From our experience with a large insurer in Singapore, we know it could take weeks to design a useful API. Sometimes, we could end up having heated arguments with our customer's application teams, because we do not agree with certain design methodology. But the end result is great! There's nothing wrong with disagreements, as long as it's for the good of the project.


.