Thursday, February 27, 2014

Policy Agent Notification

Recently, there was a discussion in OpenAM mailing list regarding Policy Agent notification which I think is worth mentioning. 

Imagine there is a cluster of application servers (for similar application, say App A) deployed behind a hardware load-balancer. 

 Of course, we need to deploy an OpenAM Policy Agent on each application server. Now, the question is: For ease of configuration, should we just create 1 x Agent in OpenAM administration console as both agents are identical?

The answer is no. Why?

See the diagram below. If agent notification is enabled and each policy agent has its own unique notification URL, then OpenAM server is able to push notification to each of them.

Now, if the 2 policy agents are "hiding behind a load-balancer" (since we only want to create 1 x Agent configuration in OpenAM administration console), the notification URL has to be set to the load-balancer FQDN.

In this case, whenever OpenAM wants to push notification, one and only one of the 2 policy agents will get notified.

This is not ideal.


Tuesday, February 25, 2014

OpenAM Data Store - High-Availability and Load-Balancing

It has been an interesting day trying to explain how the high-availability (failover) and load-balancing work in OpenAM for a customer.


In OpenAM administration console, the following is shown in the Data Stores tab:

This is unlike the authentication module where administrator can key in a Primary LDAP and a Secondary LDAP as shown below.

I am not able to find any useful documentation from ForgeRock at the moment. The below is an extract from old Sun OpenSSO documentation:

LDAP Server
Enter the name of the LDAP server to which OpenSSO will be connected in the format host.domain:portnumber. If more than one entry is entered, an attempt is made to connect to the first host in the list. The next entry in the list is tried only if the attempt to connect to the current host fails.   
Optionally, a server identifier and site identifier can be appended to the value of the LDAP Server attribute for redundancy. In this case, the format is host.domain:portnumber|serverID|siteID. These identifiers are assigned to the server when they are configured globally. 
  • serverID specifies a particular server as the primary LDAP server and others as secondary and tertiary (as defined) fallback servers. (If no number is specified, the LDAP server is primary.) The identifier is displayed in the OpenSSO console. 
  • siteID is not currently displayed in the OpenSSO console. It is a two digit number generated internally by OpenSSO — for example, 02. 
My colleague pointed me to the source code for OpenAM 10.0.0 - We dived into the getLDAPServerName() method.

private void getLDAPServerName(Map configParams) {
  List firstChoiceList = new ArrayList();
  List secondChoiceList = new ArrayList();
  // put ldapServer from list into a string seperated by space for
  // failover purposes. LDAPConnection will automatcially handle failover.
  // hostname:portnumber | severID | siteID
  // serverID is optional. if omitted, it means any(don't care).
  // siteID is optional. if omitted, it means any(don't care).
  // host whose siteID and serverID matches webtop naming's serverid and
  // siteid are put in the front of the list as well as those host which
  // did not specify a siteid/serverid because of backward compatibliity.
  // otherwise it will go to the end of the list.

Hey, good comment there inside the codes! This complement the documentation from OpenSSO.

So, I spent some time reading the codes and tracing it through with examples.


If your setting is as follows, then it only caters for High-Availability (failover/redundancy), but not load-balancing. The second AD (AD2) is always idle waiting in case of failover.

To put in simply, refer to the diagram below:


If your setting is as follows, then it caters for High-Availability as well as load-balancing. Both ADs (AD1 and AD2) are at work at the same time.


Thursday, February 20, 2014

Open Web Application Security Project - Top 10 for 2013

I came across OWASP Top 10 for 2013 and found it to be informative.

The OWASP Top 10 focuses on identifying the most serious risks for a broad array of organizations. For each of these risks, we provide generic information about likelihood and technical impact using the following simple ratings scheme, which is based on the OWASP Risk Rating Methodology.

So, here's the link to Top 10 for 2013. Quite alarming that Injection and XSS are still on top of the list year in year out.


Tuesday, February 11, 2014

What's the reasons to Move from OpenSSO to OpenAM?

If you still have Sun OpenSSO running and need reasons to move to OpenAM, wait no more … Sign up for the webinar - 100,000 Reasons to Move from OpenSSO to OpenAM …. Steve, with his ever in-depth knowledge of Sun Access Manager, Sun OpenSSO and ForgeRock OpenAM, will explain why!

The most important point he'll touch on is:

ForgeRock provides a very simple upgrade so that you can take your existing Oracle OpenSSO deployment -- now EOL'd with no significant updates since 2010 -- and immediately transform it into a next-generation access management platform.


Monday, February 10, 2014

Multi-Tenant for OpenDJ


Ludo has a great piece of advice when designing multi-tenant services for OpenDJ. Read here - OpenDJ Backends and Multi-Tenant Services.