The user management functionality feature allows you to configure the users that can access your product, and the permissions that determine how each user can work with your system.
The default user management configuration is as follows:
- The default H2 database is configured as the User Store that stores all the information on users, roles and permissions.
- An Admin user and Admin password are configured by default.
- The default Admin role connected to the Admin user has all permissions granted.
According to the default configuration explained above, you can simply log into the Management Console of the WSO2 Open Banking identity and access management component with the Admin user, and get started right away.
Follow the sections given below to understand how user management works, and for step-by-step instructions on how to change/update the default configuration:
Users, Roles, and Permissions
User management involves defining and managing users, roles, and their access levels in a system. A user management dashboard or console provides system administrators with a high-level view of a system's active user sessions, their login statuses, the privileges of each user, and their activity in the system. It enables system admins to make business-critical, real-time security decisions. A typical user management implementation involves a wide range of functionality such as adding/deleting users, controlling user activity through permissions, managing user roles, defining authentication policies, managing external user stores and manual/automatic logout, and resetting passwords.
Any user management system has the following basic components:
- Users: Users are consumers who interact with your organizational applications, databases, and other systems. A user can be a person, a device, or another application/program within or outside of the organization's network. Because users interact with internal systems and access data, organizations need to define which data and functionality each user can access by assigning permissions.
- Permissions: A permission is a delegation of authority or a right that is assigned to a user or a group of users to perform an action on a system. Permissions can be granted to or revoked from a user, user group, or user role automatically or by a system administrator. For example, if a user has the permission to log in to a system, the permission to log out is automatically granted as well.
- User roles: A user role is a grouping of permissions. In addition to assigning individual permissions to users, admins can create user roles and assign those roles to users. For example, you might create user roles called VP, Manager, and Employee, each of which has a different set of permissions, and then assign those roles to users based on their position in the company. Then, if you need to modify the permissions of all your managers, you can simply modify the Manager user role, and all the users with that role will have their permissions updated automatically.
...
RDBMS (for Authentication and Authorisation): This RDBMS stores information about the role-based permissions.
| Info |
|---|
According to the default configuration in WSO2 products, the embedded H2 RDBMS that is shipped with the product is used as the user store, as well as the RDBMS, for storing information related to permissions. |
Realm configuration: The user realm consists of the configurations required to initialise the user realm. The user-mgt.xml file stored in the <PRODUCT_HOME>/repository/conf/ directory is used as the realm configuration XML. This includes setting up the User Store Manager, the Authorization Manager and the System Administrator. These configurations are explained below.
...
The User Store Manager is responsible for managing the underlying user store. It is represented by the UserStoreManager Java interface. There can be different User Store Manager implementations to connect with different user stores, but you can configure only one User Store Manager implementation in a single user realm (that is, a single WSO2 Carbon instance). The User Store Manager can be operated in both read/write mode and read-only mode. In read-only mode, you can only connect with an existing user store. WSO2 products provide the following default User Store Manager implementations:
JDBCUserStoreManager(read and write)LDAPUserStoreManager(read-only)ApacheDSUserStoreManager(read and write)
You can write a custom user store manager implementation by implementing UserStoreManager or by extending AbstractUserStoreManager or one of the default implementations.
Using JDBCUserStoreManager
The JDBCUserStoreManager class uses a schema that is specific to WSO2 Carbon. It contains the following tables:
- UM_USER: Contains user names and passwords
- UM_ROLE: Contains role names
- UM_USER_ROLE: Contains user role mappings
- UM_USER_ATTRIBUTE: Contains user attributes. There can be any attribute ID and a value for that attribute ID that is associated with a user’s profile.
You can find the full schema of these tables from the database script files in the <PRODUCT_HOME>/dbscripts directory. Note that these scripts also contain schemas for other tables that are used for user management and registry functions. If your organization contains an existing JDBC user store that you want to use with a WSO2 product, you must extend JDBCUserStoreManager and write a new implementation for your user store according to your schema.
...
For information on how you can set up and configure the user management realm, see Configuring the User Realm. create new users and define the permissions granted to each user. You can also configure the user stores that are used for storing data related to user management.
For detailed information on working with user management, see the following sections in the WSO2 Administration Guide:
| Section | Description |
|---|---|
| Configuring the System Administrator | The admin user is the super tenant who is able to manage all other users, roles, and permissions in the system by using the management console of the product. Therefore, the user that has admin permissions has to be stored in the primary user store when you start the system for the first time. The documentation on setting up primary user stores explains how to configure the administrator while configuring the user store. The information under this topic explains the main configurations that are relevant to setting up the system administrator. |
| Configuring the Authorization Manager | According to the default configuration in WSO2 products, the users, roles and permissions are stored in the same repository (i.e., the default, embedded H2 database). However, you can change this configuration in such a way that the users and roles are stored in one repository (user store) and the permissions are stored in a separate repository. A user store can be a typical RDBMS, a LDAP, or an external Active Directory. The repository that stores permissions should always be a RDBMS. The Authorization Manager configuration in the |
| Configuring User Stores | The user management feature allows you to maintain multiple user stores for storing users and their roles. See the following topics for instructions: |
| Managing Users, Roles and Permissions | The user management functionality is provided by default, and it supports the role-based authentication model where privileges of a user are based on the role attached. For more information on managing users, roles, and permissions see the following sections in the WSO2 Administration Guide. |