Configuring Primary User Stores
Every WSO2 product comes with an embedded, internal user store, which is configured in <PRODUCT_HOME>/repository/conf/user-mgt.xml
. In WSO2 Identity Server, the embedded user store is LDAP, and in other products it is JDBC. Because the domain name (unique identifier) of this default user store is set to PRIMARY
by default, it is called the primary user store.
Instead of using the embedded user store, you can set your own user store as the primary user store. Since the user store you want to connect to might have different schemas from the ones available in the embedded user store, it needs to go through an adaptation process. WSO2 products provide the following adapters to enable you to authenticate users from different types of user stores and plug into LDAP, Active Directory, and JDBC to perform authentication:
User store manager class | Description |
---|---|
org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager | Use |
org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager
| Use |
org.wso2.carbon.user.core.ldap.ActiveDirectoryUserStoreManager | Use |
org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager | Use |
The user-mgt.xml
file already has sample configurations for all of the above user stores. To enable these configurations, you must uncomment them in the code and comment out the ones that you do not need.
The following topics provide details on the various primary user stores you can configure.
If you are using LDAPS (secure) to connect to the Active Directory, you need to import its public certificate to the client-truststore.jks of the WSO2 product you are configuring.
Configuring an external LDAP or Active Directory user store
All WSO2 products can read and write users and roles from external Active Directory or LDAP user stores. You can configure WSO2 products to access these user stores in one of the following modes:
Read-only mode
Before you begin
- If you create the
user-mgt.xml
file yourself, be sure to save it in the<PRODUCT_HOME>/repository/conf
directory. - The
class
attribute for a read-only LDAP is<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager">
User management functionality is provided by default in all WSO2 Carbon-based products and is configured in the <PRODUCT_HOME>/repository/conf/user-mgt.xml
file. This file is shipped with user store manager configurations for all possible user store types (JDBC, read-only LDAP/Active Directory, read-write LDAP and read-write Active directory).
In order to configure a read-only LDAP user store you must first disable the existing embedded LDAP user store in the Identity Server. To do this, open the <PRODUCT_HOME>/repository/conf/identity/embedded-ldap.xml
file and make the following change to the enable
property.
<EmbeddedLDAP> <Property name="enable">false</Property> ....................... </EmbeddedLDAP>
The instructions given below explains how to configure a read-only LDAP or Active Directory as the primary user store for the WSO2 server.
The default User Store
The primary user store that is configured by default in the user-mgt.xml file is a JDBC user store, which reads/writes into the internal database of the product server. By default, the internal database is H2 for all WSO2 products excluding the Identity Server. This database is used by the Authorization Manager (for user authentication information) as well as the User Store Manager (for defining users and roles). In the case of the WSO2 Identity Server, the default user store is an LDAP (Apache DS) that is shipped with the product.
Note that the RDBMS used in the default configuration can remain as the database used for storing Authorization information.
Follow the given steps to configure a read-only LDAP/AD as the primary user store:
Step 1: Setting up the read-only LDAP/AD user store manager
Before you begin
- If you create the
user-mgt.xml
file yourself, be sure to save it in the<PRODUCT_HOME>/repository/conf
directory. - The
class
attribute for a read-only LDAP/Active Directory is<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager">.
Uncomment the following user store in the
<PRODUCT_HOME>/repository/conf/user-mgt.xml
file:<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager">
. Also, ensure that you comment out the configurations for any other user stores in the same file.Given below is a sample for the LDAP/AD user store configuration in read-only mode. You can change the values to match your LDAP/AD. For descriptions of the user store properties, see the related documentation.
<UserManager> <Realm> ... <UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager"> <Property name="TenantManager">org.wso2.carbon.user.core.tenant.CommonHybridLDAPTenantManager</Property> <Property name="ReadOnly">true</Property> <Property name="Disabled">false</Property> <Property name="MaxUserNameListLength">100</Property> <Property name="ConnectionURL">ldap://localhost:10389<</Property> <Property name="ConnectionName">uid=admin,ou=system</Property> <Property name="ConnectionPassword">admin</Property> <Property name="PasswordHashMethod">PLAIN_TEXT</Property> <Property name="UserSearchBase">ou=system</Property> <Property name="UserNameListFilter">(objectClass=person)</Property> <Property name="UserNameSearchFilter">(&(objectClass=person)(uid=?))</Property> <Property name="UserNameAttribute">uid</Property> <Property name="ReadGroups">true</Property> <Property name="GroupSearchBase">ou=system</Property> <Property name="GroupNameListFilter">(objectClass=groupOfNames)</Property> <Property name="GroupNameSearchFilter">(&(objectClass=groupOfNames)(cn=?))</Property> <Property name="GroupNameAttribute">cn</Property> <Property name="SharedGroupNameAttribute">cn</Property> <Property name="SharedGroupSearchBase">ou=SharedGroups,dc=wso2,dc=org</Property> <Property name="SharedGroupNameListFilter">(objectClass=groupOfNames)</Property> <Property name="SharedTenantNameListFilter">(objectClass=organizationalUnit)</Property> <Property name="SharedTenantNameAttribute">ou</Property> <Property name="SharedTenantObjectClass">organizationalUnit</Property> <Property name="MembershipAttribute">member</Property> <Property name="UserRolesCacheEnabled">true</Property> <Property name="ReplaceEscapeCharactersAtUserLogin">true</Property> <Property name="MaxRoleNameListLength">100</Property> <Property name="SCIMEnabled">false</Property> </UserStoreManager> </Realm> </UserManager>
Update the connection details to match your user store. For example:
<Property name="ConnectionURL">ldap://localhost:10389</Property>
For Active Directory, the connectionURL should have the following format:
<Property name="ConnectionURL">ldap://<AD host-ip>:<AD_listen_port></Property>
If you are using
ldaps
(secured) to connect to the Active Directory as shown below, you need to import the certificate of Active Directory to theclient-truststore.jks
of the WSO2 product. See the topic on configuring keystores for information on how to add certificates to the trust-store.<Property name="ConnectionURL">ldaps://10.100.1.100:636</Property>
Obtain a user who has permission to read all users/attributes and perform searches on the user store from your LDAP/Active Directory administrator. For example, if the privileged user is AdminLDAP and the password is 2010#Avrudu, update the following sections of the user store configuration as shown below. Note that this user does NOT have to be the system administrator that you define here.
<Property name="ConnectionName">uid=AdminLDAP,ou=system</Property> <Property name="ConnectionPassword">2010#Avrudu</Property>
Update
<Property name="UserSearchBase">
with the directory name where the users are stored. When LDAP searches for users, it will start from this location of the directory.<Property name="UserSearchBase">ou=system</Property>
Set the attribute to use as the username, typically either
cn
oruid
for LDAP. Ideally,<Property name="UserNameAttribute">
and<Property name="UserNameSearchFilter">
should refer to the same attribute. If you are not sure what attribute is available in your user store, check with your LDAP/Active Directory administrator.For example:
<Property name="UserNameAttribute">uid</Property>
Set the
ReadGroups
property to 'true', if it should be allowed to read roles from this user store. When this property is 'true', you must also specify values for theGroupSearchBase
,GroupSearchFilter
andGroupNameAttribute
properties. If theReadGroups
property is set to 'false', only Users can be read from the user store. You can set the configuration to read roles from the user store by reading the user/role mapping based on a membership (user list) or backlink attribute as shown below.
To read the user/role mapping based on a membership (This is used by theApacheDirectory
server andOpenLDAP)
:Enable the
ReadGroups
property.<Property name="ReadGroups">true</Property>
Set the
GroupSearchBase
property to the directory name where the Roles are stored. That is, the roles you create using the management console of your product will be stored in this directory location. Also, when LDAP searches for users, it will start from this location of the directory. For example:<Property name="GroupSearchBase">ou=system,CN=Users,DC=wso2,DC=test</Property>
Set the GroupSearchFilter and GroupNameAttributes. For example:
<Property name="GroupSearchFilter">(objectClass=groupOfNames)</Property> <Property name="GroupNameAttribute">cn</Property>
Set the
MembershipAttribute
property as shown below:<Property name="MembershipAttribute">member</Property>
To read roles based on a backlink attribute, use the following code snipet instead of the above:
<Property name="ReadGroups">false</Property> <Property name="GroupSearchBase">ou=system</Property> <Property name="GroupSearchFilter">(objectClass=groupOfNames)</Property> <Property name="GroupNameAttribute">cn</Property> <Property name="MembershipAttribute">member</Property> <Property name="BackLinksEnabled">true</Property> <Property name="MembershipOfAttribute">memberOf</Property>
For Active Directory, you can use
<Property name="Referral">follow</Property>
to enable referrals within the user store. The AD user store may be partitioned into multiple domains. However, according to the use store configurations in theuser-mgt.xml
file, we are only connecting to one of the domains. Therefore, when a request for an object is received to the user store, the<Property name="Referral">follow</Property>
property ensures that all the domains in the directory will be searched to locate the requested object.
Step 2: Updating the system administrator
The admin user is the super tenant that will be able to manage all other users, roles and permissions in the system by using the management console of the product. The <Configuration>
section in the user-mgt.xml
file contains the super admin information. Update this configuration for the read-only LDAP/AD as explained below.
<Configuration> <AddAdmin>False</AddAdmin> <AdminRole>admin</AdminRole> <AdminUser> <UserName>AdminSOA</UserName> <Password>XXXXXX</Password> </AdminUser> ............ </Configuration>
- <AddAdmin>: This should be set to 'False' as it will not be allowed to create users and roles in a read-only user store.
- <AdminRole>: The admin role you enter here should already exist in the read-only user store. Otherwise, you must enter an internal role, which will be saved to the internal database of the system when the system starts the first time.
- <AdminUser>: Since we are configuring a read-only LDAP as the primary user store, the user that should have admin permissions is required to be stored in the user store when you start the system for the first time. For example, say a valid username is AdminSOA. Update the
<AdminUser>
section of your configuration as shown above. You do not have to update the password element as it is already set in the user store.
See the related documentation for more information about the system administrator.
Step 3: Starting the server
Start your server and try to log in as the admin user you specified. The password is the admin user's password in the LDAP server.
Related Topics
More Inofrmation
- Configuring the System Administrator: This section provides information about the system administrator user. For more information, see the following sections in the WSO2 Identity Server (WSO2 IS) documentation.
- Properties of User Stores: This topic describes each of the properties used in the
user-mgt.xml
file for configuring the primary user store.
Read/write mode
Before you begin
- To read and write to an Active Directory user store, set the
WriteGroups
property totrue
instead offalse
. To write user entries to an LDAP user store (roles are not written, just user entries), you follow the steps in the Read-only mode section but specify the following class instead:
<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager">
Use the following class for Active Directory.
<UserStoreManager class="org.wso2.carbon.user.core.ldap.ActiveDirectoryUserStoreManager">
The <PRODUCT_HOME>/repository/conf/user-mgt.xml
file has commented-out configurations for external LDAP/AD user stores.
- Enable the
<ReadWriteLDAPUserStoreManager>
or the<ActiveDirectoryUserStoreManager>
in the<PRODUCT_HOME>/repository/conf/user-mgt.xml
file by uncommenting the code. When it is enabled, the user manager reads/writes into the LDAP/AD user store. Note that these configurations already exist in theuser-mgt.xml
file so you only need to uncomment them and make the appropriate adjustments. Also ensure that you comment out the configurations for other user stores which you are not using. The default configuration for the external read/write user store in the
user-mgt.xml
file is as follows. Change the values according to your requirements.When working with Active Directory it is best to enable the
GetAllRolesOfUserEnabled
property in theAuthorizationManager
as follows.<AuthorizationManager class="org.wso2.carbon.user.core.authorization.JDBCAuthorizationManager"> <Property name="AdminRoleManagementPermissions">/permission</Property> <Property name="AuthorizationCacheEnabled">true</Property> <Property name="GetAllRolesOfUserEnabled">true</Property> </AuthorizationManager>
While using the user store manager does not depend on this property, you must consider enabling this if there are any performance issues in your production environment. Enabling this property affects the performance when the user logs in. This depends on the users, roles and permissions stats.
If you create the
user-mgt.xml
file yourself, be sure to save it in the<PRODUCT_HOME>/repository/conf
directory.The
class
attribute of theUserStoreManager
element indicates whether it is an Active Directory or LDAP user store:- Active Directory:
<UserStoreManager class="org.wso2.carbon.user.core.ldap.ActiveDirectoryUserStoreManager">
- Read-only LDAP:
<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager">
- Active Directory:
Set the attribute to use as the username, typically either cn or uid for LDAP. Ideally,
<Property name="UserNameAttribute">
and<Property name="UserNameSearchFilter">
should refer to the same attribute. If you are not sure what attribute is available in your user store, check with your LDAP/Active Directory administrator.For example:
The following code snippet represents reading roles based on a backlink attribute. This is used by the Active Directory.
<Property name="ReadLDAPGroups">true</Property> <Property name="GroupSearchBase">cn=users,dc=wso2,dc=lk</Property> <Property name="GroupSearchFilter">(objectcategory=group)</Property> <Property name="GroupNameAttribute">cn</Property> <Property name="MemberOfAttribute">memberOf</Property>
Start your server and try to log in as the admin user you specified. The password is the admin user's password in the LDAP server.
Configuring an internal/external JDBC user store
The default internal JDBC user store reads/writes into the internal database of the Carbon server. JDBC user stores can be configured using the <PRODUCT_HOME>/repository/conf/user-mgt.xml
file's JDBCUserStoreManager
configuration section. Additionally, all Carbon-based products can work with an external RDBMS. You can configure Carbon to read users/roles from your company RDBMS and even write to it. Therefore, in this scenario, the user core connects to two databases:
- The Carbon database where authorization information is stored internally.
- Your company database where users/roles reside.
Therefore, the user-mgt.xml
file must contain details for two database connections. The connection details mentioned earlier are used by the authorization manager. If we specify another set of database connection details inside the UserStoreManager, it reads/writes users to that database. The following are step-by-step guidelines for connecting to an internal and external JDBC user store in read-only mode:
Uncomment the following section in
<PRODUCT_HOME>/repository/conf/user-mgmt.xml
:<UserStoreManager class="org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager">
The following are samples for the internal and external JDBC user store configuration:
The sample for the external JDBC user store consists of properties pertaining to various SQL statements. This is because the schema may be different for an external user store, and these adjustments need to be made in order to streamline the configurations with WSO2 products.
You can define a data source in
<PRODUCT_HOME>/repository/conf/datasources/master-datasources.xml
and refer to it from theuser-mgt.xml
file. This takes the properties defined in themaster-datasources.xml
file and reuses them in theuser-mgt.xml
file. To do this, you need to define the following property:
<
Property
name
=
"dataSource"
>jdbc/WSO2CarbonDB</
Property
>
Find a valid user that resides in the RDBMS. For example, say a valid username is AdminSOA. Update the Admin user section of your configuration as follows. You do not have to update the password element; leave it as is.
<AdminUser> <UserName>AdminSOA</UserName> <Password>XXXXXX</Password> </AdminUser>
Add the
passwordHashMethod
property to the UserStoreManager configuration forJDBCUserStoreManager
. For example:<UserStoreManager class="org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager"> <Property name="passwordHashMethod">SHA</Property> ... </UserStoreManager>
The
passwordHashMethod
property specifies how the password should be stored. It usually has the following values:SHA
- Uses SHA digest method.MD5
- Uses MD 5 digest method.PLAIN_TEXT
- Plain text passwords.
In addition, it also supports all digest methods in http://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest.html.
- Update the connection details found within the
<UserStoreManager>
class based on your preferences. In the realm configuration section, set the value of the
MultiTenantRealmConfigBuilder
property toorg.wso2.carbon.user.core.config.multitenancy.SimpleRealmConfigBuilder
. For example:
<Property name="MultiTenantRealmConfigBuilder">org.wso2.carbon.user.core.config.multitenancy.SimpleRealmConfigBuilder</Property>
- Add the JDBC driver to the classpath by copying its JAR file into the
<PRODUCT_HOME>/repository/components/lib
directory. - Edit the SQLs in the
user-mgt.xml
file according to your requirements, and then start the server.
Related Links
Working with Properties of Primary User Stores - For a comprehensive understanding on the configuration details.