Two layers now: IAM / Zen decides who may enter the platform and with which platform role; BAW keeps deciding what the user may do inside workflow (teams, tw_admins, tw_authors). The new step is the first one:
- Identity source: LDAP is configured once in the CR (ldap_configuration) or an OIDC / SAML identity provider is registered in IAM. Users are still LDAP users.
- Onboarding to Zen: a user (or better an LDAP group) must be added in the Cloud Pak dashboard > Access control with a role that includes the capabilities: Automation Developer (Studio), Automation Administrator, Automation Analyst, or a custom role with "Workflow" permissions. Without it the login succeeds but the capability tiles and Workplace are refused. Add LDAP groups rather than users - membership is then evaluated at login.
- BAW rights as before: teams in the process apps map to LDAP groups (through the team's group binding), administration through the tw_admins mapping (CR field for the admin group / user), authoring through tw_authors. Process Admin console works on containers for team bindings and user attributes; user synchronisation with the Operations REST (POST /ops/system/users_sync).
# CR excerpt: LDAP and the workflow administrator
spec:
ldap_configuration:
lc_selected_ldap_type: "IBM Security Directory Server" # or Microsoft Active Directory
lc_ldap_server: ldap.example.com
lc_ldap_base_dn: dc=example,dc=com
lc_ldap_user_name_attribute: "*:uid"
lc_ldap_group_member_id_map: "groupofnames:member"
baw_configuration:
- name: bawins1
admin_user: bawadmin # becomes tw_adminsDifferences that trip people: user ids are case-sensitive in Zen; the filter for users / groups in the CR limits who is visible to the whole Cloud Pak; nested groups need the right member map; and on Workflow Process Service (SaaS) there is no LDAP - users are invited by e-mail through the tenant's user management.
References