CustomerID self-service role request example

Configuration options

For allowing end-users to request additional access rights based on roles, following configuration parameters must be specified in the eidm2.properties file:

ParameterUsageDefault
selfservice.rolerequest.rolelistSpecify list of roles that can (listtype=whitelist) or cannot (listtype=blacklist) be ordered.not set
selfservice.rolerequest.listtypewhitelist/blacklistblacklist
selfservice.rolerequest.homeorganization.onlyAllow requesting roles from user's home organization only.true

To be able to request roles from other than their home organization, users must have following permissions to the organization(s) of the roles to be requested. These permissions are defined in the file permissions.properties.

PermissionUsage
organization.readOrganization read permission
role.assignRole assignment permission

If the end-users have access to the CustomerID administration user interface, the above mentioned permissions should be given through roles that give the permissions only to the organizations where the roles are located. Otherwise users may get visibility to unwanted organizations. In this configuration example, we use a role RoleRequester for this purpose.

Example data model

In our example we have customers and services in separate organization branches, and we have defined some example services with roles Member, Owner and Visitor (technical names member, owner and visitor).

    


We would like to allow all users to request the Member and Visitor roles at CustomerID self-service, but they should only see their own customer organization at the administration user interface.

Example configuration

We use role hierarchy rules to automatically assign the role services/RoleRequester to all users. The roles assigned by role hierarchy rules are not visible in the self-service or admin UI.  

eidm2.properties
# Organization types
organization.type.name.1 = customer
organization.type.company.1 = OrganizationMainUser
organization.type.company.2 = OrganizationUser

organization.type.name.2 = service
organization.type.site.1 = owner
organization.type.site.2 = member
organization.type.site.3 = visitor


# Self-service role request
selfservice.rolerequest.homeorganization.only = false
selfservice.rolerequest.rolelist = member, visitor
selfservice.rolerequest.listtype = whitelist

# Role hierarchy rules
role.hierarchy.1.source.role = OrganizationUser
role.hierarchy.1.target.role = RoleRequester
role.hierarchy.1.target.organization = services

role.hierarchy.2.source.role = OrganizationMainUser
role.hierarchy.2.target.role = RoleRequester
role.hierarchy.2.target.organization = services


permissions.properties
# Organization read permission
# - This permission defines those users who are allowed to read organization information in the
#   admin service.
# - You may also define field specific read permissions by adding the field name after
#   organization.read.
# - Field specific permissions override the general permission.
organization.read = inh:OrganizationMainUser, inh:RoleRequester


# 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:RoleRequester


The RoleRequester role has been added to the root organization of the services branch manually at the admin UI.

Testing

Now the end-users can request the service roles:

    


Users can only see their own organization in the admin UI:

   Â