In order to adapt identities to the particularities and requirements of each user repository, the following groupings are available:
In order to use different password policies we will use different user types. As an example, internal users (automatically created) are different from external ones. For instance, the policy for external users can be less restrictive because this kind of users have less risk.
A user domain defines how account names will be created based on user name and its related attributes. For example, a user named jsmith can be identified as jsmith on Soffid and on the ActiveDirectory, john.smith on Lotus Notes and email@example.com on the mail server.
For each password policy a domain password must be created. For instance, if AD requires at least 8 characters and AS400 no more than 7 we need to create different password policies for these two systems.
For each password domain it is possible to create different password policies depending on the different user types.
The following picture shows the password policy hierarchy.
For a correct configuration, please start defining the required “user types”. Afterwards, add as many user domains as user identifiers are being used. For each domain user, please specify a code, description and user domain type.
For “main user name” domains, the account name will be the same as the user name.
For “scripted” user names, a bash script based on the user information can be specified.
For “spring” domains, a specific, more complex, Spring service can be developed.
Please continue by defining password domains, and one password policy for each suitable policy and user type. A password policy has the following fields:
Identifies a person, that is related in some way with the company, this could be either an employee, customer, provider or stakeholder.
Is the name by which a user is known at a specific managed system. There may be some shared accounts that are used by more than one user.
An application system identifies an immaterial asset that needs to be protected. Each account can have zero or more roles granted for each application system.
Each group refers to an organisational unit, department or workgroup. Each group can have different roles from the different applications that they are applied to, so there would be no need to assign roles to individual users.
Identifies a specific access level to an application system. A role is also system specific, but you can define more than one role with the same name as long as they live in different managed systems.
The following picture shows a typical separation of duties in role assignment. The correct application of groups enables separation of different areas. For instance, a human resources officer would assign users to groups in order to be able to carry out his functions. Then, the application manager would assign the application roles suitable for each group in order to carry out their job functions.