OpenAM Web Policy Agent Version

I was upgrading a few OpenAM Web Policy Agent to version 3.3.4 for a customer yesterday and found something which I have been always wanted to comment about.

In OpenSSOAgentBootstrap.properties, you'll see the following:

#------------------------------------------------------------------------------
# Web Agents Bootstrap File
#
# OpenAM Policy Agent
#
# Version: 3.0

####################################################

The same goes to OpenSSOAgentConfiguration.properties.

#------------------------------------------------------------------------------
# Web Agents Configuration Property File
#
# OpenAM Policy Agent
#
# Version: 3.0

####################################################

I would very much prefer it indicates the exact version from operational point of view. (The ones who implement/deploy a system usually are not the ones maintaining it)

#------------------------------------------------------------------------------

# Web Agents Bootstrap File

#

# OpenAM Policy Agent

#

# Version: 3.3.4

#####################################################

Yes, I know the policy agent version will be displayed in the amAgent debug log. But over time, it gets rotated.


2015-03-26 21:29:37.108       -1 12788:773c80 all: =======================================
2015-03-26 21:29:37.108       -1 12788:773c80 all: Version: 3.3.4
2015-03-26 21:29:37.108       -1 12788:773c80 all: Revision: 12082
2015-03-26 21:29:37.108       -1 12788:773c80 all: Build Date: Jan 15 2015 17:13:06
2015-03-26 21:29:37.108       -1 12788:773c80 all: Build Machine: constable.internal.forgerock.com
2015-03-26 21:29:37.108       -1 12788:773c80 all: =======================================
2015-03-26 21:29:37.117       -1 12788:773c80 all: naming_validator(): validation disabled



By the way, there are 2 new features introduced in OpenAM Policy Agent 3.3.4.

There are also some important changes in version 3.3.4.

The following 3 properties are introduced in OpenSSOAgentBootstrap.properties.

# Agent initialization related properties
#
# - init.retry.max:   maximum number of consecutive agent initialization retries. Default (not set) value is 0.
# - init.retry.wait:  wait time (value in seconds) between retries. Default (not set) value is 0.
# - nss.shutdown:     enables (value: on) or disables (value: off) Mozilla NSS/NSPR framework shutdown in the agent module.
#                     Set this property to off in case the agent is used together with other Web Server modules using NSS/NSPR.
#                     Default (not set) value is on.
#
# Hot-Swap Enabled: No
#
com.forgerock.agents.init.retry.max =
com.forgerock.agents.init.retry.wait =
# com.forgerock.agents.nss.shutdown = on

.

OpenAM Security Patch

I am preparing myself before heading to my customer's site to help them patch their OpenAM 10.0.2 servers.

The past patches used to be standalone. So if there are 2 security advisories that introduced 3 patches, then one had to perform patch 3 times.

Today, I am seeing an accumulated patch released by ForgeRock for OpenAM.

So besides #201503-01 and #201503-02, it contains previous patches that were introduced some months back.

Is this a good move? Pretty convenient I would say because this particular customer has not applied #201502-* yet.

So this saves my time.


.

Configuration Data Store Indexes for External OpenDJ

In production, the Configuration Data Store is usually an external OpenDJ server. In fact, most usually a pair of OpenDJ servers.

There is a section in OpenAM documentation - Preparing an External Configuration Data Store, which is useful . Read here.

The most important item is to set indexes on OpenDJ during configuration. See below:

In a recent deployment, I have forgotten to set the above indexes and the machine where OpenDJ servers were running on always hit 90-100% CPU. Very top-ish through the day.

After the indexes were set, the OpenDJ servers went back to normal.  Proper indexing does help.


.

ForgeRock has set up APJ HQ in Singapore

Finally, it's official. ForgeRock announced that it has set up its Asia-Pacific Japan (APJ) regional headquarters in Singapore. Full press release here.

In fact, we have been working closely with Sumal & team since December 2014. Customers in the Asia region, especially those in Singapore, have been asking for ForgeRock's presence years ago. This has finally become a reality.

In addition, support engineers will also be stationed in Singapore to better serve customers in this region.

This is a great start to the year!


By the way, Singapore Press Holdings is Azimuth's customer. :)

.