In some circumstances, a free, open-source tool such as Keycloak can be a good option if you want to move from an old, on-premise version of Oracle Access Management. How to carry out such a migration? We’ve tested this during some of our projects and can guide you through the process.
Before we move on to migration details, let’s first define the two solutions we’ll talk about in this article: Oracle Access Management and Keycloak.
What is Oracle Identity and Access Management?
Oracle Identity and Access Management is a collection of products that enable management and automation of the user identity lifecycle and provide users with access to enterprise resources. Oracle IAM consists of 2 main components:
- Oracle Access Management – it’s used to manage authentication and authorization processes, ensuring access to resources only to authorized users. OAM offers Single Sign-On (SSO) functions, user session management, and security policies.
- Oracle Identity Governance – Oracle Identity Governance (OIG) combines Oracle Identity Manager (OIM) and Oracle Access Management Suite. It is used for user lifecycle management, automated granting and revoking of permissions, and resource management. It also offers self-service features that allow users to manage their accounts themselves.
Oracle IAM offers support for both on-premise and cloud environments, but in the following article, we will focus on the on-premise variant, the last version of which was 12c (12.2.1.4.0), released in 2019. Moving to OCI (Oracle Cloud Infrastructure) is the go-to choice for many companies that use an old, on-premise version of Oracle IAM, but there are some cases when Keycloak can be a better option.
What is Keycloak?
Keycloak is an open-source identity and access management system with authentication and user management features. Due to the system’s openness, the list of its functionalities is somewhat unlimited – you can expand its main core with dedicated extensions (plugins). You can learn more about this technology in our Keycloak SSO – advantages of Single Sign-On and a ready-made access management system article.
Oracle IAM vs Keycloak comparison
| Category | Oracle IAM | Keycloak |
| Type | Commercial solution | Open source (developed by Red Hat) |
| Pricing model | License fee | Free (costs incurred by infrastructure, implementation, customization and support) |
| Main features (SSO, MFA) | Yes | Yes, with the option of configuration or writing your own implementation |
| Integrations | Integrations with other Oracle products and external systems | Several ready-made integrations; can be expanded with any integration |
| Support | Technical support offered by Oracle | Mainly social support; commercial support available from Red Hat |
| Customization | Limited compared to Keycloak | High level of customization |
When should you consider migrating to Keycloak?
There are two main scenarios when moving from Oracle IAM to Keycloak is a good option:
- Cutting long-term costs – Oracle IAM’s pricing model is based on the number of users, which means its costs will grow along with your business. Replacing this commercial solution with an open-source product allows you to eliminate license costs (it introduces other expenses, too, but these won’t grow as fast and can be easier to manage).
- Need for other features, integrations, or customization options – Keycloak offers a lot more in terms of customization. You can expand it with plenty of additional features and integrations, which isn’t as easy to do (or is plainly impossible) in the case of Oracle Access Management.
Migration scenario
The key point during analysis and planning in the entire user migration process is the choice of migration strategy between mass and Just-In-Time (JIT). A detailed description of these 2 strategies is available in our Okta vs. Keycloak comparison article. In this scenario, we’ll focus on a JIT migration using the Keycloak functionality of user federation.
Step 1– Analysis and planning
- Defining the scope of migration (which users, what data).
- Assessment of the current system and data structure. In the case of a non-standard database – which doesn’t provide the LDAP protocol – you should consider the provider’s implementation.
- Planning a strategy for preparing compatible versions of applications that use IAM.
- Planning a strategy for testing and validating migrated data.
Step 2 – Communication with users
- Informing users about the upcoming migration, possible interruptions, and any changes that may affect them.
Step 3 – Installing and configuring Keycloak
- Selecting the appropriate infrastructure to host the new IAM system.
- Installing the Keycloak server, along with any extensions.
- Configuring server settings and additional extensions.
- User federation configuration.
- Creating application clients in Keycloak.
- Preparing new versions of applications integrated with the previous IAM system to ensure their compatibility with Keycloak.
Step 4 – Testing
- Testing functionalities such as login, password reset, and access to resources.
Step 5 – Application update and configuration
- Uploading and configuring new versions of applications – compatible with Keycloak – in the production environment.
- Testing the integration of these applications with Keycloak.
Log-in sequence diagram
For your convenience, here’s a ready-made diagram visualizing the log-in sequence in Keycloak.
Configuring Keycloak
- Log in to the Keycloak admin panel.
- Go to the User Federation configuration section and select LDAP using Add new provider.
- Complete the configuration and save.
Potential problem – Application migration
Additionally, if your applications were hosted on Oracle WebLogic Server and you plan to move away from that platform, you will need to migrate them to your chosen hosting platform or application server. The migration process can be carried out in parallel with the IAM migration or as a separate project after switching to Keycloak.
In theory, application migration involves moving the application and its data to a new environment and then making all the necessary configurations. Unfortunately, it’s rarely that simple in practice. Migration can be complicated. It is recommended to conduct a detailed analysis of each migrated application and carefully plan the entire process.
Conclusion
Migrating from Oracle Access Management to Keycloak can be a good option in some circumstances – especially when you want to stay on-premise (no OCI), need a specific feature that Oracle IAM doesn’t offer, or want to minimize license costs. This kind of migration is also not too problematic to carry out. In this article, we’ve focused on the JIT migration scenario, but mass migration is also possible. For more information on migration strategies and Keycloak, check out our other articles:
- Keycloak SSO – advantages of Single Sign-On and a ready-made access management system
- Okta vs Keycloak: Comparison and easy Okta to Keycloak migration guide
- Migrating from Azure AD B2C to Keycloak – Possible scenarios and useful tips
Need help with an Oracle Access Management – Keycloak migration?
If you have any questions or doubts and are unsure how to carry out the migration, you can always ask us for help. Our migration specialists have plenty of experience with such projects, and will gladly do the work for you. Write to us at hello@pretius.com or use the contact form below – we’ll see what we can do for you. Initial consultations with Pretius are always free.
