How to Plug an Existing User Store into WSO2 Identity Server?
- Dinali Dabarera
- Senior Solutions Engineer - WSO2
Are you someone who already has a legacy system in place and wants to migrate to a modern authentication system with Identity and Access Management (IAM) features? The first thing you need to consider is how you can use the existing legacy user store with this new system. Keep in mind that if the legacy user store uses an old security mechanism to store your data, we would recommend that you migrate to the WSO2 JDBC user store format or Active Directory (AD).
Requirement 1: Directly plug an AD or LDAP
With WSO2 Identity Server, you can directly plug your standard Active Directory and LDAP/OpenLDAP. You would need to provide the credentials for the user store directly in configurations (Primary — deployment.toml file, secondary — UI configuration in management console)
> For Primary Read- write Active Directory user store configurations, you can refer to the following documentation.
> For Secondary - adding connection details in the UI, as shown in the image below, will easily connect to your Active Directory or LDAP.
By doing this, you can authenticate any application that connects to WSO2 Identity Server, through the user store credentials, with matching rules and authorization.
Requirement 2: Federating an existing user store or AD
WSO2 Identity Server supports all standard protocols. As such, if you need to plug a user store like LifeRay or Azure AD, we can integrate them as Federated Identity Providers. Some of the common integrations are:
-
Liferay has a highly extensible architecture, making it easy to integrate.
-
Azure AD integration is common among enterprise users.
Azure AD integration is common among enterprise users. It enables organizations with existing and on-premise user stores to securely and conveniently extend user identities to Office 365 without the burden of Microsoft-provided federation tools such as Active Directory Federation Services (ADFS).
Requirement 3: Plug an existing JDBC user store with its schema
There are two ways to achieve this requirement with WSO2 Identity Server.
Approach 1
Plug as a secondary UniqueIDJDBCUserstore and change the SQL queries to match your schema. The SQL queries are available in the secondary user store > Advanced properties section.
You also can change the password hashing algorithm.
Approach 2
Write a custom user store manager by overriding all the user store operation methods which match your user store. The following documentation will give you the classes that you need to extend, and the methods that you need to override.
If this sounds interesting, we encourage you to try out the early adopter version of Asgardeo, an identity as a service (IDaaS) solution that enables developers without security expertise to easily embed customer identity and access management (CIAM) features into their apps within minutes.
You can also follow us on Twitter or join the IAM4Devs community. Alternatively, if you’re looking for an enterprise-grade, API-driven, open source solution that can manage millions of user identities without spiraling costs, please check out WSO2 Identity Server.