Lab 2.1: CustomerID permission configuration
The purpose of this module is to show you how to configure what users can and cannot do with the user interface of CustomerID user interface. Permissions are based on user roles.
Role-based permission for access to functions
Let's see how permissions work.
By default, users that are not CustomerID administrators and have very limited access on what they can see (e.g. tabs, menus) and do (e.g. search, create mandates) in the system.
- Cannot modify organisation data (organization.edit)
- Cannot create new roles in an organisation (role.create)
- Cannot create new organisations (organization.create)
- Cannot issue or remove mandates (mandate.create, mandate.remove)
- Cannot issue or remove mandates (mandate.create, mandate.remove)
As you might remember, on Lab 1.6 we already edited some permissions. We granted the following permissions to Contact Person (Jeremy Mills):
- Granted users in the Contact Person role (technical name: mainuser) to have access privileges to administrator interface.
- Gave users in the Contact Person role (technical name: mainuser) a series of permissions in order to use mandates.
A complete example of all possible permissions can be found in the "C:\Program Files\Ubisecure\customerid\tools\examples\custom\permissions.properties" file.
Open this file and examine the format. The file also contains documentation for each of the permissions. Various permissions can be granular down to the field level.
Instructions
Permission Configuration
- Log in as Jeremy Mills to Ubisecure CustomerID Administration Interface
- Try to search for an organisation or a user.
- Verify that Jeremy has read access only to City Group organisation and users.
Permissions to manage roles
- Jeremy Mills needs more permissions to manage the organisation.
Edit the permissions configuration file (permissions.properties) in "C:\Program Files\Ubisecure\customerid\application\custom\permissions.properties" and add some more rights to manage roles:
# ************************************************************************************************* # ********** User Permissions                                                          ********** # ************************************************************************************************* # User listing permission # - This permission defines those users who are allowed to list organization's users in the admin #  service. user.list = inh:OrganizationMainUser, inh:Superuser, inh:owner, inh:mainuser # User personal information read permission # - This permission defines those users who are allowed to read the personal information concerning #  organization users in the admin service. # - You may also define field specific read permissions by adding the field name after #  user.read.personal. # - Field specific permissions override the general permission. user.read.personal = inh:OrganizationMainUser, any:Superuser, any:owner, any:mainuser # ************************************************************************************************* # ********** Role Permissions ********** # ************************************************************************************************* # Role read permission # - This permission defines those users who are allowed to list organization roles in the # admin service. role.read = inh:OrganizationMainUser, inh:mainuser # Role assignment permission # - This permission defines those users who are allowed to assign roles to users in the admin # service. role.assign = inh:OrganizationMainUser, inh:mainuser # Role invitation permission # - This permission defines those users who are allowed to invite users to roles in the admin # service. role.invite = inh:OrganizationMainUser, inh:mainuser # Role deassignment permission # - This permission defines those users who are allowed to deassign roles from users in the admin # service. role.deassign = inh:OrganizationMainUser, inh:mainuser # List role approvals # - This permission defines those users who are allowed to view role approvals in the admin service. role.list_approvals = inh:OrganizationMainUser, inh:mainuser # Role approval permission # - This permission defines those users who are allowed to approve role assignments in the admin # service. role.approve = inh:OrganizationMainUser, inh:mainuser # Role deletion permission # - This permission defines those users who are allowed to delete roles in the admin service. role.delete = inh:OrganizationMainUser, inh:mainuser # Role list users permission # - This permission defines those users who are allowed to list users in selected role. role.listusers = inh:OrganizationMainUser, inh:mainuser
- Restart Wildfly.
- He should now see the Users and Roles tabs:
Let's look at the default permissions.properties file where all possible permissions are, but DON'T add these lines to your configuration file. If you do it, you will lose the permissions you have added in labs 1.6 and 2.2.
Optional exercise
Hide a button so nobody can delete a user. Hint: login as Scott Long and verify you can't delete users.