In the Dynamo User Directory, users may belong to organizations, and organizations may belong to parent organizations. For example, you could have an organization that represents your company and children organizations that represent the various departments within the company. An organization can be any object you’d like to represent in the user directory. You don’t have to assign users to an organization, although you can use organizations to group users. In the user directory UI, users who are assigned to an organization are called members of that organization.
Users, organizations, and roles are all considered examples of principals. Principals are logical identities that may be granted or denied access rights in various ATG security domains. In this way, user directories provide a uniform way for ATG security models to look at a user and to understand the user from a security point of view.
You can assign roles to users and to organizations. Roles define actions that users can take or positions that they hold. For example, you can assign someone the role of “buyer” within a specific organization. Buyers may have access to certain repository items, and you can easily group together all users who have the role “buyer.” You could also assign someone the role “VP of Sales.” This role is a little different because you probably would assign this role to only one user. You can specify access rights for a role. For example, perhaps the role “VP of Sales” has the ability to view and to edit the profiles of all the users who have the role “buyer.”
In addition, you can assign roles to organizations. For example, you could assign an organization in the user directory the role of “Partner,” and you can specify that partners have access to certain repository items. Users who belong to an organization can inherit that organization’s role. Roles can be one of two types:
Global roles are roles that you can assign to any user or organization. If you assign a global role to an organization, all users who belong to that organization and any child organizations inherit that role. Global roles are the only kind of roles that you can organize in role folders.
A role folder is a collection of child roles and role folders that serves as a organizing element for the space of global roles. You cannot assign any security permissions to a role folder because it is not a
Principal
object. Some directory implementations may not support the creation of any folders but the root folder. For example, if you do not have the Personalization module installed, a user directory manages the organization of your internal ATG product users, but it does not have the capacity to manage profiles. In this case, a single role folder encapsulates the roles assigned to internal users.Organizational roles are roles that a user plays in the context of a specific organization. Organizational roles are also called relative roles.
An organizational role has a property called function that allows you to establish a connection among similar organizational roles. For example, you could have several different roles, Marketing Director, Human Resources Director, and Customer Service Director, that have the same basic function, “director.” By specifying the same value for the
function
property of each role, you can track the connection among the roles and write custom code that makes use of it.
The following figure illustrates the relationships within a user directory:
In this figure, the User
, Role
, and Organization
objects are all Principal
objects. In this example, the user is assigned a global role and inherits the OrganizationalRole
, which is a role that pertains to a specific organization. The organization may inherit characteristics from its parent organization. A user directory doesn’t need to support all the possibilities detailed in this diagram. It can contain any subset that you decide upon. For example, the concept of relative roles might be absent from a user directory.
While users and organizations are usually RepositoryItem
objects, groups and roles are usually objects of other types. You can determine the PrincipalType
of each Principal
object. Available types are user
, organization
, and role
. The determination of a PrincipalType
of a principal object is internal to the user directory. You can, however, examine a Principal
object within the user directory and determine that it is a RepositoryItem
or another dynamic bean and modify that object accordingly.
The following figure is an example of an organizational scheme: