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.
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?
Spring Boot is a open-source tool which uses Java-based frameworks for building web applications.
In this article we'll be using Keycloak to secure an Angular application and access secured resources from a Spring Boot Web application.
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.
In this article we'll be using Keycloak to quickly secure a SvelteKit application with user management and single sign on (SSO) using the open source IAMs Keycloak for Authentication and Authorization. We will demonstrate the integration by securing a page for logged-in users. This quickly provides a jump-off point to more complex integrations.
In this article we'll be using Keycloak to quickly secure a Remix application with user management and single sign on (SSO) using the open source IAMs Keycloak for Authentication and Authorization. We will demonstrate the integration by securing a page for logged-in users. This quickly provides a jump-off point to more complex integrations.
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.
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.