OpenDJ Rest API - Part III

In case you encounter the same error as what I encountered, this is what I did to resolve the issue.

The entry ou=people,dc=example,dc=com specified as the search base does not exist in the Directory Server.

Kind of strange to me initially. When I installed OpenDJ, I have explicitly configured my root suffix to be dc=azlabs, dc=sg. How come the Rest2Ldap interface is responding with a "dc=example,dc=com" error message?

Then I remember there is a configuration file http-config.json - which I said is the "soul" of Rest2Ldap. 

There you are... by default, the http-config.json consists of mapping to "dc=example,dc=com".

All I needed to do is to change all references of "dc=example,dc=com" to "dc=azlabs,dc=sg".

After that, stop-ds followed by start-ds. Fire a curl again.

Nice!


Ops! Mine was a hacker's act. For a production system, please do the following to reload the http-config.json.

Force the HTTP Connection Handler to reread its configuration.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

$ dsconfig  set-connection-handler-prop  --hostname opendj.example.com  --port 4444  --bindDN "cn=Directory Manager"  --bindPassword password  --handler-name "HTTP Connection Handler"  --set enabled:false  --no-prompt $ dsconfig  set-connection-handler-prop  --hostname opendj.example.com  --port 4444  --bindDN "cn=Directory Manager"  --bindPassword password  --handler-name "HTTP Connection Handler"  --set enabled:true  --no-prompt

.

OpenDJ Rest API - Part II

I continued to have fun with OpenDJ Rest2Ldap Interface. 

So how does one determine whether the Rest2Ldap interface is enabled? By default, it is disabled. 

To enable, follow the below example:

$ ./dsconfig set-connection-handler-prop --hostname am2.cdemo.sg --port 15444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "HTTP Connection Handler" --set listen-port:18080 --set enabled:true --no-prompt --trustAll

$ netstat -an | grep 18080

tcp        0      0 :::18080                    :::*                        LISTEN

We can use the status command to check the HTTP Connection Handler status (aka Rest2Ldap interface).

Or, like myself, we can take a look at config.ldif.

ds-cfg-config-file is the "soul" of Rest2Ldap.

This is where the mapping occurs to expose directory data over HTTP as JSON resources. The artifact for serving JSON resources is a REST to LDAP Gateway, which is technically a Servlet. The Servlet will be followed by a REST to LDAP Connection Handler within OpenDJ.


The benefit is of course to allow applications that do not support LDAP protocol to retrieve directory data via HTTP transport.


.

OpenDJ Rest API

I had some free time this week, so I continued to explore the Rest2Ldap interface in OpenDJ 2.6.0.

It was fun as this is something new to me. I'm not really a REST/JSON guy. I leave it to our younger colleagues. Ha!

So I was having fun until I hit into the following problem when I attempted to list all users whose user names contains "user.200". 

{"code":400,"reason":"Bad Request","message":"The value 'userName co user.200' for parameter '_queryFilter' could not be parsed as a valid query filter"} ...

What's that? I was fairly sure I typed words by words from the examples in OpenDJ Administration Guide.

After a while, I spent some more time reading the documentation again and found out how silly I was.

Make sure you URL encode the filter expressions! Ok, so sorry.

So I downloaded Simple REST Client add-on for my Chrome and that solved the issue.

Overall, I found it a refreshing way to query a LDAP server which traditionally has to go via the LDAP connection route. e.g. if you write a Java class, you would need to query a LDAP server via Java LDAP Programming/API. And most likely, you'll need to download and deploy LDAP SDK onto the web container.

By using REST API, there is no more hassle. A much cleaner way for modern developers who are very well-versed in REST/JSON.

.

OpenDJ vs OUD - Part II

I came across this comparison chart which clearly illustrates how the ForgeRock Open Identity Stack has evolved after Sun Microsystems sun-set.

The following chart attempts to compare OpenDJ against Directory Services offering from Oracle.

Oracle has 3 different directory products to choose from. The Sun OpenDS code base provides the foundation for both Oracle Unified Directory and OpenDJ which means all the advantages of the Oracle product can be found in OpenDJ as well - Internet scalability, HA, and support for use cases for the enterprise and cloud - except OpenDJ is 100% open source with an actively and rapidly contributing community and the flexibility to customize code.

Not forgetting the fact which I have mentioned in my previous blog - OpenDJ vs OUD - Which do you need? - key team members from OpenDS projects are now in ForgeRock.

So who will have the more superior product over time?

The choice is really yours...


.

OpenDJ vs OUD - Which do you need?

An old Sun DSEE Customer asked me whether they should go for OUD or OpenDJ. 

I showed them the following comparison.

Immediately, they jumped into the conclusion that they should go for OUD. Hang on!


I asked Customer the following questions and this is the response I got.

There you are … most customers only need Core Directory Service and at most, Proxy Directory Service. There's really not much demand for Virtual Directory Service (at least for this region).

Next, I shared with them the state of most Identity Products Today. See slides here - Open Identity Stack.

From my understanding, all 3 components in OpenDJ (Core, Proxy, Virtual) are/will be built from scratch and complement one another. They are built to work as a seamless stack. They are not acquired and then magically plug-and-play to sell as a bundle.

I pointed a very important fact to Customer.

I said it multiple times in my blog before. Here they are:
0. OpenDJ Roadmap
1. ForgeRock Customer Support Services
2. Commercial Open Source from ForgeRock

Now, it is also important to note that key team members from OpenDS projects are now in ForgeRock. They include Ludovic Poitou (OpenDJ Product Manager) and Matthew Swift (Chief Architect, OpenDJ).


The next thing I asked Customer to consider is cost.

Is there a way to pay less if one only needs the Core Directory Service?

Some products are sold as a bundle. You need to pay the price for the bundle, regardless of whether or not you need all the products within the bundle. Take it or leave it.


By the way, before I left,  I referred Customer to this success story which was implemented 2 years ago when OpenDJ was only at version 2.4.

3 data-centers (and different sites), and over 2.5 Million entries. Yes, it's a fact!


OpenDJ is now at 2.6.0 and so much better, with a long list of new features.


The choice is yours...


.

Replication Gateway - Part III

I blogged about OUD providing a Replication Gateway (note: this is different from Replication Server) to help replicate data two-ways from Sun DSEE to Oracle OpenDS or Unified Directory.

And I mentioned that there is in fact an alternative to replicate data from Sun DSEE to ForgeRock OpenDJ - which is using LDAP Synchronization Connector.

I was in ForgeRock Open Identity European Summit in Paris few weeks back and someone shared with me some bad experiences customers had when they used the Replication Gateway. I was told it did not work so beautifully. Strangely, directory schema was replicated!

Err… isn't the directory schema in the new OpenDS (aka OUD) not meant to be the same as the old Sun DSEE? OpenDS is supposed to be a revamp, but an upgrade for Sun DSEE.


.

OS Patching and the Impact

I encountered a Priority 1 case in a customer site 2 weeks ago with an OpenSSO deployment for one of our government ministries. 

What really happened was the Single Sign-On infrastructure became unstable after a Solaris Patch Cluster was applied, especially during high-load.

No one realised the issue right after patching. There was even a round of internal testing conducted and the system was given the go-ahead by the administrator.

But on the 1st working day after the patching, the help-desk received numerous calls that authentication was "sometimes OK, sometimes not OK". They thought the farm of OpenSSO servers were restarting one at a time. But no one touched the OpenSSO servers at all.

We observed that CPU consumptions were on the high side and connection timeouts were often encountered.

I was consulted. As I was helping customers with tuning in another environment where our Solaris servers were recently patched and encountered poor performance, I thought it was a good bet to roll back the Solaris Patch Cluster.

As the fire was on the Production side, a decision was made to perform the roll-back on the servers in the Production environment first. That solved the issue!

Root cause? I'll let the Oracle experts tell us since they are paid to service us.

Once the fire was put off, we also subsequently roll-back the patch on our QAT environment and we were back in business.

Lesson learnt is OS Patching does have impact on the performance of the software that is installed on top of it. Do not ignore this fact. Load testing after patching will be ideal if time permits. (well, I would say no one does this 90% of the time. :> )

.

Zimbra Collaboration Suite - Open Source Edition

Zimbra got a new lease of life after Telligent bought it over. I'm happy that development for Zimbra continues as our own mail server is Zimbra! :) We have been using it for years.

Recently, Zimbra releases Collaboration Server 8.0. We'll be looking forward to upgrading to this new and exciting version!

By the way, there are various deployment models to choose from when deploying Zimbra Collaboration Server.

Again, Cloud is a platform which software developers cannot choose not to support these days.


.

Social Login for Single Sign-On

I have a customer who has already implemented Facebook OAuth2 authentication module in their existing OpenAM infrastructure. So I was having an annual review with them last week and they intended to expand the type of OAuth2 authentication for their customers.

Today, I came across this blog from Gigya - The Landscape of Social Login: The Identity War Heats Up.

Pretty much sum up which Social Login should be the next in line.

.

Open-source software projects need to improve vulnerability handling practices

I came across an article in TechWorld - Open-source software projects need to improve vulnerability handling practices.

The optimists believe in the following and they think every Open-Source Software developer will behave the same:

There's a line of thought among some users that open-source software is more secure than commercial software because there are more people looking at the source code and providing feedback or because open-source projects can patch issues faster.

In reality, this is hardly true. And that explains why most CIOs are pessimists, especially in Singapore.

While in other Asia regions (especially South-East Asia) where budget is limited, CIOs in Singapore have relatively huge budget to work with. Cost is never in their top-priority list. Security is, especially if they are looking for suitable Identity and Access Management software.

It is seldom the best-features product that wins tenders. (I was naive few years back that  I'll surely win any project if I have the best product in the market in terms of features, scalability and cost-effectiveness. I learnt my lesson. Humble now.) 

I think the process in handling security vulnerability must be transparent and communicated again and again.

I just visited Apache Software Foundation site and was pretty impressed with the way they communicate how they handle security vulnerability. The steps in handling security vulnerability are listed in detail.

They even have dedicated team with corresponding email addresses for certain high-usage products.

Now, it is never enough to tell potential customers that "there is a team of smart developers helping to take a look as and when security vulnerability is found. These are the smartest people around who know this particular open-source software inside out. They are the ones you need if vulnerability is found. And by the way, this is the email address you can forward your concern to."

CIOs are not stupid, I have to say that.

They need to be convinced that there is indeed a process in place and a dedicated security team to rely on as and when critical vulnerability occurs. Turnaround time in resolving the security loop-hole is very important to them.

By the way, if there is indeed a process in place, then it's better that the same information is communicated to the public. Otherwise, who knows you are working hard behind the scene?

Communication is an art.


.