33 posts tagged with "keycloak"

Exploring Keycloak as an alternative to PingIdentity for Authentication Solutions

In the evolving landscape of identity and access management (IAM), organizations face critical decisions regarding the tools that will best meet their needs. Keycloak and Ping Identity are two noteworthy solutions, each exhibiting unique features that cater to different organizational requirements. This blog provides a detailed comparison of open-source Keycloak and the commercial offering of Ping Identity across essential aspects of IAM solutions.

Exploring Keycloak as an alternative to OneLogin for Authentication Solutions

Keycloak and OneLogin (by One Identity) are both important players in the identity and access management (IAM) space, each catering to different organizational needs. Keycloak is an open-source solution with over eight years of active development, known for its scalability and customization. OneLogin, on the other hand, is a commercial product emphasizing user-friendly interfaces and extensive integration options. This article compares Keycloak and OneLogin based on cost, deployment, customization, scalability, functionality, integration, and support.

Exploring Keycloak as an Alternative to WorkOS for Authentication Solutions

Keycloak and WorkOS are both identity and access management (IAM) solutions that offer various features for authentication, authorization, and user management. While they serve similar purposes, there are key differences between the two platforms that make them unique and suitable for different use cases. Keycloak is an open source platform under active development for over 8 years and known for its scalability and customization options. WorkOS is a closed-source platform that can quickly integrate SSO to an application. In this blog post, we'll explore the key differences between Keycloak and WorkOS, focusing on factors such as cost of ownership, scalability, deployments, and maintenance.

An exciting new feature has been added to Phase Two Organizations Extension! Organizations now support shared Identity Providers (IdPs) for mapping multiple organizations to a single IDP. This feature is especially useful for organizations that have multiple organizations that need to share the same IDP.

Exploring Keycloak as an Alternative to Okta for Authentication Solutions​

In today's rapidly evolving digital landscape, securing and managing user identities has become more critical than ever. Organizations are faced with the challenge of choosing the right Identity and Access Management (IAM) solution that balances cost, ease of implementation, and robust feature sets. Two popular contenders in this space are Keycloak and Okta. Keycloak, an open-source solution developed by Red Hat, offers extensive customizability and a community-driven support model. On the other hand, Okta, a leading cloud-based IAM provider, promises quick deployment and comprehensive security features through its subscription-based service. In this blog post, we will delve into a detailed comparison of Keycloak and Okta, examining their costs, total cost of ownership, implementation processes, and the rich array of features and capabilities each brings to the table. Whether you're a small startup or a large enterprise, understanding these key differences will help you make an informed decision for your identity management needs.

Since we first released our (most) popular Keycloak extension, Keycloak Organizations (Orgs) and made it available as open source on Github, the Keycloak maintainers have decided to build into native organization support.

This begs the question? What is different between Keycloak's upcoming organizations feature and the Phase Two Organization Extension?

Exploring Keycloak as an Alternative to Auth0 for Authentication Solutions​

When it comes to implementing authentication and authorization in web applications, Auth0 and Keycloak are two prominent solutions that offer robust security features. While Auth0 is a popular choice for many developers due to its comprehensive, cloud-based platform, Keycloak presents a compelling alternative, especially in terms of cost and flexibility. This blog post will delve into how Keycloak stacks up against Auth0, focusing on cost of ownership, architecture and deployment, maintenance, functionality, community and support.

We recently gave a talk at the Keycloak DevDay 2024 conference in Frankfurt on our Organizations extension which provides single Realm multi-tenancy to Keycloak for modern SaaS applications. The hosts of the conference have posted the video of the talk on Youtube.

Keeping your brand consistent across user touch-points is important to modern Saas companies. Just like customizing Login Pages, customizing your email templates is just as important. Keycloak has a number of templates which can be customized.

Keycloak starts out with simple text templates, but unless you like spending your days looking at Unix terminals, you probably prefer some color and images in your emails.

With many companies racing into the cloud, very little is written about the huge opportunity, and potential pitfalls of building software for on-prem and private cloud deployments. With the growing Kubernetes and CNCF ecosystems, the balance point to justify self-hosting is constantly shifting. This is great news for companies that must host data and applications inside the enterprise. For software vendors looking to serve this exploding market, authentication can be a blind spot.

A story, inspired by customer use cases:​

You’ve built a successful enterprise SaaS product, and your cloud offering has taken off. Recently, you’ve been getting inquiries from government agencies, large companies in regulated industries, and foreign companies – all of which have legal, compliance or regulatory requirements that prohibit them from using your product in the cloud.

Given the size of the opportunity, you’ve decided to go for it. Your team has packaged your application up as a set of Kubernetes manifests, making changes, replacing cloud services with open source alternatives, and even built out a runbook to help your devops peers at the customer operate it themselves.

The big day comes, and you’re installing at your first customer. You expect that there will be some minor bumps along the way, but their first question just flattens you: “How do we connect this to our in-house identity provider?” It was a question that was never on your radar, but now it’s the most important thing for the customer.

Like most SaaS companies, you’re probably either hand-rolling your authentication and user management using something like Passport.js, Devise, Django, etc., using some social login options, or using a cloud-only service like Auth0 or WorkOS. If you had implemented SAML, the most common protocol for just-in-time user provisioning with enterprise identity providers, you probably went for a basic approach. You wrongly assumed that user management and identity brokering would be easier for on-prem.

You throw some engineering and customer success resources at the problem, but quickly realize it’s not a scalable solution. The customer wants to map their groups, and manage access and authorization through their IdP. Just the overhead of connecting to every possible type of IdP, and supporting that for every customer, will eat up your margin before they start using your application.