Configuring Primary User Stores

Every WSO2 Carbon-based product comes with an embedded user store available for use which is known as an internal user store. However, if you have a user store which is already running, you may prefer to use your own user store instead of the embedded user store. This brings about the need to connect to external user stores. The user store you wish to connect to has different schemas to the ones available in WSO2, hence this needs to go through an adaptation process.

WSO2 products enable you to authenticate users from different types of user stores and currently have the capability to easily plug-in to LDAP, Active Directory and JDBC to perform authentication.

You can find many user store managers in the user-mgt.xml file.

Use the ReadOnlyLDAPUserStoreManager to do read-only operations for external LDAP user stores.
To do both read and write operations, use the ReadWriteLDAPUserStoreManager for external LDAP user stores.
If you wish to use an Active Directory Domain Service (AD DS) or Active Directory Lightweight Directory Service (AD LDS), use the ActiveDirectoryUserStoreManager. This can be used for both read-only and read/write operations.
Use JDBCUserStoreManager for both internal and external JDBC user stores.

The following topics provide details on the various primary user stores you can configure.

Configuring an external LDAP user store/active directory

All WSO2 Carbon-based products can read and write users and roles from external Active Directory/LDAP user stores. You can configure Carbon products to access the Active Directory/LDAP user stores using one of the following modes.

Read-only mode

You can configure Carbon products to read users/roles from your company LDAP. The "Read Only" mode does not write any data into the LDAP.

Access the user-mgt.xml file found in the <PRODUCT_HOME>/repository/conf/ directory.

The following are samples for the LDAP user store and Active Directory:

Note that the following tags in your file indicate whether it is an Active Directory or LDAP:

Active Directory - <UserStoreManager class="org.wso2.carbon.user.core.ldap.ActiveDirectoryUserStoreManager">
LDAP - <UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager">

If you wish to create this file yourself, ensure that the user-mgt.xml file you create is saved in <PRODUCT_HOME>/repository/conf/user-mgt.xml.
Find a valid user that resides in the Directory Server. For example, if the valid username is "AdminSOA", update the Admin user section of your LDAP configuration as follows. You do not have to update the password element; leave it as it is.
```
<AdminRole>wso2admin</AdminRole>
<AdminUser>
   <UserName>AdminSOA</UserName>
   <Password>XXXXXX</Password>
</AdminUser>
```
- <AdminRole>wso2admin</AdminRole>
  This is the role that has all administrative privileges of the WSO2 product, i.e., all users having this role are admins of the WSO2 product. You can provide any meaningful name for this role and it is created in the internal H2 database when the product starts up.
- <AdminUser>
  Here we configure the default administrator for the WSO2 product. If the user store is read-only, then this role is added to the system as a special internal role where users are from an external user store.
- <UserName>
  This is the username of the default administrator. This user MUST exist in the external LDAP. If the user store is read-only, the admin user must exist in the user store for the process to work.
- <Password>
  Do NOT put the password there. Just leave it empty or place some stars (*) there. If the user store is read-only, this element and its value are ignored.
Update the connection details to suit your Directory Server. For example:
```
<Property name="ConnectionURL">ldap://localhost:10389</Property>
```
Obtain a user who has permission to read all users/attributes and perform searches on the Directory Server from your LDAP administrator. For example, if the privileged user is "AdminLDAP" and the password is "2010#Avrudu", update the following sections of the realm configuration as follows:
```
<Property name="ConnectionName">uid=AdminLDAP,ou=system</Property>
<Property name="ConnectionPassword">2010#Avrudu</Property>
```
Also update the <Property name="UserSearchBase"> by providing 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 that you wish to use as the username. The most common case is to use either cn or uid as the username. If you are not sure what attribute is available in your LDAP, check with your LDAP administrator.
```
<Property name="UserNameAttribute">uid</Property>
```
For Active Directory this will differ as follows:
```
<Property name="UserNameAttribute">sAMAccountName</Property>
```
The above steps address the most basic form of configuration. For more advanced options like "external roles", jump to step 7. Otherwise you are done. Start your server and try to log in as "AdminSOA". The password is the AdminSOA's password in the LDAP server.

The realm can read roles from the Directory Server. It can read user/role mapping based on a backlink attribute or membership (user list) attribute.

The following code snippet represents reading roles based on a membership attribute. This is used by the ApacheDirectory server and OpenLDAP.

<Property name="ReadLDAPGroups">false</Property>
<Property name="GroupSearchBase">ou=system</Property>
<Property name="GroupSearchFilter">(objectClass=groupOfNames)</Property>
<Property name="GroupNameAttribute">cn</Property>
<Property name="MembershipAttribute">member</Property>

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>

See here for a detailed description of each property in order to gain a more comprehensive understanding of the configuration details.

Read/write mode

If you wish to connect to an external LDAP user store, such that only the user entries are written to the external LDAP and roles are not written to the external LDAP, the only difference from the steps in section Read-only mode is the following:

<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager">

The <PRODUCT_HOME>/repository/conf/user-mgt.xml file has commented out configuration for external LDAP user stores.

Enable the <ReadWriteLDAPUserStoreManager> element in the user-mgt.xml file by uncommenting the code. When it is enabled, the user manager reads/writes into the LDAP user store.
The default configuration for the external read/write LDAP user store in the user-mgt.xml file is as follows. Change the values according to your requirements. See here for a detailed description of each property in order to gain a more comprehensive understanding of the configuration details.

For active directory configurations, the WriteGroups property is set to true for read/write mode and false for read-only mode.

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. In addition to this, all Carbon-based products can work with external RDBMSs. 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.

So 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:

A sample file for the JDBC user store (user-mgt.xml) is available in the <PRODUCT_HOME>/repository/conf directory. Uncomment the following section in your file if it is commented out:
```
<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 repository/conf/datasources/master-datasources.xml and refer to it from the user-mgt.xml file. This takes the properties defined in the master-datasources.xml file and reuses it in the user-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 LDAP configuration as follows. You do not have to update the password element; leave it as it is.
```
<AdminUser>
   <UserName>AdminSOA</UserName>
   <Password>XXXXXX</Password>
</AdminUser>
```
In the user-mgt.xml file, add the passwordHashMethod property within the JDBCUserStoreManager. 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, and 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. See here for a detailed description of each property in order to gain a more comprehensive understanding of the configuration details.
In the user-mgt.xml file, under the realm configuration, set the value of the MultiTenantRealmConfigBuilder property to org.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 dropping the JAR into the <PRODUCT_HOME>/repository/components/lib directory.
Edit the SQLs in the user-mgt.xml file according to your requirements, and start the server.