OpenAM Policy Agent Configuration (since v12.0.0)

If you are migrating policy agent configuration from a version earlier than 12.0.0, do take note that you need to fill in Realm and Application in Policy Client Service section.

The following is the release note from OpenAM 12.0.0. It applies to version 13.x.x.

Now, OpenAM 13.5 behaves a little different from 12. (I'm not too sure of v13.0 as I skip that version totally)

In OpenAM 13.5, there is this concept of Policy Set whereby you need to key in a Policy Set ID and Policy Set Name. Policy Set ID is hidden most of the times after initial setup.

However, when you configure Policy Agent and you need to fill in the Realm and Application, you need to be careful.

Application refers to Policy Set ID, not Policy Set Name.

Confusing isn't it, since Policy Set ID is hidden unless one clicks on the Details tab?

It's also a bit confusing that one section of the console keeps using Policy Set and Policies, while the other section keeps using Application, when they are supposed to mean the same thing.

Documentation might help a little, except they contradict slightly. 

Anyway, what will you observe if you hit into this issue?

On the frontend, this is what will be thrown:

This is especially not helpful. Reminds me of SiteMinder integration. :) One will be shown the same Internal Server Error for every possible error that can occur. Ha!

On the backend, this is what is being captured in the logs:

org.forgerock.audit.events.handlers.writers.RotatableWriter:08/23/2016 11:00:33:052 AM SGT: Thread[CsvHandler,5,main]: TransactionId[17960893-bd4e-4da2-ab8b-369a360d5a28-58]

Actually writing to file: "17960893-bd4e-4da2-ab8b-369a360d5a28-736","2016-08-23T03:00:33.051Z","AM-ACCESS-OUTCOME","17960893-bd4e-4da2-ab8b-369a360d5a28-734","id=oneaccess,ou=agent,dc=azlabs,dc=sg","[""9b54bd2abc7e586601""]","idp.azlabs.sg","443","192.168.XX.XX","41971","PLL","REQUEST_GET_RESOURCE_RESULTS",,"true","POST","https://XXX.XXX.sg/openam/policyservice","{}","{""accept"":[""text/xml""],""host"":[""XXX.XXX.sg""]}","{""amlbcookie"":""01""}",,"FAILED",,"{""reason"":""Evaluation error.\nUnable to retrieve application under realm /.\nUnable to retrieve application under realm /.""}","17","MILLISECONDS","Policy","/"

A little bit of getting used to. Otherwise, we're good to go for OpenAM 13.5! :)


.

OpenAM Security Advisories #201605

Just came back from Sydney last night. Attended ForgeRock Identity Summit, Unconference and 2 days of Partner Training. Over-loaded with new knowledge. :)

Not forgetting met up with old friends... Oh ya... and tons of beer! :>

Back to serious topic, ForgeRock announced security advisories middle of this week. The products impacted are OpenAM, OpenIG and OpenIDM.

The following is a summary of the issues found in OpenAM which I quickly sent out to my customers.

Details can be found as follows:

1. OpenAM
2. OpenIG
3. OpenIDM

Paid customers can download the patches from Backstage. Head over there quick!


.

OpenAM Console Legacy UI / XUI

So I have started playing with OpenAM 13.5 and I always have strong opinions on the UI as they undergo "progressive revamp". I do not personally like "progressive" changes as the user experience sucks... big time...


The legacy UI used to look like this...

The XUI now looks like this ...

Configure and Deployment in XUI are expanded from the Configuration in legacy UI.


Let's try navigating from left to right in OpenAM 13.5. (I would think 13 has the same UI experience)

1) Realms will bring you to the following screen. Looks pretty.

2) Configure allows you to modify Authentication, Global Services and Server Defaults. These used to be found in Configuration tab.

3) Deployment allows you to configure Servers and Sites. These used to be found in Configuration tab as well. Everything looks good so far.

4) Bomb! When you click on Federation, you'll be redirected to the legacy UI.

5) The same happens to Sessions.

Let's look further into what happens underneath Realms.

The following is from legacy UI.

In XUI, every sub-menu has been moved to the left. Looks clean!

Now, let's try to navigate from top (Dashboard) to bottom (Scripts), in sequential order.

This is one crappy user experience! The navigation journey sucks big time!

Now, maybe I'm just too picky... but what about this?

Let's say I'm right now at Dashboard in Top Level Realm.

I now want to go to configure Data Stores.. well, I'll be redirected to the legacy UI... ok .... so be it..

And let's say I'm done with configuring Data Stores, I'll want to go back to where I came from. From donkey years ago, I have been using "Back to Access Control", as this clearly implies to me that this is the way to navigate back.

Bomb!

Hello, I did not came from the screen above. I was inside Top Level Realm. I need to go back to this screen instead.

Enough? Not really ... I navigate to Deployment > Servers, as I know there is now UMA support in OpenAM. I want to know more about how it is being configured.

See anything interesting above? :)

Yes, Chinese language was shown in General, Security, Session, SDK and Directory Configuration. No issue with CTS, UMA and Advanced. 

I checked my browser language. EN-US. *strange*

This "weird" user experience will be here for a while... I do not know when the whole revamp will be completed. Meanwhile, what can you do? Nothing. 

.

OpenAM with Apache 2.0 as Reverse Proxy

I'm attending ForgeRock Identity Summit 2016 in Sydney today and the Unconference tomorrow.

The summit has just ended. Unconference is the main objective why I made the 8 hours trip from Singapore. To make the session more worthwhile for me, I decided to get refreshed on OpenAM again, in particular 13.5. (Ok, I have to admit I have been busy with other products for the past few months as we have won a big tender in Singapore.)

By the way, it is about time we upgrade the OpenAM in our labs. The current version is 11. 13.5 has just been released. It's a good time to upgrade and at the same time, learn about the new feature.

While configuring OpenAM, I came across the tip for Cookie Domain. This used to be a mandatory field. It no longer is. 

Found this in documentation - 

The default configuration sets the cookie domain based on the fully qualified domain name (FQDN) of the system. For an FQDN openam.example.com, the cookie domain is set to openam.example.com, the FQDN, by default.

So, OpenAM will auto-populate for you the cookie domain derived from your Server URL which contains your FQDN. Smart right? It's overdue.

There is also an interesting section on Apache 2.0 if you deploy it as a Reverse Proxy to a container like Tomcat, which is commonly used when deploying OpenAM.

In particular, I refer to the section on 1.8.1 Tuning Apache Multi-Processing Modules.

Apache 2.0 and later comes with Multi-Processing Modules (MPMs) that extend the basic functionality of a web server to support the wide variety of operating systems and customizations for a particular site.

The key area of performance tuning for Apache is to run in worker mode ensuring that there are enough processes and threads available to service the expected number of client requests. Apache performance is configured in the conf/extra/http-mpm.conf file. 

The key properties in this file are ThreadsPerChild and MaxClients. Together the properties control the maximum number of concurrent requests that can be processed by Apache. The default configuration allows for 150 concurrent clients spread across 6 processes of 25 threads each.

Then there is this Important Notice. 

For the policy agent notification feature, the MaxSpareThreads, ThreadLimit and ThreadsPerChild default values must not be altered; otherwise the notification queue listener thread cannot be registered.

Why? It would be good to explain the technical challenge behind this.


.

OpenAM 13.5

ForgeRock released OpenAM 13.5 few weeks ago. Well, to be politically correct, ForgeRock delivered a Mid-Year Platform Minor release few weeks ago. Marketing gimmick! :)

Behind the hook, every single product (OpenAM, OpenDJ, OpenIDM, OpenIG) is still installed individually. Versioning for each product is still not aligned - OpenAM 13.5, OpenDJ 3.5, OpenIDM 4.5, OpenIG 4.5. Why .5 and not the usual increment to .2, then .3? Marketing gimmick! :)

For the first time, ForgeRock is delivering a Mid-Year Platform Minor release that is available only to subscription customers. Non-subscribing community customers can get access to these new features in our next major release. From this point forward, we will ship product 2x per year to get you faster access to the latest features.

As this is a minor release it includes several new and important features that customers can now get access to via BackStage, including: 

• Push Authentication for Passwordless Login and Frictionless Second Factor Authentication 

• Stateless OAuth Token and Server Support 

• Identity Relationship Visualisation 

• Common Audit Event Handlers for ElasticSearch, JMS 

• API Protection (Rate Limiting) 

• Encrypted Database Entries

Let's zoom into OpenAM 13.5. Release Notes here.

The Push Authentication is a nice feature to have. Again, this is the trend these days. An Access Management product without this feature will not look attractive. Technical detail of how Push Authentication works here.

I saw a demo last week and managed to capture a few screens.

The following is a quick overview of how Push Authentication works.

Nice feature! :)

.

RSA SecurID Access Part II

This is what RSA position SecureID Access moving forward - "Secure & convenient access for any user, from anywhere to anything".

The trend these days cannot run away without Adaptive Risk (Risk-based Identity Assurance in RSA SecureID Access) and Cloud integration.

Risk-based Identity Assurance in RSA SecureID Access.

.