We've been pretty quiet over the summer. Since we released the Organizations and Magic Link extensions and open sourced them, there has been a lot of interest in using Phase Two.

We were flattered by the inbound interest, but our small team wasn't able to keep up with demand for trial accounts. Rather than scramble against that demand, we opted to pause new accounts, and instead build a self-service tool to allow anyone to quickly provision a new deployment a try it out.

Today we're announcing the beta launch of the Phase Two Self-service deployment tool. This tool allows you to easily create new deployments of the Phase Two enhanced version of Keycloak in our secure, highly-available clusters. In the future, it will also allow you to deploy dedicated instances that use your own database.

Today we're making two announcements: A new, highly-requested feature, and the open sourcing of the extension at the same time. We've received a lot of requests from customers to implement "magic link" login functionality that would allow users to login to an application using a link sent to their email or over some other secure channel.

Today we're open sourcing a set of Keycloak extensions, specifically our Organizations extension, that are focused on solving several of the common use cases of multi-tenant, SaaS applications that Keycloak does not solve out of the box. We are doing this in line with our commitment to keeping our core extensions open source. These extensions are the basis of our Organizations features, which allow Phase Two customers to model their own customers in their systems and create enterprise "team" functionality that suits their business case.

Following our post about our wizard product, we received an overwhelming amount of interest in it. Many customers of our cloud offering asked for it as a portal for their organization administrators to set up their identity providers. On-prem customers said that one consistent onboarding hurdle was SSO complexity, and asked for it to be included in the bundled distribution.

Working with one of our customers, we discovered that even the most technically literate developer or ops professional could look at the configuration for an SSO connection like it was a foreign language. While our configuration interface attempts to cover all possible options, and document clearly what each option means, it can still be entirely unclear what is required during a setup.

Per our commitment 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.

Since our release about basing Phase Two on the Keycloak Open Source Identity and Access Management system, and our commitment 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 helpful 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 realm[^1].

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, including Auth0, Okta, and many others.

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?