Skip to main content

7 posts tagged with "release"

View All Tags

· 2 min read

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.

Take a look at how easy it is to get started:

The clusters that run our deployments are available in two regions (AWS, us-west-2 and eu-central-1), and are backed by CockroachDB, giving you scale, resilience and low-latency performance. In the future, clusters and dedicated instances will be available in other regions based on demand.

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

TRY IT NOW!

· 2 min read

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.

To that end, we've implemented two pathways for creating a magic link. One can be configured in the Authentication section of the admin UI by duplicating the Browser flow, and replacing the normal Username/Password/OTP forms with the Magic Link execution type Install Magic Link Authenticator in Browser Flow This mechanism inserts a authenticator in the login flow that intercepts the email address and sends the magic link in an email to to the user.

We've also implemented a web service that allows you to create a magic link without necessarily sending an email. This will allow you to send the link through another channel. Specification for the new endpoint can be found in the Magic Link API Documentation.

Both methods have the option of forcing the creation of a new user when an unknown email address is used. This allows a combination login/registration flow that combines an email verification. We think this really nails reducing friction in a new user flow.

We're open sourcing the Keycloak extensionsso that the broad Keycloak community can benefit right away. We are doing this in line with our committment to keeping our core extensions open source. 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-magic-link

· One min read

Today we're open sourcing set of Keycloak extensions 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 committment 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.

A variation of this code has been built, enhanced and used in production by several customers for almost two years. It is now available as open source for members of the broader Keycloak community. 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-orgs

· One min read

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.

Today we're pleased to report that we've listened to both use cases and completed embedding the "wizard" product into Phase Two. We're calling it "Connect", as it's the best way we could come up with characterizing its simplicity. It massively reduces the complexit of configuring SSO connections, and distills the process into something any member of the team can understand.

Phase Two Connect is currently available by invitation only while we work out the final kinks. Contact sales for more information.

· One min read

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.

Furthermore, the identity provider that is being integrated can present a similarly extensive interface that may not use the same terms and language. However, after investigation into the most common identity providers, we found that most of the configuration options can simply be set by convention if the vendor is known.

Based on that observation, we've built what we call a "wizard" UI on top of our identity provider configuration to make it easy to integration the top commercial identity provider vendors. Take a look at a quick video of a setup using our most recent prototype.

If you're interested in early access to our "wizards", please contact us today.

· 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

· 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!