Some time ago, two different projects were started in the open source community, namely: Ipsilon and Keycloak. These projects were started by groups with different backgrounds and different perspectives. In the beginning, it seemed like these two projects would have very little in common… though both aimed to include an Identity Provider (IdP) capability as one of their respective main features.
Keycloak, written in Java and originating from the JBoss ecosystem, focused on the needs of application developers who were seeking to offload authentication, access control, SSO and account management to some external entity that would simplify development and reduce related costs in a platform independent way. It is a very similar paradigm to the one I covered in a previous blog but in “Java JBoss land”.
Ipsilon, developed in Python, and targeting the Linux platform (only), was focused on the needs of IT administrators, DevOps, and non-Java developers.
As the projects moved along it became apparent that their “overlap” was growing in size and that their respective ultimate goals were more common than originally anticipated. As a result, the teams decided to merge their efforts and work towards a common solution. Keycloak was chosen as the main platform despite a lack of rpm packaging and integration with some of the low-level Linux components like GSS-proxy and SSSD. The community for Keycloak is much bigger and more active so it was an obvious choice. Over the course of the upcoming months, the teams will work together to build a robust solution that will provide the best features of both projects to deliver a general SSO solution.
Ipsilon is included as a Technology Preview with Red Hat Enterprise Linux 7.2 while an official Keycloak-based offering is still on the roadmap. If you are interested in Keycloak – you can take a look at the community version. In addition, there’s a great presentation about Keycloak that was delivered last year at the Red Hat Summit in Boston. The Ipsilon team will work with the Keycloak project to deliver better platform integration and in an effort to smooth operations with Active Directory, IdM/FreeIPA and in cross-forest trust configurations and to provide automatic configuration of Service Providers and packaging.
We hope to deliver a robust federated identity solution to our customers in the near term future. Thoughts or questions? Please reach out using the comments section below.