Wednesday, May 14, 2014

Something is brewing in the future release of OpenAM regarding the Session Persistency and Cross-talk among OpenAM servers.

I am seeing the following in the documentation:

To enable crosstalk between OpenAM instances, click the Enabled box. This ensures that OpenAM instances talk with each other to resolve any non-local sessions, rather than using session persistence.

Note that if you have a large numbers of requests (for example, millions of requests per hour), the crosstalk could adversely affect server performance with the increase in network traffic.

If session persistence is enabled, the crosstalk option is not enabled by default. If session persistence is not enabled, crosstalk is automatically enabled by default. If both session persistence and crosstalk is enabled, both features will be implemented, which could result in more network traffic.

I thought the embedded OpenDJ was dead, but upon checking, it was running as per normal after it was upgraded from version 2.4.6.8102 to 2.6.1.10289.

ERROR: Upgrade required: upgrading from 8102 to 10289>>>> OpenDJ Upgrade Utility * OpenDJ will be upgraded from version 2.4.6.8102 to 2.6.1.10289 * See '/home/azlabs/var/openam1/opends/upgrade.log' for a detailed log of this operation>>>> Preparing to upgrade OpenDJ 2.5.0 modified the default configuration of the 'isMemberOf' virtual attribute so that it is included with group entries. This was done in order to make it easier for users to determine which groups a 'nested' group belongs to. Do you want to make this configuration change? (yes/no) yes The upgrade is ready to proceed. Do you wish to continue? (yes/no) yes::>>>> Performing upgrade>>>> OpenDJ was successfully upgraded from version 2.4.6.8102 to 2.6.1.10289 * See '/home/azlabs/var/openam1/opends/upgrade.log' for a detailed log of this operation

No idea then. So what to do? Clicked on Upgrade to OpenAM 11.0.1 hyperlink again. Ops! No good.

What to do next? Re-do! It's quite simple as I have already backed up every directories.

export-svc-cfg and import-svc-cfg aren't necessarily the most trustworthy backup solution for configuration data. An example where things can go wrong is OPENAM-718 and OPENAM-3793. Since my recent encounters with these commands personally I'm more inclined to use OpenDJ's export-ldif command for backup.

This email thread brought me back to an discussion I had with a customer a month back. He was reading the same document from ForgeRock and wanted to implement the same for his backup and restoration procedure.

That's not necessary, I told him. When we implemented the project, we already have a Backup and Restoration procedure in place.

Naming URL validation was introduced after release 3.0.4. The initial implementation of naming URL validation for web policy agents enabled validation by default. Naming URL validation is now fully disabled by default. You can adjust this setting by using the bootstrap configuration property, com.forgerock.agents.ext.url.validation.level.

But .... that's still not enough to verify whether the agent has been installed correctly. If the agent profile name and/or password are set up wrongly, you'll still be getting url_validator(0): https://www-uat.xxx.com:11443/openam/namingservice validation succeeded.

Try setting com.forgerock.agents.ext.url.validation.level to 0, extended URL validation will be enabled. The logs will display even more information.

2014-04-30 10:58:43.015 -1 26617:1a93cae0 all: url_validator(0): https://www-uat.xxx.com:11443/openam/namingservice validation failed with OpenAM authentication service failure (3), http status (200)
Now that the agent is verified to be installed correctly, switch com.forgerock.agents.ext.url.validation.level to 2 and we are ready to go!

Saturday, May 3, 2014

This morning, I received an email from Zimbra - Zimbra News: Important Zimbra Collaboration Security Updates.

One thing to note is we are not a paid customer of Zimbra, but we have been running Zimbra Community Free Edition for a long time. Yes, not a single cent for Zimbra to earn. But, hey ... they still send us emails regarding security updates... as and when they are found over the years!

At the same time, Zimbra Collaboration 7.2.7 has been released, which fixes some security issues as well.

In the release note, there is a dedicated section on Security Fixes, where the security flaws are described and fixes/workaround are recommended.

Cool, right? Still remember we are not a paid customer?

Now, we know there is a commotion lately regarding the way ForgeRock handles the latest security flaws found in OpenAM.

In late 2012 (well, when ForgeRock was still young), they published security advisory publicly to the community. It is still available in the Internet today.

The root causes and workarounds were publicly shared then.

Moving forward, when the latest security flaws are discovered, ForgeRock now decides to only briefly inform the community with the following email in the mailing list.

If you are a paid customer and on the latest release of OpenAM, the patch is fairly simple.

1. Download the appropriate jar for your OpenAM version

2. Restart your application server

Done. As simple as that.

And I openly and still honestly think that this "convenient service" is what paid customers deserve. (Come on, there has to be a difference. Otherwise, who will pay premium service if everyone enjoy the same benefits?) On the same day, I tweeted a sentence from OpenAM mailing list - "Open Source software is NOT free. Open Source software still takes a lot of time and money in order to produce it." I was still on the same context on the "convenient service" provided by ForgeRock to paid customers.

What I did not know then (which someone later pointed out to me. Thank you very much!) was the detailed descriptions and codes that have been fixed are only made known to paid customers. The community members are expected to look at the source code trunk and to compare what has been changed. Even if the fixed codes have been found, one has to guess what exactly was the root cause to the security flaw. But all these delays will take time.

I do not agree to this. Security flaw is big issue -- to paid customers … as well as non-paying community members. Every single deployed OpenAM should be patched at the earliest time possible.

Take a look at Redhat …

Everyone single piece of information is shared publicly, including "security".

Paid Redhat customers can immediately download the latest binaries to patch their servers, while community members need to quickly see what has been changed and to apply the same into their servers.

In my opinion, paid customers should be differentiated by:

premium, top-notch & quick turnaround support services

product features

Security fixes should not be classified as product features. It should never be.

You see.. the point is: Yes, I may not be a paid customer now. But if your product is great and your service is excellent and you treat security as your top priority, I may well pay you for commercial support one day. Better still... for my customers, I'll definitely push your paid services to them. Dun you get it? I thought this is Business 101?.

Thursday, May 1, 2014

OpenAM supports two different approaches to account lockout, where OpenAM locks an account after repeated authentication failures. Lockout works with modules for which users can enter a password incorrectly.

Memory lockout locks the user account, keeping track of the locked state only in memory, and then unlocking the account after a specified delay. Memory lockout is also released when OpenAM restarts.

Persistent account lockout works independently of account lockout mechanisms in the underlying directory server that serves as the user data store.

I am in Bangkok this week and this is the 1st question (How to configure Account Lockout?) I get from customer when I arrived. I blogged on this topic before.

In particular, Customer only wants memory lockout. Why? I seldom have this requirement. Usually, persistent lockout is the default. Ok, in fact, I seldom have requirement to configure Account Lockout feature in OpenAM at all. My recommendation is to always ride on the backend authoritative user store's (e.g. OpenDJ, Microsoft Active Directory) Password Policy.

Anyway, back to Customer's question. Account Lockout can be easily turned on by clicking on the Enabled check-box next to "Login Failure Lockout Mode". It is disabled by default.

For memory lockout, remember to uncheck Enabled check-box next to "Store Invalid Attempts in Data Store".

Simple. Isn't it?

For persistent lockout, OpenAM sets the value of the user's inetuserstatus profile attribute to inactive. You can also specify another attribute to update on lockout. You can further set a non-default attribute on which to store the number of failed authentication attempts. When you do store the number of failed attempts in the data store, other OpenAM servers accessing the user data store can also see the number.

To reverse the bold statement above: "When you do not store the number of failed attempts in the data store, other OpenAM servers cannot see the number."

Well, for multi-instance deployment, behaviour will be kind of erratic. Just take note.