My company is using Auth0 for identity management and we would like to migrate to one of:
Can you suggest what advantages and disadvantage have any platform? Are there features that stand out for any in particular or that would be especially relevant for migrating from Auth0?
So far I was able to install gluu server, keycloak and wso2 seems very tricky.
I'm the founder of Gluu. I can shed some light on the design decisions:
It is true that we leverage good open source components, where an active community exists. Why should we re-invent the wheel? The Shibboleth IDP is an excellent, comprehensive implementation. Issues are addressed quickly by the Shibboleth Consortium, which funds developers to research any potential problems, and patch the software quickly. We also use Passport-js. With over 300 strategies for many social networks, we couldn't posssibly cover the range of connectors needed if we wrote everything ourselves. Finally, we forked the last open source release of OpenDJ, which has been stable for us in production for over a decade. You could say that in many ways, Gluu is the vacuum cleaner of open source--we find good open source components, and integrate them into our platform. This enables us to focus on developing the components where we add the most value--OAuth2, UMA, OpenID Connect and devops tools. In these areas we can't rely on an external community to innovate fast enough. Nothing is new in SAML or LDAP. But OAuth is rapidly evolving. So our goal is to adopt software where the standards are very stable, and to write software where we need to innovate quickly. Beware of companies that want to write the entire stack--this leads to major weaknesses in the product, because no company can be an expert in everything. The strength of the open source development methodlogy is leveraging the community.
We work very hard to integrate the components together to lower deployment and operational cost. If you don't believe me, try installing the Gluu Server. All you have to do is install the package, run the setup program, answer about 10 questions, and it's up and running. Compare that to the deployment instructions of other IAM platforms--either open source or commercial. What you'll find is that they will have you dropping war files in servlet containers, hand editing config files, configuring databases, starting many services, configuring web servers, and so on. You could say that any linux distribution is also a bunch of open source software glued together. But like a linux distribution, the Gluu Server is integrated, tested and supported for a long period of time. For over a decade, we've been supporting mission critical deployments in finance, government, telco, healthcare, retail, university and many more sectors. Furthermore, over time, we have optimized the Gluu Server for low operational cost. Over time, the opererational cost is the major contributor to TCO (total cost of ownership). Operational cost exceeds even license cost--so if you think a commercial product is less expensive to operate--you should pay the license. We've accomplished low TCO by provide administration GUI's and tools. And by reducing one-offs integrations and proprietary security solutions (by supporting only widely adopted open standards for security). One vendor's quick proprietary solution is tomorrow's support / upgrade headache.
Gluu has made a huge investment in "identity brokering", which we call managing "inbound identity". That's why we have integrated Passport-JS. You can accept inbound identities from SAML, OpenID Connect, CAS, Facebook, Microsoft Azure AD, Linkedin or over 300 different social login providers. In fact, inbound identity is a driver for our business. No other platform offers as much flexibility to control the workflow around how to map attributes, dynamically register users (who show up at your website for the first time via social login or SAML), or additional implement fraud detection techniques post-assertion.
We have tested with OpenJDK. Version 2.4.4 used OpenJDK only. The question about which open source JVM to use is an industry issue that is the same for everyone: Keycloak, WS02 and Gluu all use Java. Operational cost, speed, clustering, features: these are the drivers for what IAM platform to deploy--not the JVM.
When you consider open source IAM, you should look at four essential ingredients: code, docs, packages, and support. If you consider all these factors, you'll see that Gluu is the only one with a strong story in each category. The packages are particularly important. Gluu provides packages for Centos, Red Hat, Ubuntu, and Debian. We also provide a linux container distribution, Kubernetes, and soon Helm charts. System adminstrators don't want the code, they want easy to install binaries (and easy to upgrade). Comprehensive documentation is also an issue. And finally, community support is essential. A mailing list is not enough for IAM. The issues are too complex. That's why we launched a support portal: https://support.gluu.org Gluu spends a lot of time answering community questions. While there are always limits--we're not going to support huge companies indefinitely (we do make a living selling support contracts)--we do review every support issue and try to help the community get stared, and get past any blocking issues.
Keycloak is part of Red Hat, which is being acquired by IBM. This has created quite a bit of uncertainty around the product, which is unfortunate. I'd like to see a robust market for open source IAM. However, the reality is that IBM has an IAM platform, and whether Keycloak is folded into this offering, end-of-lifed, or forked is an open question that neither IBM or Red Hat has addressed. IBM will not allow engineers to work on open source projects that compete with their own products. So if Keycloak continues, the current team will have to leave their employer, or someone else will have to fork it. That's easier said then done. At Gluu, we've been building a business around the open soure platform, and it's really a tough market. There are large competitors, and strong SaaS offerings (like Okta, Microsoft Azure AD, and Google Identity). Forking the code is not enough--given the innnovation and increasing security surface area, an IAM product needs a sustained effort to keep it relevant. IAM infrastructure is hard to replace. Make sure you understand that what you install will be around for a long time. At Gluu, we've been at it for 10 years. We are internally funded, so we have no VC's breathing down our necks to provide them with an exit. We have a long term vision to win in the on-premise IAM market by building the best product, and by attracting the largest community to our product. That might take several more decades. But we are in this for the long term.
Make sure the products you are considering have at least passed the OpenID Connect Certifications: https://openid.net/certification/
Even though the Gluu Server does a lot, it is still only a part of a larger open source identity/security community. That's one of the reasons I wrote a book on the topic, called "Securing the Perimeter". It covers the theory behind the product (What is SAML?) and also shows examples of how to use the Gluu Server, and... other open source products to achieve your goals. You can find it on Apress at: https://gluu.co/book
The Gluu Server was designed with three goals in mind: 1) Speed; 2) Redundancy; 3) Low TCO. There is a big difference between a "project" and a "product". Products include the docs, QA, packaging, marketing, support, training, devops tools--the totality of all the stuff you need to make the project successful. And there is also a difference between a "product" and a "platform". The Gluu Server is not our only product. We also have: 1) Super Gluu (mobile FIDO 2FA app); 2) oxd (OAuth client middleware server); 3) Cluster Manager (GUI for deploying Clusters); 4) Casa (Web Portal for Credential Mgt / Consent Mgt); 5) Gluu Gateway (Kong-CE based API gateway).
I hope you find these points useful in your evaluation. Deciding which IAM platform to use is a big decision--it may be with you for a decade or more. If you decide to use the Gluu Server, you'll be most welcome to the community. And I think you'll find that there are a lot of great features coming in the future which will cement our position as the market leader in open source IAM.
I'm doing a similar search and overall they appear to be very similar, meaning that any one of them probably wouldn't be a bad choice:
I'm documenting my results here, but I'll try to highlight my main takeaways:
Unfortunately what set it apart for me were the red flags that popped up as I looked into it:
Gluu is different from many other products in that they've taken a number of other open-source products, added some of their own pieces, and packaged it all together. I was hesitant to even try it because I was concerned about how well all the pieces would interact and how well Gluu would be able to support components that were built by somebody else.
One such component is Shibboleth IdP, which Gluu relies on for SAML. At the time of my original inquiry, Shibboleth IdP did not support OpenJDK, and so I was concerned that Gluu would have the same limitation. While Shibboleth IdP now provides partial support for OpenJDK, it appears Gluu does not yet support it:
we don't QA OpenJDK. So if you make that switch, we can't support it.
https://support.gluu.org/installation/7035/replace-oracle-java-with-openjdk/
My concerns caused me to pass on Gluu during my own inquiry, but I would encourage you to read Mike Schwartz's answer for a different perspective.
Unlike Gluu, Keycloak was designed from the ground up as a single product. It's also the only product out of the 3 that supports OpenJDK. (As already noted, this is no longer true)
Keycloak seemed like the best fit for my situation so it was the only one of the three that I actually tried.
I ran into a couple small bugs and noticed on a couple occasions that the documentation wasn't specific enough to fully walk me through the task at hand. That may be a result of its relative immaturity (the first release was September 2014), but in spite of this it felt like a solid product overall.
I don't have expertise in these, but based on the other products you listed, these may interest you as well:
If there's not much distance between the products in terms of features then some suggestions to think about:
These suggestions may each be more or less applicable to you - they are not ordered by importance. The point is you want the solution best for your situation, weighing up getting started quickly and also long-term growth
