Full OpenDS adoption questionnaire responses from Michael Schwartz, founder and CEO of Gluu, Inc. provider of Gluu.org.

Date : July 2009

Can you tell us more about your company ?

Gluu is a San Antonio, TX based startup offering a cloud based Identity as a Service (IDaaS) that aims to make it easier for organizations to securely share identity information and to achieve SSO via SAML.

Gluu aims to be an open cloud based federation infrastructure that will empower organizations to create small and large “Communities” on-demand, as in social networking applications. After joining a Gluu Community, an organization can specify which people from their organization and what attributes of those people are shared within the Community.

While inter-domain SAML federation networks have been successful in specific vertical markets, (for example InCommon for educational institutions), the goal of Gluu is greater than user-centric SSO. The primary problem that Gluu seeks to address is extranet identity life-cycle management. While provisioning workflows for adding and deleting people within the organization have been well defined (if not easily solved), scalable flow of identity information across organizational boundaries has simply not been addressed by current products and services.

Gluu, acting as a trusted third party, performs the role of an identity clearinghouse and federation exchange. This can be especially useful for large enterprises with thousands of partners. The task of keeping extranet information up to date is critical, expensive, and logistically challenging.

An important design goal of Gluu is to accommodate organizations with varying degrees of technical sophistication: from a one person company to a large enterprise. Consequently, there are several methods for managing identities in Gluu. For very small organizations without internal IT departments, Gluu offers manual delegated administration. For large organizations, Gluu offers integration via SPML. For organizations in the middle, Gluu offers an appliance approach that uses a virtual directory server to map LDAP and RDBMS data on the Gluu member’s internal network. The appliance also detects changes and updates Gluu.

Can you tell us about the application, site, or service in which you have adopted OpenDS?

In order to build a globally ubiquitous identity infrastructure, a horizontally scalable, virtualized directory service was necessary. Gluu’s directory service distinguishes between data that is mastered within Gluu (for example, data created by Organizations through Gluu’s delegated administration) and data that is simply shared through Gluu while owned and mastered in the organizations’ internal systems. RDBMS is used to model Groups and Communities, although Groups are also virtualized in LDAP (they are needed for ACI enforcement).

OpenDS is used at Gluu whenever LDAP data is persisted. This includes data that is mastered within Gluu, in which case OpenDS is configured for multi-master replication. But it also includes data that is cached on Gluu, where the goal is performance versus robustness. While information about people is the primary data stored in LDAP, OpenDS is also the external configuration store for OpenSSO.

The OpenDS DSML gateway is the basis of Gluu’s dsml service: https://dsml.gluu.org, run and load balanced on Tomcat servers. DSML was chosen because it is easier to manage network security and high availability with an HTTP web service protocol, although LDAPS may be supported directly in the future.

Another design challenge of Gluu was to enable organizations to dynamically extend the user and group schema. The ability of organizations to use Communities to solve their specific business needs requires the schema to be extensible. With OpenDS, it was possible to extend schema on the fly, enabling schema extension to be built into the Gluu application workflow.

Another distinct advantage of OpenDS is the portability inherent in Java. Both Linux and Windows are used to develop Gluu. The development platforms vary widely: Vista, XP, Fedora, Red Hat, 64-bit, 32-bit. OpenDS has almost the same deployment configuration process on all these platforms. But more importantly, it runs! With previous versions of 5.x and 6.x Sun Directory servers, we would not have had distributions to work on all our system platforms.

Below is a high level diagram of the Gluu Infrastructure:

How and when did you first find out about OpenDS?

Its been a while, but I think I heard about it first at a Sun Directory Servers Masters event in Somerset NJ. I used it first for a POC project, where we needed to deploy and configure a sample DS quickly and easily.

Did you go through an evaluation process before selecting OpenDS? If so, can you tell us a little bit about the process and results?

It was the only DS that met our requirements, other than DSEE 6.3. But the open source license, and portability made it a better choice for Gluu.

What specific version of OpenDS are you using?

1.2 GA

On what operating system do you run OpenDS? Do you use the same OS for both development and production deployment?

Mentioned above.

On what hardware platform do you run OpenDS? Do you use the same platform for both development and production deployment?

In production we are using commodity cloud servers, which are currently 64-bit, quad core Xeon X3220 processors. In development, we use a wide array of servers, laptops, desktops, and VM images.

Have you purchased a OpenDS license? If not, have you thought about doing so and do you know it includes access to patches and sustaining releases (more details from http://wikis.sun.com/display/sunopends)?

Gluu will license OpenDS at a later date.

What specific features of OpenDS are you using?

Most important, we use OpenDS for LDAP persistence. We feel very confident in the read, write and authentication performance, and how that persistence scales predictably with an increased amount of data. Other features that Gluu utilizes include multi-master replication, the DSML Gateway, SSL, multiple suffixes, indexing, CLI tools, password encryption services (we have incorporated the OpenDS jar file into our application to use the SSHA libraries to encrypt passwords in MySQL), and probably a few that I am either forgetting, or we take for granted.

What do you like most about OpenDS?

Its like an improved DSEE. Much of the quirkiness about DSEE has been fixed. For example, why was the configuration file called dse.ldif in DSEE (it's now config.ldif in OpenDS). Another example is supporting JKS keystores. It’s a very sensible re-implementation of an excellent product, that left what was good, but still found important ways to improve the product.

We also like the strict LDAP interpretation. We feel very confident that our client code has implemented the LDAP specifications properly if we integrate with OpenDS.

What would you most like to see improved in OpenDS?

The one advantage of DSEE over OpenDS is the Cacao integration, providing a remote agent based management infrastructure. I’d also really like to see an OpenDS Proxy, similar to the DSEE 6.3 proxy.

Also, I’d like to see more information on db optimization. What is the best ratio for database to entry cache sizing? What is the best db-page size to entry size, and how is that calculated? What is the best way to size the right value for allidsthreshold? How does logging affect performance? While I understand that nothing is going to replace benchmarking analysis, it would be helpful to see a more practical explanation of how to size.

Does your application also use a database? If so, which one?

Our business model is stored in MySQL. Seam is a JSF/EJB3 framework, and we use entity beans to manage database persistence.

Are there any figures about the scale of your adoption which you would like to share (such as how much traffic is being handled, how many entries are stored in OpenDS, how many servers are used)?

Gluu is in the alpha phase right now. The infrastructure is designed to support several billion users. Hopefully the business model can do the same.

How has OpenDS performed since your application/service went live? Have you run into any production issues which you would attribute to OpenDS?

The application has been in alpha phase in production since May 2009. We haven’t had any major problems.

Would you recommend OpenDS to others? Why?

Yes, and we do, for the reasons mentioned above.

How does OpenDS figure in your future plans?

We’re looking forward to OpenDS improvements. It’s the basis of our directory data persistence strategy. A better question is what would we replace it with if it went away? There are options, but all of them would involve compromises.

How would your describe your participation in the OpenDS project (e.g. user only, submitter of bug reports and RFEs, developer who has contributed code)?

User only, although we could probably submit a few bug reports on the status-panel !

Is there anything else you think would be of interest in a story about your OpenDS adoption?

When we run our SLAMD benchmarking, we might have more to report.