Configuring a Read-Write LDAP User Store
The default User Store
The internal H2 database is configured as the default primary user store. This internal database is used by the Authorization Manager (for user authentication information) as well as the User Store Manager (for defining users and roles).
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-write LDAP as the primary user store:
Step 1: Setting up the read-write LDAP user store manager
Before you begin
- If you create the
user-mgt.xml
file yourself, be sure to save it in the/conf
directory. - The
class
attribute for a read-write LDAP is<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager">
Once the above points are made note of and completed, you can start configuring your external read-write LDAP as the primary user store.
Enable the
<ReadWriteLDAPUserStoreManager>
user store manager class in theuser-mgt.xml
file by uncommenting the relevant code. When it is enabled, the user manager reads/writes into the LDAP user store.Note that these configurations already exist in the
user-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 that you are not using; in short, you can only configure one primary user store.The default configuration for the external read/write user store in the
user-mgt.xml
file is as follows. You may have to change some of these values according to your requirements. For more information about each of the properties used in theuser-mgt.xml
file for configuring the primary user store, see Properties of User Stores.<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager"> <Property name="TenantManager">org.wso2.carbon.user.core.tenant.CommonHybridLDAPTenantManager</Property> <Property name="ConnectionURL">ldap://localhost:${Ports.EmbeddedLDAP.LDAPServerPort}</Property> <Property name="ConnectionName">uid=admin,ou=system</Property> <Property name="ConnectionPassword">admin</Property> <Property name="PasswordHashMethod">SHA</Property> <Property name="UserNameListFilter">(objectClass=person)</Property> <Property name="UserEntryObjectClass">wso2Person</Property> <Property name="UserSearchBase">ou=Users,dc=wso2,dc=org</Property> <Property name="UserNameSearchFilter">(&(objectClass=person)(uid=?))</Property> <Property name="UserNameAttribute">uid</Property> <Property name="PasswordJavaScriptRegEx">[\\S]{5,30}</Property> <Property name="UsernameJavaScriptRegEx">[\\S]{3,30}</Property> <Property name="UsernameJavaRegEx">[a-zA-Z0-9._\-|/]{3,30}$</Property> <Property name="RolenameJavaScriptRegEx">[\\S]{3,30}</Property> <Property name="RolenameJavaRegEx">[a-zA-Z0-9._\-|/]{3,30}$</Property> <Property name="ReadGroups">true</Property> <Property name="WriteGroups">true</Property> <Property name="EmptyRolesAllowed">true</Property> <Property name="GroupSearchBase">ou=Groups,dc=wso2,dc=org</Property> <Property name="GroupNameListFilter">(objectClass=groupOfNames)</Property> <Property name="GroupEntryObjectClass">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="SharedGroupEntryObjectClass">groups</Property> <Property name="SharedTenantNameListFilter">(object=organizationalUnit)</Property> <Property name="SharedTenantNameAttribute">ou</Property> <Property name="SharedTenantObjectClass">organizationalUnit</Property> <Property name="MembershipAttribute">member</Property> <Property name="LDAPConnectionTimeout">5000</Property> <Property name="UserRolesCacheEnabled">true</Property> <Property name="UserDNPattern">uid={0},ou=Users,dc=wso2,dc=org</Property> </UserStoreManager>
To read and write to an LDAPuserstore, it is important to ensure that the
ReadGroups
andWriteGroups
properties in the/conf/user-mgt.xml
file are set totrue
.<Property name="ReadGroups">true</Property> <Property name="WriteGroups">true</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 administrator.<Property name="UserNameAttribute">uid</Property>
If you are using
ldaps
(secured LDAP) to connect to the LDAP:You need set the
ConnectionURL
as shown below.<Property name="ConnectionURL">ldaps://10.100.1.100:636</Property>
You also need to enable connection pooling for LDAPS connections at the time of starting your server, which will enhance server performance.
Specify the following properties that are relevant to connecting to the LDAP in order to perform various tasks.
<Property name="ConnectionURL">ldap://localhost:${Ports.EmbeddedLDAP.LDAPServerPort}</Property> <Property name="ConnectionName">uid=admin,ou=system</Property> <Property name="ConnectionPassword">admin</Property>
In WSO2 products based on Carbon 4.4.x, you can set the
LDAPConnectionTimeout
property: If the connection to the LDAP is inactive for the length of time (in milliseconds) specified by this property, the connection will be terminated.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 EI profile will be stored in this directory location. Also, when LDAP searches for groups, 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 andGroupNameAttributes. 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 snippet 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>
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 EI profile. Therefore, 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. Since the LDAP user store can be written to, you have the option of creating a new admin user in the user store when you start the system for the first time. Alternatively, you can also use a user ID that already exists in the LDAP. For information about the system administrator user, see Configuring the System Administrator.
These two alternative configurations can be done as explained below.
If the user store is read-only, find a valid user that already resides in the user store. For example, say a valid username is AdminSOA. Update the
<AdminUser>
section of your configuration as shown below. You do not have to update the password element as it is already set in the user store.<AddAdmin>False</AddAdmin> <AdminRole>admin</AdminRole> <AdminUser> <UserName>AdminSOA</UserName> <Password>XXXXXX</Password> </AdminUser>
If the user store can be written to, you can add the super tenant user to the user store. Therefore,
<AddAdmin>
should be set to true as shown below.<AddAdmin>true</AddAdmin> <AdminRole>admin</AdminRole> <AdminUser> <UserName>admin</UserName> <Password>admin</Password> </AdminUser>
Step 3: Starting the server
Start your server and try to log in as the admin user you specified in Step 2.