Install OpenDJ Directory Server With a Properties File

We were working with some AWS engineers on creating puppet scripts for a Open Identity Stack installation.

OpenDJ installation with a properties file was what we tackled first since it is fairly easy to get OpenDJ up and running, with command line.

There is a section in ForgeRock Documentation that describes how to Install OpenDJ Directory Server With a Properties File.

A sample properties file was given, but it was unclear what is the use of ldifFile?

As I didn't know what was that ldifFile parameter for, I commented it during installation. All went fine and the installation was completed successfully. But ...

When we started to configure OpenAM, we encountered error - "Invalid Suffix".

So I fired up OpenDJ Control Panel to take a look, and I discovered why. 

There was no entry at all. 

Usually when I install OpenDJ via command line, I would be given an option to choose like the following:

And I usually choose Option 1. I needed an equivalent via the Properties File installation method.

The documentation was not clear enough what we should do in such a situation. So I played around with the ldifFile parameter. I should define a base entry in the ldif File. And that will do.

dn: dc=cdemo,dc=sg
dc: cdemo
objectClass: top
objectClass: domain

And that really solved the issue! A check with OpenDJ Control Panel showed everything was in place after the successful configuration of OpenAM.

Nice!

.

OpenAM 12 Sessions

Peter has a nice blog (Sessions) regarding how sessions work in OpenAM, especially in release 12 onwards.

I was discussing with a customer few days ago regarding how to deploy OpenAM optimally on Amazon Web Services. One topic which we discussed in-depth was how does OpenAM session work and why do OpenAM nodes need to be aware of one another.


ForgeRock documentation has a lot of information regarding how the Core Token Service (CTS) works and how performance is optimised when Reduced Crosstalk is enabled.

However, the documentation did not mention much about any activity besides sessions validation via cross-talk. 

Our discussion that day was : "What is the other usage(s) of crosstalk? Can we remove crosstalk totally as we scale up/down frequently in AWS environment? If not, what happens when an OpenAM node is removed from site? Will crosstalk becomes the performance bottleneck in "non-locatable" OpenAM situation? "

Luckily, as what Peter has mentioned in his blog, Cluster State Service is here to help. 

Monitoring servers

As we already know, under normal circumstances OpenAM uses crosstalk when requests gets misrouted, and this is something that does not change once session failover is enabled. Although the sessions are stored in OpenDJ, OpenAM will remain to send crosstalk requests to the other instances (in essence, this behavior is what the reduced crosstalk mode attempts to change).

In case of session failover it doesn’t really help if AM waits on crosstalk response from a node which may be actually unavailable. In order to prevent this scenario, there is a component that gets automatically enabled once session failover has been enabled: the ClusterStateService (or CSS as I’d like to call it). The ClusterStateService essentially tries to monitor the servers within the current site (and since 12 it also monitors remote site URLs), so that if there is a need to do a crosstalk, OpenAM first checks with ClusterStateService whether the given node is available, before sending any kind of crosstalk request.

Great stuff!


PS: Peter has started using diagrams in his blog! Keep it up! :)

.

OpenAM 12 : Changes & Deprecated Functionality

We kick-started an Open Identity Stack (OpenAM, OpenIdM, OpenDJ) project yesterday. * feeling excited *

So for this project, we intend to use OpenAM 12.0.1 - the latest release to 12 series.


In Additional New Features, I saw the following which my customers asked for:

• Audit Logging to Syslog
• CORS Support for OpenAM APIs
• Session Failover Across Sites
• Whitelist for Custom Login URIs
• Policy Support for Common HTTP Operations

Personally, since I'm very much into the internal working of OpenAM, my favourite will be:

• Reduced Cross-Talk

In OpenAM 12, there are quite a number of important changes which we need to be aware of. Read Chapter 3. OpenAM Changes & Deprecated Functionality.

The Policy Evaluation engine has undergone huge changes, so one has to be careful here when performing an upgrade. Luckily this is a green field project!

There is also a lot of fixes - read 4.1. Key Fixes.


.

Adaptive Risk Authentication

Adaptive Risk Authentication has been built into most SSO products these days. Should I say all? It used to be an add-on module or by-product, which customers have to pay extra. However, these days, we are seeing that this feature is shipped by default.


So, what makes a good authentication of choice? I found this slide from a CA webinar.

.

OpenAM 13 : Stateless Sessions

OpenAM 13 is scheduled to be released in Q4 2015, according to OpenAM Roadmap.

One of the new features I am looking forward to is Stateless Sessions for Scale and Elasticity. There is a slide (Customer Scale: Stateless Sessions and Managing High-Volume Digital Services) that can better illustrate this feature.


Basically, what we know of OpenAM now is it can only handle stateful sessions. This means in a highly-available deployment, failover storage (OpenDJ used as CTS) is required. This makes deployment slightly more tricky and at times cumbersome. It is especially true if multiple data centers are involved.

In some deployments where session failover is not required, a stateless session architecture is much preferred. Cleaner and faster. SSO product like CA SiteMinder is stateless by default.

.

Tomcat container log file is filling up with messages from OpenAM's OAuth authorization service

I was browsing through OpenAM 12 documentation and came across the Troubleshooting section.

There is this particular FAQ that caught my attention.

Q: My container log file is filling up with messages from OpenAM's OAuth authorization service and OpenID Connect provider. What can I do to prevent all these messages from being logged?

I shall paste the answer shamelessly from the OpenAM documentation.

A:

This behavior is governed by the log settings for RESTlet, which is used by OpenAM for OAuth 2.0 and OpenID Connect 1.0. Use log configuration settings to turn off logging from RESTlet.

For example, if your container is Apache Tomcat, follow these steps.

1. Stop Tomcat.

$ /path/to/tomcat/bin/shutdown.sh

       

2. Edit the Tomcat settings script, catalina.sh or catalina.bat, to use the logging configuration file.

For example, in /path/to/tomcat/bin/catalina.sh, uncomment the following line, and then save your work:

LOGGING_CONFIG= \

  "-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties"

3. In $CATALINA_BASE/conf/logging.properties, add the following line, and then save your work:

org.restlet.level=OFF

       

4. Start Tomcat.

$ /path/to/tomcat/bin/startup.sh

I have seen these logs in catalina.out in my customer's Tomcat servers, but did not find the time to find out why they appear there. This solves the mystery. :)

.

Device Identification to prevent Session Hijacking

This slide was from a webinar from CA I attended. It talked about how to prevent session hijacking by using device identification techniques.

So, besides ensuring the user is coming in from a "trusted" device during initial authentication, each access to a protected application is validated again. 

This can be quite resource intensive, but if an application is sensitive and of highest importance to customers, then it makes sense.

.