Two layers are involved: WebSphere decides who the user is (registry), BPM decides what the user may do (groups / teams). To give one user narrow rights:
- Create the user in the registry - Process Admin console > User Management > Add user (internal file registry; fine for tests) or in the LDAP / WebSphere federated repository for real environments (AdminTask.createUser in wsadmin).
- Give BPM-level rights through groups: tw_authors (design in Process Designer), tw_admins (Process Admin, everything), tw_portal_admins, tw_allusers (everyone, automatic). A "normal" user is a member of nothing but tw_allusers.
- Application rights through teams: in Process Designer, the process app's Teams (participant groups) define who sees tasks and who may start the app's exposed items - add the user (or better, an LDAP group) to the right team; the Exposed to setting of each BPD / service / dashboard names the team.
- Restrict repository rights: Process Center > process app > Manage > Administration: give read / write / admin on that app only to the user; a user with no rights on an app does not see it in the designer.
# wsadmin: add the user to the BPM "authors" group (WebSphere group mapped to tw_authors) - or use Process Admin > Group Management
AdminTask.addMemberToGroup('[-memberUniqueName uid=jdoe,o=defaultWIMFileBasedRealm -groupUniqueName cn=bpmauthors,o=defaultWIMFileBasedRealm]')
AdminConfig.save()Do not give the user a WebSphere administrative role (Console users) unless they must administer WebSphere - BPM permissions never require it. Process Portal shows only what the teams allow, so "permissions only for that user" is achieved by teams with one member.
References