Keycloak is a very good open source SSO server, with lots of features, and a strong community. Red Hat is the corporate backer of the project.
How does Gluu compare to Keycloak? We get asked this question a lot! We’re looking very closely at the direction of KeyCloak. Following are some thoughts.
First some level setting. The Gluu Server, our flagship product, is a platform. Just as a Linux distribution is not one piece of software, the Gluu Server is a distribution of several open source components, integrated together. These components include web services, database, caching and administrative pieces. We test these components, and then we provide support and patches on them for years. Keycloak is just one component. You need to use Keycloak with other components to create an IAM platform like the Gluu Server. But hypothetically, Gluu could use the Apache 2.0 licensed Keycloak as an SSO web service component. Is this likely to happen? For the near term, the answer is no. But if Keycloak keeps improving, you never know! Following are some considerations.
We see a lot of Keycloak business risk. Granted, we’re looking out 5-10 years, and in that time, a lot can happen. For now, Red Hat seems committed to the project. But with all the things that could change in the IBM/Red Hat landscape in the next few years, it’s hard for us to understand or predict the possible implications. IBM is under pressure to be a leader in the cloud–so where will it allocate it’s R&D investment priorities? If Red Hat were to cut back it’s investment, we do not think a volunteer lead project can sustain innovation. From our experience, the most predictable way to lead in innovation is to have a strong business model behind the project.
You might say that Gluu has just as much business risk. We could go out of business or be aquired by a large company that hates open source. However, from a Gluu perspective, those are risks we understand! Fundamentally, business is good. There are actually fewer companies in the market then when we started. At the same time, the size of the market is growing. Perhaps we’re naively optimistic about the demand for hybrid-cloud IAM solutions. But from our perspective, the general industry trends look favorable. And we are a pure play IAM software vendor–there is nothing else to distract us.
Everyone loves good old transactional RDBMS platforms. But RDBMS systems have some scale issues–it’s hard to create an active-active replication topology, which is ideal if you have a globally distributed authentication service. Also, it’s hard to the scale RDBMS horizontally. LDAP has strong replication capabilities and good performance, and is as the database engine of choice by both Ping, Forgerock and many of our predecessors. Like RDBMS, LDAP has issues scaling horizontally. For this reason, Gluu supports a NoSQL option: Couchbase can support multi-datacenter sharded deploments, and enables you to individually scale the query, index and data services.
We are concerned about Keycloak’s reliance on the Infinispan cache, which is a subsytem of the Wildfly J2EE Application Server. Gluu supports the use of Redis or Couchbase as the cache. For small deployments, you can just use the database–caching is not super important. For large deployments, we think moving the memory requirement to Redis or Couchbase makes more sense. In the Gluu Server, we deploy our Java applications in light-weight jetty servlet containers–trying to stay away from relying on complex (i.e. slow to start) J2EE application servers.
Gluu tries to be the best in OAuth. While Keycloak is a pretty decent OpenID Connect implementation, we believe that Gluu’s OAuth project (“oxAuth”) covers more features, and is more flexible to configure. We’ve gone out of our way to introduce many interfaces that enable you to customize the behavior of the responses from the Gluu Server. Futhermore, Gluu has the most comprehensive current shipping implementation of the User Managed Access protocol, a profile of OAuth that enables API access control. In particular, Keycloak does not implement the claims gathering endpoint of UMA, which is the front channel used to interact with a person if authorization cannot be otherwise obtained. Use cases for the UMA claims gathering endpoint include consent management, progressive risk profiling, and stepped-up authentication workflows.
To run a mission critical IAM system, many components have to work together. Much of the performance of the system is derived from proper configuration of the database and cache. Without a standard deployment strategy for all the components, much of the work is left to the system administrators to figure out. If every deployment is a one-off, it’s hard to drive down the cost of operations. Gluu looks at the IAM platform wholistically. Reduced finger pointing is achieved by standard devops strategies for all the components.
So what does it all mean? Is Keycloak Ali or Frazier? Luckily, the open source world is not a zero sum game. For us at Gluu, cool new open source IAM components are not the enemy–they are the opportunity. We can harness the power of open source innovation. And when there are gaps, we can fill them with our own software.
Right now we are on the sidelines with Keycloak. But who knows… maybe for another product or offering, it will make sense. Let’s see how the community continues to evolve.
If you want to learn more, you can read about our open source strategy on this blog.
Subscribe to Get News and Product Updates
our RSS Feed