Table 1 shows examples
of role assignments, in chronological order.
Table 1. Users and their roles
| User ID |
OU |
Role |
Role assigned to user ID by... |
| Peter |
SYSOU |
DniUA |
Installation default ID, UA1 |
| Jane |
SYSOU |
DniUA |
Installation default ID, UA1 |
| Alex |
SYSOU |
Approver |
Peter |
| Jane |
BANKA |
DniUA |
Peter |
| Michael |
BANKA |
DniUA |
Jane |
| Alex |
BANKA |
Approver |
Michael |
| Sally |
BANKB |
DniUA |
Peter |
| Alex |
BANKB |
Approver |
Sally |
| Helen |
BANKB |
Assigner |
Sally |
| Alex |
BANKB |
Committer |
Helen |
In
Table 1:
- UA1 is one of the default IDs that is generated during the installation
of FTM SWIFT.
It was assigned the system-generated security administrator role (DniUA-SYSOU).
- UA1 assigns Peter and Jane the system-generated security administrator
role (DniUA-SYSOU). They can now create other DniUAs in specific OUs.
They can also assign roles to users in the OU SYSOU.
- Peter has the security administrator role in the OU SYSOU. He
assigns Alex the Approver role in the OU SYSOU. Peter also can assign
Jane another role. She now has the security administrator role in
the OU BANKA, too.
- Jane can now assign roles to users within the OU BANKA as well
as the OU SYSOU, because she has the security administrator role in
the OUs SYSOU and BANKA.
- Jane has the security administrator role in two OUs, SYSOU and
BANKA. She can list all users in those two OUs. However, she must
change to each OU to see its users when she uses the list command.
- Alex was assigned several roles. He has the Approver role in all
three OUs. Alex also has the Committer role in the OU BANKB. He can
approve entities in the OUs SYSOU, BANKA, and BANKB. However, he can
only commit entities in the OU BANKB.
- There is no user who can list all users in all three OUs.
You can also add COs of the security administration tasks to
other roles and assign these roles for any OU to users. These users
can then perform the appropriate security administration tasks in
the assigned OU.