Cyril's Identity Management Blog

Interested in monitoring OpenAM ? I suggest you to have a look at this tool, developed by a collegue of mine. Leave us your feedback !

Forgerock's just releases OpenAM 10.1 as well as OpenIDM 2.1. For details about these new versions, see this:
OpenAM
OpenIDM

It makes no doubt that a new OpenDJ version should also follow in a near future.

Concerning OpenAM, the most important improvments are new policy agents (version 3.1), an OAUTH 2.0 server, and an enhanced and simplified IDM REST API On its side, OpenIDM brings too many things to mention here. See above !

The different layers of caches in OpenAM 3.0.4 agents may look confusing if you're not careful. Moreover, web agents, J2EE agents or SDK clients accept different configuration parameters with regards to caches and notifications. That's why I decided to write this page in order to try to clarify that. So let's go:

OpenAM 3.04 Web (Apache, IIS, ....) agent caches parameters

com.sun.identity.agents.config.policy.cache.polling.interval
# POLICY CACHE POLLING INTERVAL
#   This property determines the amount of time (in minutes) an entry
#   remains valid after it has been added to the cache. The default
#   value for this property is 3 minutes.
#
# Hot-Swap Enabled: No

com.sun.identity.agents.config.sso.cache.polling.interval
# SSO TOKEN CACHE POLLING INTERVAL
#   This property determines the amount of time (in minutes) an sso entry
#   remains valid after it has been added to the cache. The default
#   value for this property is 3 minutes.
#
# Hot-Swap Enabled: No

com.sun.identity.agents.config.polling.interval
# AGENT CONFIGURATION POLLING INTERVAL
#   Agent fetches new configuration either from server or local file(i.e. this file)
#   based on agent repository type value: centralized/local.
#   If agent is configured with AM 7.x, then agent uses local file(i.e. this file)
#   The value is in minutes.
#
# Hot-Swap Enabled: No

com.sun.identity.agents.config.notification.enable
#
# NOTIFICATION PROPERTIES
#   - notification.enable: Should the policy SDK use the OpenSSO server notification
#       mechanism to maintain the consistency of its internal cache?  If the value
#       is false, then a polling mechanism is used to maintain cache consistency.
#       Possible values are true or false.
# Hot-Swap Enabled: No

OpenAM 3.0.4 J2EE (Tomcat, Weblogic, ....) agent caches parameters

com.sun.identity.idm.remote.notification.enabled
# Set enabled to true to enable notifications for the IdRepo cache.

com.iplanet.am.sdk.remote.pollingTime
# Set pollingTime to the poll frequency in minutes for the IdRepo cache, if notification are enabled.

com.sun.identity.agents.config.load.interval
# This property specifies the interval in seconds between configuration reloads. When this
 property is set to 0, the hot-swap mechanism is disabled.

com.sun.identity.agents.notification.enabled
# When set to true, enable notifications of security policy changes. If false, polling is enabled

com.sun.identity.agents.polling.interval
# Security policies cache polling time in minutes 

com.iplanet.am.session.client.polling.enable
# Enable or disable agent polling for session cache. If disabled, sessions changes are notified by OpenAM.

com.iplanet.am.session.client.polling.period
# Session cache refresh interval in seconds, when session cache polling is enabled

com.sun.identity.sm.notification.enabled
# Set to true to enable configuration data change notifications. If false, polling is enabled.

com.sun.identity.sm.cacheTime
# Set notification.enabled to false and set cacheTime to the poll frequency in minutes to enable polling for the configuration cache.

Also, if you didn't find what you were looking for, I'd suggest you to read this page, from the Forgerock's wiki. Happy authentications !

I recently had to install OpenAM 10 over Jboss 5. While a priori easy, it turned out to be somewhat more complex than expected. First of all, the default Jboss 5 configuration must be modified in order to successfully run the OpenAM 10 wizard. On one side, there're no special instructions neither in the official OpenAM 10 installation guide nor in the release notes, to use Jboss 5. So, I was just expecting the installation wizard to complete successfully but it was actually always failing for different reasons, with several error messages. Looking at the problem closer, it became clearer that the OpenAM 10 war file deployment was producing abnormal warnings and errors, even before executing the configuration wizard.
The fix was to modify the Jboss class loader behaviour, as documented here: OpenAM 10 deployment with Jboss 5

The second problem I met occured when trying to use a non default context root for the OpenAM configuration repository. At least, using "cn=openam" produced parsing errors later near the end of the wizard and I didn't find any solution other than using the default "dc=java,dc=opensso,dc=net" suffix. By the way, also keep in mind that deploying OpenAM at the root of your application server (that is with a context of "/") is not supported, while not clearly documented yet.

Let me finally mention a couple of best practices when deploying OpenAM: firstly, always leave the root realm unchanged (unless it really makes sense to customize it slightly), and rather create and customize your own sub-realm(s), in order to split the administrative tasks and configurations from your business needs. It also makes it easier to recover from a misconfiguration. Secondly, leave the agents definitions at the top realm, because they're better managed by top level security administrators, and use referral policies to delegate access control to sub-realms.

I recently had to setup a couple of OpenLDAP servers in mirror replication mode, to authenticate users accessing Unix hosts, ranging from Fedora 11 to 14, and CentOS 6. I had already setup that kind of solution a few years ago, and I have to say it's a lot more mature and stable now. I mean both the client and server side have been improved, especially with OpenLDAP 2.4.31 which prooves to be the first 2.4.x "production" version.

Also, most of the LDAP clients configuration keeps consistent now, while it used to be very heterogeneous in the past. Yet, some progress still needs to be done, in the encryption area, for example, where libraries are not always fully compatible from one client application to another, even on the same system.
Also, a newcomer (in comparison with PAM or NSS) in the authentication area now spreads to the different Linux flavours: SSSD. SSSD stands for System Security Services Daemon. It can be seen as a "nscd partner", but since it's more recent, it also enhances the authentication process, especially when using a network authentication server like LDAP.
Indeed, sssd has the ability to work offline, (as far as users have already authenticated online once), which can be convenient on a laptop. Also, sssd runs over NSS and PAM, so it probably won't break your existing authentication process, and actually improves it. There're many options to configure it, especially to adjust its cache behaviour, so it can really make sense in some environments at least. Also, sssd efficiently deals with the boot process, especially when your LDAP server is down, and can also be used on the LDAP server itself, while configuring the LDAP server as its own client used to bring problems in the past. So, enjoy it !

There're actually 2 distincts parts in client certificate authentication with Oracle DSEE or former Sun directory server versions.

The first part is really standards (TLS,SSL v3) based: both client and server authenticate to each other as they'd in a usual SSL handshake like HTTPS. Then, ODSEE adds a second optional check (the 2nd part): it can make sure the certificate sent by the client is the same as the one stored in the LDAP entry for that client. That's why if you want to use that option, enabling it also requires to configure ODSEE so that it knows how and where to find the LDAP entry representing the client in its database(s), and where to find the attribute in that entry.
The second check is primarily intended in case of certificate renewal of the CA, to make sure clients (especially browsers) will present the right certificate after a while, preventing them to use a possibly still valid (from a time validity point of view) certificate signed by the right CA but with an old CA key.
Also, notice that DSEE has a security related option to allow or require a client certificate, when running over SSL/TLS. In both cases, the client will present a certificate (if he has a valid one of course), but if you set the server option to "allow", DSEE will then simply ignore it.

In the past few days, I had the opportunity to test OpenIG, the OpenAM Open Identity Gateway. It's an architecture component to be used as a reverse proxy between browsers and applications. The great benefit of OpenIG is that it makes it possible to extend your SSO or federation network to existing applications, without modifying them. So, it's useful when you've to deal with "black box like" applications.

OpenIG comes as a Java web application you simply deploy in your favorite application server. Most of the gateway configuration is located in a json file where you have to describe the requests flow through the gateway, thanks to provided filters. These filters can extract data from the incoming requests, and/or use it to replay credentials, or whatever the backend applicatin requires.

Some filters may also use a database, an LDAP directory, a flat file, HTTP headers, SAML assertions, or an OpenAM agent to extract data and submit it to the application, without user interaction.

I just wonder how it performs since it's not a real reverse proxy but rather a lego that can act as a reverse proxy. Moreover, as a rather new product, I'd test it intensively before moving to production. At least, a reasonable option would be to use it aside a true reverse proxy, to offload the gateway from static pages.

OATH and Google authenticator are some relatively new components of the IAM/IDM world, that could change our lives some day: OATH, (not to confound with OAuth !), proposes the wide adoption of OTP based and 2 factor authentication frameworks, making the web actors exchanges more secure, easier to implement and easier to integrate thanks to some well known authentication standards like HOTP.

OATH also features simplified authentication thanks to federation (that is some kind of virtually unlimited web SSO). The very new thing here is that OATH proposes a standard framework at the users, devices, and networks levels, potentially making adoption faster.

Google authenticator, on its side, is one of Google's user friendly solution to the authentication and identity thieft issues: if your application or authentication server supports Google authenticator, then your users will be able to benefit from strong authentication (one time password based authentication) just by downloading the Google authenticator Android application on their smart phone. Interesting at least for businesses requiring more security in the cloud.

And thus, if you noticed the title of this article, you may wonder what's Authentic 2, with regards to OATH and Google authenticator ? Well, it's the new version of an authentication software server that supports each of them, and also proposes many other identity related features like a federation gateway and PAM support.

Did you know that OpenDJ, one of the major open source directory server, features a powerful logging interface ? For each need and use case, the OpenDJ logging system brings a solution to debug, finely tune and optimize or just filter out what you want or don't want to see in your logs.

For example, let's have a look at a few commands below...

Use this one to enable nanoseconds accuracy for LDAP operations execution time:

dsconfig -j mypasswordfile -Xn set-global-configuration-prop --set etime-resolution:nanoseconds

Use this one to enable the debug log with a somewhat talkative log level:

dsconfig -j mypasswordfile -Xn set-log-publisher-prop --publisher-name File-Based Debug Logger --set default-debug-level:verbose --set enabled:true

The last one below is a bit more complicated:

dsconfig -j mypasswordfile -Xn set-log-publisher-prop --publisher-name "File-Based Access Logger" --set connection-client-address-not-equal-to:10.0.0.1 --set log-record-type:extended --set response-etime-less-than:500 --set log-format:combined --set log-control-oids:true --set suppress-internal-operations:true --set buffer-size:512kb --set filtering-policy:exclusive --set queue-size:100000

It would have the following effects:

- it would exclude (from the access log) access requests issued by the 10.0.0.1 IP address, which can be very useful for example to prevent load balancers health-check requests from being logged, making the access log grow large unusefully if not excluded.
- it would also exclude LDAP extended operations like the replication trafic for example
- it would also exclude requests that took less than half a millisecond (500 ns) to be served. In such a case, it's recommended to log both requests and results on the same line, for the same operation. That's exactly what the "log-format:combined" parameter does.
- it would log LDAP controls OIDs, as well as the server internal LDAP operations like the ones executed by some enabled plugins
- finally, to limit disks I/O and improve the overall throughput, it would increase the default asynchronous access logger queue size as well as the log buffer size.

It's been a while since my previous post, so let's push 2 articles today. OpenDJ brings some nice features in comparison with Sun DSEE, but may also give you some headaches if you don't closely read the documentation (I did !).

Among the good things, it's possible to have a very fine grained directory administration with OpenDJ, thanks to privileges. Privileges define administrative rights one must gain in order to perform some specific operations. It can be administrative operations, but also operations on data. For example, in order to be able to modify the access control rules (stored as aci attributes in the LDAP entries), defining the right acis is not enough, one needs the modify-acl privilege. Among other privileges, any user can be assigned the right to bypass the whole acis, thanks to the bypass-acl privilege, or to execute unindexed searches, which is forbidden by default.

Among some other features that require special care, OpenDJ now distinguishes between user and operational attributes in acis, in such a way that when specifying "all" in an aci, it means all user attributes, implicitly excluding the operational attributes. To target them in acis, they now have to be explicitly mentioned. Or you can alternatively use the special keyword "+" to target all operational attributes.So, beware !