Skip to main content

· One min read

Per our committment to keeping our core extensions open source, today we're releasing our Keycloak extensions to the event system. These extensions form the basis of how our Audit Log features are built.

Additionally, we're providing several goodies that will be valuable to others building extensions on top of Keycloak, including a generic scriptable event listener, an event emitter to send events to any HTTP endpoint, a mechanism for retrieving event listener configurations from realm attributes, a mechanism for running multiple event listeners of the same type with different configurations, and a unified event model with facility for subscribing to webhooks.

We hope you find these extensions valuable, and we look forward to feedback and participation from both our customers and the wider Keycloak community.

The extension is available on GitHub https://github.com/p2-inc/keycloak-events

· 2 min read

Since our release about basing Phase Two on the Keycloak Open Source Identity and Access Management system, an our committment to keeping our core extensions open source, we've received positive feedback from customers and interest from the the Keycloak community.

We've noticed that support forums for Keycloak have many questions and requests around just getting started. Even though the software is mature, open source, and has a helpfu user community, just spinning up an environment and trying it out can be puzzling for first-time users. It's pretty clear that a lot of people just give up, because they can't get a server running, let alone configure their first realm1.

Because of that, we've decided to offer developers a FREE realm in Phase Two, so those that are interested in trying it out can get successful quickly. Free realms are limited to fewer than 1000 users and 5 SSO connections. Otherwise, there are no restrictions beyond abiding by our terms of use. Sound good? Please fill out the contact form with your company information, and we'll respond with access information for your realm.


  1. In Keycloak, a "realm" manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control.

· 2 min read

Following the initial release of Phase Two's authentication and SSO tools 3 months ago, we had a warm reception by several early- to mid- stage SaaS companies. The message was consistent. SSO was a key barrier to unlocking enterprise customers, and we had made it much easier to quickly integrate the alphabet-soup of enterprise identity providers.

Furthermore, many of our customers have responded well to our "one price per project" idea, citing that competitors and other enterprise authentication companies had pricing models that ramped on a per-user and per-SSO connection basis, making them economically unattractive to companies with business and pricing models that couldn't support that.

One of the other points that we heard loud and clear from our first customers, was the fear of vendor lock-in. Integrating tools like this can be a large effort, and can be difficult to unwind if the terms or service fall short. While our adoption of standards such as OpenID and SAML allayed some of those fears, we wanted to go a step further.

We built the initial verison of Phase Two as a set of extensions to the Keycloak Open Source Identity and Access Management system, built and maintained by Red Hat. After several months of developing for it, and operating it for our customers, we've decided to continue using it. Keycloak has been battle-tested and hardened for over 6 years. It's security and reliability is depended on by organizations from small startups to Fortune 500 companies and governments.

To put to rest any future concerns about vendor lock-in, we're committing to making our core extensions to Keycloak open source. While we will endeavor to make Phase Two simple to use, operate and scale, we will maintain compatibility so that customers can migrate to their own Keycloak deployment. Updates and links to our open source extensions will be published in the Open Source section of the documentation, and will be available in our p2-inc GitHub organization page.

We have benefitted immensely from the open source communitiy, and we are excited to give back!

· 3 min read

After building and working for startups and technology companies for almost 25 years, I found myself having a sense of déjà-vu.

Had I really built the same features and functionality over and over?

Everyone of us who has been in the industry for any length of time probably has the same feeling. Whether or not we are fully conscious of it, we probably built a (bad) version of login, registration, user management, authorization, organizations and invitations, audit logging, etc. at least one time for every company we've worked for.

In early 2018, I joined an enterprise SaaS startup, where I built the initial team and product over 18 months. Analyzing tickets and epics in the project tracking system we used, I found that over 60% of our first 18 months was spent building features and functionality like this -- essential building blocks, but not the core competency we sought to test in the marketplace. And the result of that effort was only adequate versions of those common features, which resulted in less time spent on what we were trying to prove. I began to refer to this heavy tax a "SaaS CRUD".

Was this really what everyone else was doing? I was lucky to have a large network of engineering leaders at companies that ranged from the earliest stages to the largest public companies, so I asked them. The responses were remarkably consisitent. Early stage companies wished there was something comprehensive they could adopt, and later stage and large companies lamented not adopting external tools earlier that gave them guarantees around uptime and compliance. All were aware of or had tried to knit together a mish-mash of "feature company" products, and all expressed dissatisfaction with "model mismatch" of most of the tools in the marketplace, which demanded more integration overhead than the perceived benefit allowed.

I was lucky to find others that had observed the same thing. We joined forces and spent the next 6 months interviewing companies of a range of sizes, developing a playbook for companies building new products. Based on that playbook, today we are releasing our first version of tooling designed to help application developers avoid rebuilding "SaaS CRUD".

Phase Two is designed to help SaaS companies accelerate time-to-market. Authentication and SSO are our first targets, but we plan to expand to many other areas of pain for the growing company seeking enterprise adoption. We'd love for you to join us on this journey. For product demos and to become a beta customer, please contact us!