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. As a product burried deep in the Red Hat middleware stack, does it have enough revenue associated with it to guarantee continued investment?
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. But we’ve survived 11 years now with zero outside capital! We’re in it for the long term. We are under no pressure to sell Gluu. We’re fairly optimistic, even with this terrible economic outlook. Although IT spending will certainly be down in the near term, remote access is an area that may actually benefit. From a competition standpoint, there are fewer companies in the market then when we started. As 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. The Keycloak team admits “It has a number of scalability issues like the number of realms and clients.” They go on the say that the session strategy doesn’t scale: “Sessions are only kept in-memory, which can be good for performance, but not so great for scaling when you consider a large portion of sessions are idle and unused most of the time.”
We are concerned about Keycloak’s reliance on the Infinispan cache, which is a subsytem of the Wildfly J2EE Application Server. 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 supports the use of Redis or Couchbase as the cache. We can also leverage the cache service of cloud providers like Amazon. For small deployments, you can use LDAP as the cache! Yes… it’s an oxymore to use a database to “cache”, but the use case here is replication to achieve active-active low-concurrency HA topologies.
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. Gluu is passing all OpenID Connect OP certification profiles, including for FAPI. 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? For us at Gluu, open source IAM components are not the enemy–they are the opportunity. We’re not afraid to harness the power of open source innovation or to collaborate. And when there are gaps, we’re not afraid to write code.
Right now we are on the sidelines with Keycloak. But if good things happen there, maybe we’ll dive in.
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