1 Oracle Role Manager Data Model

This chapter describes data model for Oracle Role Manager. This document contains information on the primordial and standard data models and includes the following aspects:

• General Concepts

• Roles

• Users

• Organizations

• Hierarchies

• Internal Security and Access Control

• Entitlements

• System Infrastructure

1.1 General Concepts

The general concepts described in this section reflect the important information about the Oracle Role Manager data model and how the application is built with that model.

• Data Model Layering

• Domains and Attributes

• Permissions and System Privileges

1.1.1 Data Model Layering

The Oracle Role Manager data model follows a multi-tier approach as follows:

• The base data model objects that are required for Oracle Role Manager to function as designed are defined in the primordial model. The primordial model is loaded as part of the initial deployment of Oracle Role Manager.

• The standard model provides extensions to the primordial layer, building on base objects. The objects in the standard model are required for the Web application to function as designed. This should be considered when customizing the model-related aspects of the user interface. For example, one customization approach could be satisfied by simply extending the standard model where another approach could require the standard model to be altered or even not deployed at all.

  The standard model is defined in a file named standard.xml. To view the content of this file, refer to Section 2.2.

• Optional extensions, such as the oim_integration model that supports the Oracle Role Manager Integration Library with Oracle Identity Manager, contain extensions to the standard model.

The Oracle Role Manager application data model (extensions to the primordial model) is configurable and supports incremental model additions and customizations. For example, the model containing the extensions required to use the Oracle Role Manager Integration Library with Oracle Identity Manager can be deployed after Oracle Role Manager is installed and in production. Incremental data model deployments can be performed while the application and database are running without disrupting the environment.

One effect of this layered approach is that things defined on a lower layer have very specific ways that they can be extended. For example:

• A domain definition (attribute definition) in one configuration cannot be changed or removed in another. For example, if there is a domain defined in standard.xml, you cannot deploy another data model definition at the same time that alters or removes that domain. (Refer to Section 1.1.2 for more information about domains.)

• An object type defined in one configuration cannot be changed or removed in another.

• Hierarchies can only be defined once and not extended in another configuration.

1.1.2 Domains and Attributes

The Oracle Role Manager model uses the concept of domains. Domains are attributes (values on objects) within the data model and are defined individually before they are associated with object types.

A domain defines the data type and some inherent aspects of that domain such as various aspects (maximum length, size, precision). Supported data types are String (CLOB), integer, decimal, datetime, Boolean, binary (BLOB), and reference (Long).

The domain can then be associated to object types to define attributes. When associated to those object types, further constraints can be added, such as string pattern constraints, enumerated value lists and value ranges.

Note:

Constraints defined in the domain definition, not the associated object type, cannot be altered. The same is true for domain constraints defined in the primordial model.

1.1.3 Permissions and System Privileges

The internal permissions and privileges in Oracle Role Manager are key to the system's internal security and access model and give users the access to types of events in Oracle Role Manager. These permissions and privileges should not be confused with the external privileges (entitlements) that are used to represent external security models.

Permissions represent general actions that a user may want to do with objects in Oracle Role Manager. These are defined globally and associated with object types in the standard permissions model. The standard permissions model is defined in the standard_permissions.xml file. To view the content of this file, refer to Section 2.2.

Note:

Permissions are not inherited. For example, person does not inherit the permissions defined for abstractIdentity.

System privileges are the association of a permission and an object type, such as "audit person" or "manage organization." System privileges also support inheritance, for example, a permission on abstractOrg is a general case of the same permission bound to the organization sub-type. Using this example, if a person has the manage permission on abstractOrg but not on organization, that person would implicitly have the manage permission on organization because organization extends abstractOrg.

In addition to defining permissions and system privileges, the data model is also the place where particular security policy enforcement is defined. Security policy enforcement is done through policies on an object type that specify which system privilege is necessary to manage (modify) an object of that type and also which system privilege is necessary to read the audit details of objects of that type.

The standard permissions model extends the person object type to include the audit, delegate, grant, and manage permissions on person objects. The permissions in the Oracle Role Manager system are defined in both the primordial model and the standard model as shown in Table 1-1.

Table 1-1 System Permissions

Permission ID	Defined in	Default Title	Description
any	primordial	All	Have all permissions for an object.
audit	standard_permissions	Audit	Have audit permission for an object (Access through the Web application's user interface to transaction history.)
delegate	standard_permissions	Delegate	Have delegate permission for an object. (Used for role delegation.)
grant	standard_permissions	Grant	Have grant permission for an object. (Used for role objects for user-role assignments.)
manage	standard_permissions	Manage	Have management permission for an object (Includes create, update, and delete.)

1.2 Roles

This section describes all of the role objects and role-related relationships in the data model, illustrated in Figure 1-1. The following objects are described in this section:

• abstractRole

• approverRole

• businessRole

• itRole

• systemRole

• roleGrant

• roleMapping

• relevantRoleAttribute

• userRoleAssignment

Figure 1-1 Role Object Relationship Diagram

1.2.1 abstractRole

The abstractRole object type is the abstract base type from which all roles are extended. The use of an abstract base type is necessary to permit the generalization patterns of role grants, user role assignments and general role functionality.

An instance of abstractRole is never explicitly created, but rather, is created as part of creating instances of its subtypes. abstractRole is related to abstractOrg to represent its membership in the reporting hierarchy for administrative purposes.

The base definition of abstractRole is in the primordial model and it is extended in the standard model. abstractRole has no permissions as they are defined on its subtypes. The external title for abstractRole instances is "all role," which is used in tokenized system privileges names, for example, "Audit all role objects" and "Manage all role objects."

1.2.1.1 Attributes for abstractRole

The attributes for abstract role, shown in Table 1-2 are defined in both the primordial model and the standard model.

Table 1-2 abstractRole Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
displayName	primordial	String	Display name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
eligibilityRule	primordial	CLOB	Eligibility rule	max-length=100000000
membershipRule	primordial	CLOB	Membership rule	max-length=100000000
roleType	primordial	String	Role type	Must not be null. Allowable values are static or dynamic. max-length=32
simpleDynamic	primordial	Boolean	Simple Dynamic
status	primordial	String	Status	Must not be null. Allowable values are inactive or active. Default is active. max-length=32
uniqueName	primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.2.1.2 Relationship Paths for abstractRole (primordial)

The relationship paths shown in Table 1-3, are defined in the primordial model.

Table 1-3 abstractRole Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
socHierarchy	socHierarchyRoles	many-to-one	hierarchy
role_grants	role	one-to-many	roleGrant
grantees	granted_roles	many-to-many	abstractIdentity
user_role_assignments	role	one-to-many	userRoleAssignment
assignees	assigned_roles	many-to-many	abstractIdentity

1.2.1.3 Relationship Paths for abstractRole (standard)

The relationship paths shown in Table 1-4 are defined in the standard model.

Table 1-4 abstractRole Relationship Paths (standard)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
parent_reporting_organization	child_reporting_roles	many-to-one	abstractOrg
parent_cost_center_organization	child_cost_center_roles	many-to-one	abstractOrg
parent_location_organization	child_location_roles	many-to-one	abstractOrg

1.2.1.4 Related audit objects for abstractRole

The related audit object for abstractRole, shown in Table 1-5, is defined in the standard model.

Table 1-5 abstractRole Related Audit Objects

Related Object Type	Incoming Relationship Path
roleGrant	role
userRoleAssignment	role

1.2.2 approverRole

The approverRole subtype of abstractRole is specifically for representing approver roles. It supports only being a dynamic role to fit the recommended model of dynamically managed role memberships. The special aspect of approver roles is that the membership rule resolves in a relative as opposed to a simple fashion, meaning that the set of members of the role can be determined by the approval context object provided when membership is resolved. When defining rules for approver roles, any object type can be provided as an approval context object to resolve the set of people who qualify as approvers.

The base definition of approverRole is in the primordial model and it is extended in the standard model. approverRole has the manage, and audit permissions. The external title for approverRole is "Approver Role," which is used in tokenized system privilege names, for example "Audit Approver Role objects."

For more general information about Approver Roles and examples of eligibility rules, refer to the Oracle Role Manager User's Guide.

1.2.2.1 Attributes for approverRole

The attributes for approverRole, shown in Table 1-6 are defined in the primordial model. All attributes are inherited from the abstractRole object type from which approverRole is extended.

Table 1-6 approverRole Attributes

Inherited Attribute ID	Defined in	Type	Default Title	Constraints
description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
displayName	primordial	String	Display name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
eligibilityRule	primordial	CLOB	Eligibility rule	max-length=100000000
membershipRule	primordial	CLOB	Membership rule	max-length=100000000
roleType	primordial	String	Role type	Must not be null. Allowable values are static or dynamic. max-length=32
simpleDynamic	primordial	Boolean	Simple Dynamic
status	primordial	String	Status	Must not be null. Allowable values are inactive or active. Default is active. max-length=32
uniqueName	primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.2.2.2 Relationship Paths for approverRole (standard)

The relationship path shown in Table 1-7, is defined in the standard model.

Table 1-7 approverRole Relationship Paths (standard)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
roleOwner	ownedApproverRoles	many-to-one	person

1.2.3 businessRole

The businessRole subtype of abstractRole is specifically for representing business roles. It supports being either a static or a dynamic role. Static grants of business roles support sphere of control within the Oracle Role Manager system. (Refer to Section 1.5 for information about sphere of control.)

The base definition of businessRole is in the primordial model and it is extended in the standard model. businessRole has the manage, audit, grant, and delegate permissions. The external title for businessRole is "Business Role," which is used in tokenized system privilege names, for example "Grant Business Role objects."

For more general information about Business Roles and examples of membership rules, refer to the Oracle Role Manager User's Guide.

1.2.3.1 Attributes for businessRole

The attributes for businessRole, shown in Table 1-8 are defined in the primordial model and extended in the standard model. Many attributes are inherited from the abstractRole object type from which businessRole is extended.

Table 1-8 businessRole attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
approverType		primordial	String	Approver	Must not be null. Allowable values are noapproval, roleowner, or specificperson. Default is noapproval.
isDelegatable		primordial	Boolean	Can Be Delegated	Default is false.
responsibility		standard	String	Responsibilities	max-length=4000
	description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	primordial	String	Display name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	eligibilityRule	primordial	CLOB	Eligibility rule	max-length=100000000
	membershipRule	primordial	CLOB	Membership rule	max-length=100000000
	roleType	primordial	String	Role type	Must not be null. Allowable values are static or dynamic. max-length=32
	simpleDynamic	primordial	Boolean	Simple Dynamic
	status	primordial	String	Status	Must not be null. Allowable values are inactive or active. Default is active. max-length=32
	uniqueName	primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.2.3.2 Relationship Paths for businessRole (primordial)

The relationship paths shown in Table 1-9, are defined in the primordial model.

Table 1-9 businessRole Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
business_to_it_role_mappings	business_role	one-to-many	roleMapping
it_roles	business_roles	many-to-many	itRole

Refer to Table 1-3 for additional relationship paths of abstractRole, which businessRole extends.

1.2.3.3 Relationship Paths for businessRole (standard)

The relationship path shown in Table 1-10, is defined in the standard model.

Table 1-10 businessRole Relationship Paths (standard)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
approver	approverBusinessRoles	one-to-many	person
roleOwner	ownedBusinessRoles	many-to-one	person

1.2.3.4 Related audit objects for businessRole

The related audit object for businessRole, shown in Table 1-11, is defined in the standard model.

Table 1-11 businessRole Related Audit Objects

Related Object Type	Incoming Relationship Path
roleMapping	business_role

1.2.4 itRole

The itRole subtype of abstractRole is specifically for representing IT roles. It is constrained to only be a static role, but does support mapping to zero or more business roles, representing membership inheritance (in other words, all people who have the business roles mapped to this IT role are considered members of the IT role).

The base definition of itRole is in the primordial model and it is extended in the standard model. itRole has the manage, audit, grant, and delegate permissions. The external title for itRole instances is "IT Role," which is used in tokenized system privilege names, for example "Audit IT Role objects."

For more general information about IT Roles and examples of membership rules, refer to the Oracle Role Manager User's Guide.

1.2.4.1 Attributes for itRole

The attributes for itRole, shown in Table 1-12 are defined in both the primordial model and the standard model. Many attributes are inherited from the abstractRole object type from which itRole is extended.

Table 1-12 itRole attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
isDelegatable		primordial	Boolean	Can Be Delegated	Default is false.
isFinanceRelated		standard	Boolean	Finance related	Default is false.
isHighRisk		standard	Boolean	High Risk	Default is false.
isNpiRelated		standard	Boolean	Non-Public Personal Information Related	Default is false.
isSoxRelated		standard	Boolean	Sarbanes-Oxley Related	Default is false.
	description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	primordial	String	Display name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	eligibilityRule	primordial	CLOB	Eligibility rule	max-length=100000000
	membershipRule	primordial	CLOB	Membership rule	max-length=100000000
	roleType	primordial	String	Role type	Must not be null. Allowable values are static or dynamic. max-length=32
	simpleDynamic	primordial	Boolean	Simple Dynamic
	status	primordial	String	Status	Must not be null. Allowable values are inactive or active. Default is active. max-length=32
	uniqueName	primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false) whitespace (cannot have leading or trailing spaces) max-length=256

1.2.4.2 Relationship Paths for itRole (primordial)

The relationship paths shown in Table 1-13, are defined in the primordial model.

Table 1-13 itRole Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
business_to_it_role_mappings	it_role	one-to-many	roleMapping
business_roles	it_roles	many-to-many	businessRole
it_role_privilege_mappings	it_role	one-to-many	itRolePrivilegeMapping
it_privileges	it_roles	many-to-many	itPrivilege

Refer to Table 1-3 for additional relationship paths of abstractRole, which itRole extends.

1.2.4.3 Relationship Paths for itRole (standard)

The relationship path shown in Table 1-14, is defined in the standard model.

Table 1-14 itRole Relationship Paths (standard)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
roleOwner	ownedITRoles	many-to-one	person

1.2.4.4 Related audit objects for itRole

The related audit objects for itRole, shown in Table 1-15, are defined in the standard model.

Table 1-15 itRole Related Audit Objects

Related Object Type	Incoming Relationship Path
roleMapping	it_role
itRolePrivilegeMapping	it_role

1.2.5 systemRole

The systemRole subtype of abstractRole is specifically for representing system roles. It only supports being a static role. Static grants of system roles support sphere of control by defining the objects on which the grantee has the associated privileges to act upon. For more information about privileges, refer to Section 1.7 For more information about sphere of control, refer to Section 1.5.

The base definition of systemRole is in the primordial model and it is extended in the standard model. systemRole has the manage, audit, and grant permissions. The external title for systemRole is "System Role," which is used in tokenized system privilege names, for example "Grant System Role objects."

1.2.5.1 Attributes for systemRole

The attributes for systemRole, shown in Table 1-16 are defined in both the primordial model and the standard model. Many attributes are inherited from the abstractRole object type from which systemRole is extended.

Table 1-16 systemRole Attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
isDelegatable		primordial	Boolean	Can Be Delegated	Default is false.
	description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	primordial	String	Display name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	eligibilityRule	primordial	CLOB	Eligibility rule	max-length=100000000
	membershipRule	primordial	CLOB	Membership rule	max-length=100000000
	roleType	primordial	String	Role type	Must not be null. Allowable values are static or dynamic. max-length=32
	simpleDynamic	primordial	Boolean	Simple Dynamic
	status	primordial	String	Status	Must not be null. Allowable values are inactive or active. Default is active. max-length=32
	uniqueName	primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.2.5.2 Relationship Paths for systemRole (primordial)

The relationship paths shown in Table 1-17, are defined in the primordial model.

Table 1-17 systemRole Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
sys_role_privilege_mappings	system_role	one-to-many	sysRolePrivilegeMapping
system_privileges	system_roles	many-to-many	systemPrivilege

Refer to Table 1-3 for additional relationship paths of abstractRole, which systemRole extends.

1.2.5.3 Relationship Paths for systemRole (standard)

The relationship path shown in Table 1-18, is defined in the standard model.

Table 1-18 systemRole Relationship Paths (standard)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
roleOwner	ownedSystemRoles	many-to-one	person

1.2.5.4 Related audit objects for systemRole

The related audit object for systemRole, shown in Table 1-19, is defined in the standard model.

Table 1-19 systemRole Related Audit Objects

Related Object Type	Incoming Relationship Path
sysRolePrivilegeMapping	system_role

1.2.6 roleGrant

The roleGrant relationship object type represents an explicit membership of an abstract identity to a role. Due to its relationship nature, there can only be one grant per abstract identity per role. Multiple grants that differentiate themselves by sphere of control are represented by zero or more relationships between this object and the sphere of control (represented by hierarchy index mix-ins).

To represent delegated grants, the grantee from which the delegated grant originates is stored in the originalGrantee_id reference attribute. If the grant was due to delegation, this attribute is null. Refer to Section 1.5 for more information about sphere of control on role grants.

The base definition of roleGrant is in the primordial model and it is extended in the standard model. The external title for roleGrant is "Role Grant," which is used in system messages that display in the log files and application server console.

1.2.6.1 Relationship Paths for roleGrant (primordial)

The relationship paths shown in Table 1-20, are defined in the primordial model.

Table 1-20 roleGrant Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
originalGrantee	delegatedRoleGrants	many-to-one	abstractIdentity
grantee	role_grants	many-to-one	abstractIdentity
role	role_grants	many-to-one	abstractRole

1.2.7 roleMapping

The roleMapping relationship object type represents the mapping between a business role and an IT role. The business ramifications of this are that the effective membership of the IT role is the union of members of all of its mapped business roles. Members of the mapped business role have, as a result of role mapping, any entitlements associated with the mapped IT role. Refer to Section 1.7 for information about the mapped entitlements.

The base definition of roleMapping is in the primordial model and it is extended in the standard model. The external title for roleMapping is "Business Role to IT Role Mapping," which is used in system messages that display in the log files and application server console.

1.2.7.1 Relationship Paths for roleMapping (primordial)

The relationship paths shown in Table 1-21, are defined in the primordial model.

Table 1-21 roleMapping Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
business_role	business_to_it_role_mappings	many-to-one	businessRole
it_role	business_to_it_role_mappings	many-to-one	itRole

1.2.8 relevantRoleAttribute

The relevantRoleAttribute structural type object stores attributes that are relevant to the type of role and is used to enable a fast search to find "which simple dynamic roles would be affected by a particular set of attribute values changing." For example, to resolve to all person objects whose first name is John, the relevantRoleAttribute table contains the givenName attribute.

This type enables fast synchronization of user role assignments when a system identity's attributes are modified. The external title for relevantRoleAttribute is "Relevant Role Attribute," which is used in system messages that display in the log files and application server console.

1.2.8.1 Attributes for relevantRoleAttribute

The attribute for relevantRoleAttribute, shown in Table 1-22 is defined in the primordial model.

Table 1-22 relevantRoleAttribute Attributes (primordial)

Attribute ID	Defined in	Type	Default Title	Constraints
attributeName	primordial	String	Attribute Name	Must not be null. max-length=64

1.2.8.2 Relationship Paths for relevantRoleAttribute (primordial)

The relationship path shown in Table 1-23, is defined in the primordial model.

Table 1-23 relevantRoleAttribute Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
role	relevant_role_attributes	many-to-one	abstractRole

1.2.9 userRoleAssignment

The userRoleAssigment relationship object type represents a derived (implicit) membership of an abstract identity to a role (subtype of abstractRole). These objects are created and deleted by the framework based on the results of a role's membership rule, thus representing the derived version of a role grant. Due to its relationship nature, there can only be one assignment per abstract identity per role. Unlike roleGrant objects, userRoleAssignment objects do not support concepts of sphere of control or delegation.

The definition of userRoleAssignment is in the primordial model. The external title for userRoleAssignment is "User Role Assignment," which is used in system messages that display in the log files and application server console.

1.2.9.1 Relationship Paths for userRoleAssignment (primordial)

The relationship path shown in Table 1-24, is defined in the primordial model.

Table 1-24 userRoleAssignment Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
assignee	user_role_assignments	many-to-one	abstractIdentity
role	user_role_assignments	many-to-one	abstractRole

1.3 Users

The objects in this section represent things that can interact with Oracle Role Manager, such as application users, system users, or integrated users, as illustrated in Figure 1-2. Whether a particular object can be used to interact with the system depends on the ability for it to authenticate.

The following objects are described in this section:

• abstractIdentity

• person

• systemIdentity

Figure 1-2 Users Entity Relationship Diagram

The object types shown in the diagram with solid borders are described in the following sections.

1.3.1 abstractIdentity

The abstractIdentity object type is the abstract root type for all users. This object type is necessary to allow general, user-oriented operations like role grants, user role assignments and authorization. With this base object type, there is shared business logic for identities and people and the ability to define its subtypes independently.

An instance of abstractIdentity is never explicitly created, but rather, is created as part of creating instances of its subtypes.

The base definition of abstractIdentity is in the primordial model and it is extended in the standard model. abstractIdentity has no permissions as they are defined on its subtypes. The external title for abstractIdentity instances is "User," which is used in system messages that display in the log files and application server console.

1.3.1.1 Attributes for abstractIdentity

The attributes for abstractIdentity, shown in Table 1-25 are defined in both the primordial model and the standard model.

Table 1-25 abstractIdentity Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
displayName	primordial	String	Display Name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
locale	primordial	String	Locale	max-length=128
status	primordial	String	Status	Must not be null. Allowable values are inactive or active. Default is inactive. max-length=32
uniqueName	primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256
userPassword	primordial	String	Hashed Password	max-length=64

1.3.1.2 Relationship Paths for abstractIdentity (primordial)

The relationship paths shown in Table 1-26, are defined in the primordial model.

Table 1-26 abstractRole Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
originalGrantee	delegatedRoleGrants	one-to-many	roleGrant
grantee	role_grants	one-to-many	roleGrant
assignee	user_role_assignments	one-to-many	userRoleAssignment

1.3.1.3 Related audit objects for abstractIdentity

The related audit objects for abstractIdentity, shown in Table 1-27, are defined in the standard model.

Table 1-27 abstractIdentity Related Audit Objects

Related Object Type	Incoming Relationship Path
roleGrant	grantee
roleGrant	originalGrantee
userRoleAssignment	assignee

1.3.2 person

The person object type extends abstractIdentity and represents users of Oracle Role Manager that are associated with a real person. Because of this association, they are often synchronized with external systems such as identity management, directory, or single-sign-on products. person objects are distinct from systemIdentity objects because they are typically synchronized with external systems and configured with custom attributes that would not be applicable for system identities.

The base definition of person is in the primordial model and it is extended in the standard model. person has the manage, audit, grant, and delegate permissions. The external title for person is "Person," which is used in tokenized system privilege names, for example "Audit Person objects."

1.3.2.1 person Attributes

The person object inherits attributes from abstractIdentity, defined in the primordial model, and also has direct attributes, defined in the standard model. All person attributes are shown in Table 1-28.

Table 1-28 person Attributes

Inherited Attribute ID	Attribute ID	Defined in	Type	Default Title	Constraints
displayName		primordial	String	Display Name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
locale		primordial	String	Locale	max-length=128
status		primordial	String	Status	Must not be null. Allowable values are inactive or active. Default is inactive. max-length=32
uniqueName		primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256
userPassword		primordial	String	Hashed Password	max-length=64
	audio	standard	binary	Audio file
	businessCategory	standard	String	Business Category	max-length=64
	carLicense	standard	String	Car License	max-length=16
	departmentNumber	standard	String	Department Number	max-length=64
	description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	destinationIndicator	standard	String	Destination Indicator	max-length=256
	employeeNumber	standard	String	Employee Number	whitespace (cannot have leading or trailing spaces) max-length=32
	employeeType	standard	String	Employee Type	max-length=64
	fax	standard	String	Fax number	max-length=32
	givenName	standard	String	First Name	whitespace (cannot have leading or trailing spaces) max-length=128
	homePhone	standard	String	Home phone number	max-length=32
	homePostalAddress	standard	String	Home Postal Address	max-length=256
	initials	standard	String	Initials	max-length=16
	jobTitle	standard	String	Job Title	whitespace (cannot have leading or trailing spaces) max-length=256
	jpegPhoto	standard	binary	JPEG Photo
	l	standard	String	Locale	max-length=256
	mail	standard	String	Email	max-length=128
	mobile	standard	String	Mobile phone number	max-length=20
	pager	standard	String	Pager number	max-length=20
	photo	standard	binary	Photo
	physicalDeleveryOfficeName	standard	String	Physical delivery office	max-length=256
	postalAddress	standard	String	Postal Address	max-length=256
	postalCode	standard	String	Postal Code	max-length=256
	postOfficeBox	standard	String	P.O. Box	max-length=256
	preferredDeliveryMethod	standard	String	Preferred Delivery Method	max-length=256
	preferredLanguage	standard	String	Preferred Language	max-length=256
	registeredAddress	standard	String	Registered Address	max-length=256
	roomNumber	standard	String	Room Number	max-length=256
	seeAlso	standard	String	See Also	max-length=256
	sn	standard	String	Last Name	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=256
	st	standard	String	State	max-length=256
	street	standard	String	Street	max-length=256
	telephoneNumber	standard	String	Telephone Number	max-length=20
	telexNumber	standard	String	Telex Number	max-length=20
	userCertificate	standard	binary	User Certificate
	userID	standard	string	User ID	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) min-length=4 max-length=256
	userSMIMECertificate	standard	binary	User SMIME Certificate
	x121Address	standard	String	x121 Address	max-length=16

1.3.2.2 Relationship Paths for person

The relationship paths shown in Table 1-29 are defined in the standard model.

Table 1-29 person Relationship Paths

Outgoing ID	Incoming ID	Cardinality	Foreign Type
headedOrg	orgHead	one-to-many	abstractOrg
secretary	secretarialCients	many-to-one	person
parent_reporting_organization	child_reporting_people	many-to-one	abstractOrg
parent_cost_center_organization	child_cost_center_people	many-to-one	abstractOrg
parent_location_organization	child_location_people	many-to-one	abstractOrg
manager	managedPeople	many-to-one	person
ownedITRoles	roleOwner	one-to-many	itRole
ownedSystemRoles	roleOwner	one-to-many	systemRole
ownedBusinessRoles	roleOwner	one-to-many	businessRole
ownedApproverRoles	roleOwner	one-to-many	approverRole

1.3.3 systemIdentity

The systemIdentity object type extends abstractIdentity and represents users of Oracle Role Manager that do not have a person representation. Examples of these are:

• System

  This is the identity used by Oracle Role Manager to represent the user for automated tasks. This identity cannot be used externally as it has no password to authenticate with. This user is created through the bootstrap process and cannot be modified.

• System Administrator

  This is the identity used to administer the system, for example, for running deployment tools at the command line or through the Oracle Universal Installer. This user is created through the bootstrap process and can be modified and deleted as needed.

• oimSystem

  This is an identity used by an external system, Oracle Identity Manager, when it interacts with Oracle Role Manager for purposes such as system synchronization. The user is created as part of the deployment process of the Oracle Role Manager Integration Library. Refer to the Oracle Role Manager Integration Guide for information about deploying the Oracle Role Manager Integration Library and the oimSystem user. Refer to the Oracle Role Manager Administrator's Guide for information about creating system identities.

The definition of systemIdentity is in the primordial model. systemIdentity has the manage, audit, grant, and delegate permissions. The external title for systemIdentity is "System Identity," which is used in tokenized system privilege names, for example "Audit System Identity objects."

1.3.3.1 Attributes for systemIdentity

The attributes for systemIdentity, shown in Table 1-30 are defined in the primordial model. All attributes are inherited from the abstractIdentity object type from which systemIdentity is extended.

When an external system is the system of record for people or any other particular object type, the Oracle Role Manager administrator would typically configure the system roles/grants so that only the system identity that represents the system of record for person would have permission to create, modify or delete person records. An example of this is the oimSystem system identity for Oracle Identity Manager.

Table 1-30 systemIdentity Attributes

Inherited Attribute ID	Attribute ID	Defined in	Type	Default Title	Constraints
displayName		primordial	String	Display Name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
locale		primordial	String	Locale	max-length=128
status		primordial	String	Status	Must not be null. Allowable values are inactive or active. The default is inactive. max-length=32
uniqueName		primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256
userPassword		primordial	String	Hashed Password	max-length=64
	description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	userID	primordial	String	User ID	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) min-length=4 max-length=256

1.4 Organizations

The objects described in this section and illustrated in Figure 1-3 represent various containers that are used to model different types of organization structures such as reporting hierarchies, locations and cost centers. These objects are defined in the standard model and not required for the Oracle Role Manager system to function. However, the Oracle Role Manager Web application requires that these object types exist.

The following objects are described in this section:

• abstractOrg

• building

• country

• dcObject

• division

• floor

• locality

• organization

• ou

• room

Figure 1-3 Organization Model Entity Relationship Diagram

1.4.1 abstractOrg

The abstractOrg object type represents the base type for all organizational constructs. This is necessary to allow generalization for things like hierarchy construction. Most interorganizational relationships are defined in abstractOrg so other objects generally refer to this base type for membership information.

An instance of abstractOrg is never explicitly created, but rather, is created as part of creating instances of its subtypes.

The definition of abstractOrg is in the standard model and has the manage and audit permissions. The external title for abstractOrg instances is "all organization," which is used in tokenized system privileges names, for example, "Audit all organization objects" and "Manage all organization objects."

1.4.1.1 Attributes for abstractOrg

The attributes for abstractOrg, shown in Table 1-31 are defined in the standard model.

Table 1-31 abstractOrg Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
uniqueName	primordial	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.4.1.2 Relationship Paths for abstractOrg (standard)

The relationship path shown in Table 1-32, is defined in the standard model.

Of these relationship paths, all of the parent_*_organization paths have an incoming, restricted parent action, so that the abstractOrg cannot be deleted if there is an active relationship. An active relationship would be if an organization contains another organization, person, or role.

Note:

This approach to generic organizational membership, allows the data model great flexibility but also could represent some nonintuitive patterns, such as building being contained in floor, and so forth.

Table 1-32 abstractOrg Relationship Paths (standard)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
orgHead	headedOrgs	many-to-one	person
parent_reporting_organization	child_reporting_organizations	many-to-one	abstractOrg
parent_location_organization	child_location_organizations	many-to-one	abstractOrg
parent_cost_center_organization	child_cost_center_organizations	many-to-one	abstractOrg
reporting_hierarchy_root	reporting_hierarchy_anchors	many-to-one	reportingHierarchy
location_hierarchy_root	location_hierarchy_anchors	many-to-one	locationHierarchy
cost_center_hierarchy_root	cost_center_hierarch_anchors	many-to-one	costCenterHierarchy
child_reporting_roles	parent_reporting_organization	one-to-many	abstractRole
child_location_roles	parent_location_organization	one-to-many	abstractRole
child_cost_center_roles	parent_cost_center_organization	one-to-many	abstractRole
child_reporting_people	parent_reporting_organization	one-to-many	person
child_location_people	parent_location_organization	one-to-many	person
child_cost_center_people	parent_cost_center_organization	one-to-many	person

1.4.2 building

The building subtype of abstractOrg is specifically for representing physical buildings. The definition of building is in the standard model and has the manage and audit permissions. The external title for building instances is "Building," which is used in tokenized system privilege names, for example "Manage Building objects."

The attributes for building, shown in Table 1-33 are defined in the standard model. Many attributes are inherited from the abstractOrg object type from which building is extended.

Table 1-33 building attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
buildingName		standard	String	Building name	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=64
postalAddress		standard	String	Postal Address	max-length=256
telephoneNumber		standard	String	Telephone number	max-length=20
	description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false) whitespace (cannot have leading or trailing spaces) max-length=256

1.4.3 country

The country subtype of abstractOrg is specifically for representing countries. The definition of country is in the standard model and has the manage and audit permissions. The external title for country instances is "Country," which is used in tokenized system privilege names, for example "Manage Country objects."

The attributes for country, shown in Table 1-34 are defined in the standard model. Many attributes are inherited from the abstractOrg object type from which country is extended.

Table 1-34 country attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
c		standard	String	Country code	Must be unique (case-sensitive=false) whitespace (cannot have leading or trailing spaces) max-length=2
	description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false) whitespace (cannot have leading or trailing spaces) max-length=256

1.4.4 dcObject

The dcObject subtype of abstractOrg is specifically for representing domain components. The definition of dcObject is in the standard model and has the manage and audit permissions. The external title for dcObject instances is "Domain Component," which is used in tokenized system privilege names, for example "Manage Domain Component objects."

The attributes for dcObject, shown in Table 1-35 are defined in the standard model. All attributes are inherited from the abstractOrg object type from which dcObject is extended.

Table 1-35 dcObject attributes

Inherited Attribute ID	Defined in	Type	Default Title	Constraints
description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false) whitespace (cannot have leading or trailing spaces) max-length=256

1.4.5 division

The division subtype of abstractOrg is specifically for representing divisions. The definition of division is in the standard model and has the manage and audit permissions. The external title for division instances is "Division," which is used in tokenized system privilege names, for example "Manage Division objects."

The attributes for division, shown in Table 1-36 are defined in the standard model. All attributes are inherited from the abstractOrg object type from which division is extended.

Table 1-36 division attributes

Inherited Attribute ID	Defined in	Type	Default Title	Constraints
description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false) whitespace (cannot have leading or trailing spaces) max-length=256

1.4.6 floor

The floor subtype of abstractOrg is specifically for representing floors. The definition of floor is in the standard model and has the manage and audit permissions. The external title for floor instances is "Floor," which is used in tokenized system privilege names, for example "Manage Floor objects."

The attributes for floor, shown in Table 1-37 are defined in the standard model. Most attributes are inherited from the abstractOrg object type from which floor is extended.

Table 1-37 floor attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
floorIdentitier		standard	String	Floor identifier	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=64
	description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	standard		Display Name	whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.4.7 locality

The locality subtype of abstractOrg is specifically for representing groupings of locales. The definition of locality is in the standard model and has the manage and audit permissions. The external title for locality instances is "Locality," which is used in tokenized system privilege names, for example "Manage Locality objects."

The attributes for locality, shown in Table 1-38 are defined in the standard model. Many attributes are inherited from the abstractOrg object type from which locality is extended.

Table 1-38 locality attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
l		standard	String	Locale	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=256
seeAlso		standard	String	See Also	max-length=256
st		standard	String	State	max-length=256
street		standard	String	Street	max-length=256
	description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.4.8 organization

The organization subtype of abstractOrg is specifically for representing organizations. The definition of organization is in the standard model and has the manage and audit permissions. The external title for organization instances is "Organization," which is used in tokenized system privilege names, for example "Manage Organization objects."

The attributes for organization, shown in Table 1-39 are defined in the standard model. Some attributes are inherited from the abstractOrg object type from which organization is extended.

Table 1-39 organization attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
businessCategory		standard	String	Business category	max-length=64
destinationIndicator		standard	String	Destination Indicator	max-length=256
fax		standard	String	Fax number	max-length=32
internationalISDNNumber		standard	String	International ISDN Number	max-length=32
l		standard	String	Locale	max-length=256
physicalDeliveryOfficeName		standard	String	Physical delivery office	max-length=256
postalAddress		standard	String	Postal Address	max-length=256
postalCode		standard	String	Postal Code	max-length=256
postOfficeBox		standard	String	post Office Box	max-length=256
preferredDeliveryMethod		standard	String	Preferred Delivery method	max-length=256
registeredAddress		standard	String	Registered Address	max-length=256
seeAlso		standard	String	See Also	max-length=256
st		standard	String	State	max-length=256
street		standard	String	Street	max-length=256
telephoneNumber		standard	String	Telephone number	max-length=20
telexNumber		standard	String	Telex Number	max-length=20
x121Address		standard	String	x121Address	max-length=16
	description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false) whitespace (cannot have leading or trailing spaces) max-length=256

1.4.9 ou

The ou subtype of abstractOrg is specifically for representing organizational units. The definition of ou is in the standard model and has the manage and audit permissions. The external title for ou instances is "Organizational Unit," which is used in tokenized system privilege names, for example "Manage Organizational Unit objects."

The attributes for ou, shown in Table 1-40 are defined in the standard model. Many attributes are inherited from the abstractOrg object type from which ou is extended.

Table 1-40 ou attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
businessCategory		standard	String	Business category	max-length=64
destinationIndicator		standard	String	Destination Indicator	max-length=64
fax		standard	String	Fax number	max-length=32
internationalISDNNumber		standard	String	International ISDN Number	max-length=32
l		standard	String	Locale	max-length=256
physicalDeliveryOfficeName		standard	String	Physical delivery office	max-length=256
postalAddress		standard	String	Postal Address	max-length=256
postalCode		standard	String	Postal Code	max-length=256
postOfficeBox		standard	String	post Office Box	max-length=256
preferredDeliveryMethod		standard	String	Preferred Delivery method	max-length=256
registeredAddress		standard	String	Registered Address	max-length=256
seeAlso		standard	String	See Also	max-length=256
st		standard	String	State	max-length=256
street		standard	String	Street	max-length=256
telephoneNumber		standard	String	Telephone number	max-length=20
telexNumber		standard	String	Telex Number	max-length=20
x121Address		standard	String	x121Address	max-length=16
	description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.4.10 room

The room subtype of abstractOrg is specifically for representing physical rooms. The definition of room is in the standard model and has the manage and audit permissions. The external title for room instances is "Room," which is used in tokenized system privilege names, for example "Manage Room objects."

The attributes for room, shown in Table 1-41 are defined in the standard model. Some attributes are inherited from the abstractOrg object type from which room is extended.

Table 1-41 room attributes

Attribute ID	Inherited Attribute ID	Defined in	Type	Default Title	Constraints
roomNumber		standard	String	Room number	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=256
seeAlso		standard	String	See Also	max-length=256
telephoneNumber		standard	String	Telephone number	max-length=20
	description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
	displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
	uniqueName	standard	String	Uniquely Identifying Name	Must be unique (case-sensitive=false) whitespace (cannot have leading or trailing spaces) max-length=256

1.5 Hierarchies

Hierarchies are a specialized combination between a type and a mechanism. Each defined hierarchy creates an index type to represent the hierarchy's index, and a sphere of control binding relationship that links role grants to the hierarchy index. The index type also acts as an attachment point for sphere of control. Sphere of control is a relationship between a grant and a node within a hierarchy such as reporting organization, cost center, and location. The sphere of control specifies the scope within which a grant is valid, which provides a means of limiting the validity of a role grant within a hierarchy.The hierarchy model is illustrated in Figure 1-4.

The following objects are described in this section:

• hierarchy

• reportingHierarchy

• costCenterHierarchy

• locationHierarchy

Figure 1-4 Hierarchy Model Entity Relationship Diagram

1.5.1 hierarchy

The hierarchy object is the abstract base type from which all hierarchy roots extend. It is defined in the primordial data model. It is necessary to support some generalizations, for example, the ability to specify hierarchical sphere of control for role grants.

The Oracle Role Manager deploy tool creates, edits and deletes hierarchy objects indirectly during the instance management of the hierarchy subtypes.

The definition of hierarchy is in the primordial model. The external title for hierarchy instances is "Hierarchy," which is used in system messages that display in the log files and application server console.

1.5.1.1 Attributes for hierarchy

The attributes for hierarchy, shown in Table 1-42 are defined in the primordial model.

Table 1-42 abstractOrg Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
displayName	standard	String	Display Name	Must not be null. whitespace (cannot have leading or trailing spaces) searchable=true max-length=256

1.5.1.2 Relationship Paths for hierarchy (primordial)

The relationship path shown in Table 1-43, is defined in the primordial model.

Table 1-43 hierarchy Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
socHierarchyRoles	socHierarchy	one-to-many	abstractRole

1.5.2 reportingHierarchy

The reportingHierarchy hierarchy object type represents the reporting structure of an organization. All object types use the reporting hierarchy to structure information.

A reporting hierarchy represents the managerial and authoritative relationships that reporting organizations have to one another. For example, the sales organization in China reports to the sales organization that spans all of Asia Pacific.

Because it is the default administrative hierarchy for the Oracle Role Manager Web application, the system places any unassigned person or role objects that do not have explicit parent organizations into a node in this hierarchy named Unassigned that is created at deploy time. (For more information about the Unassigned node, refer to the Oracle Role Manager User's Guide.)

The definition of reportingHierarchy is in the standard model and has the manage permission. The external title for reportingHierarchy instances is "Reporting Hierarchy Root," which is used in tokenized system privilege names, for example "Manage Reporting Hierarchy Root objects."

1.5.2.1 Node Relationships for reportingHierarchy

The node relationship paths shown in Table 1-44, are defined in the standard model.

Table 1-44 reportingHierarchy Node Relationship Paths (standard)

Parent ID	Child ID	Relationship Path
reportingHierarchy	abstractOrg	reporting_hierarchy_root
abstractOrg	abstractOrg	parent_reporting_organization
abstractOrg	abstractRole	parent_reporting_organization
abstractOrg	person	parent_reporting_organization

1.5.3 costCenterHierarchy

The costCenterHierarchy hierarchy object type represents the cost center structure of the organization.

A cost center hierarchy represents the monetary relationships organizations have to one another. For example, the North American accounting organization pays the expenses for all organizations in North America.

The definition of costCenterHierarchy is in the standard model and has the manage permission. The external title for reportingHierarchy instances is "Cost Center Hierarchy Root," which is used in tokenized system privilege names, for example "Manage Cost Center Hierarchy Root objects."

1.5.3.1 Node Relationships for costCenterHierarchy

The node relationship paths shown in Table 1-45, are defined in the standard model.

Table 1-45 reportingHierarchy Node Relationship Paths (standard)

Parent ID	Child ID	Relationship Path
costCenterHierarchy	abstractOrg	cost_center_hierarchy_root
abstractOrg	abstractOrg	cost_center_reporting_organization
abstractOrg	person	cost_center_reporting_organization

1.5.4 locationHierarchy

The locationHierarchy hierarchy object type represents the location structure of the organization.

The location hierarchy represents the physical relationship that different locations have to one another. For example, individual bank branches in San Francisco are organized under the California location.

The definition of locationHierarchy is in the standard model and has the manage permission. The external title for locationHierarchy instances is "Location Hierarchy Root," which is used in tokenized system privilege names, for example "Manage Location Hierarchy Root objects."

1.5.4.1 Node Relationships for locationHierarchy

The node relationship paths shown in Table 1-46, are defined in the standard model.

Table 1-46 locationHierarchy Node Relationship Paths (standard)

Parent ID	Child ID	Relationship Path
locationHierarchy	abstractOrg	location_hierarchy_root
abstractOrg	abstractOrg	parent_location_organization
abstractOrg	person	parent_location_organization

1.6 Internal Security and Access Control

The objects in this section are the underlying infrastructure used for the internal security model. (Refer to Section 1.2.5 for details on the systemRole object type.)

The following objects are described in this section:

• systemPermission

• systemPrivilege

• systemResource

• systemResourceType

• sysPermissionAssociation

• sysRolePrivilegeMapping

Figure 1-5 Internal Security Entity Relationship Diagram

1.6.1 systemPermission

The systemPermission object type represents the permissions that are available to associate with system resource types to use for system privileges. They are explicitly defined in the data model configuration. The any permission is defined in the primordial model and implicitly inherits all of the capabilities of any other defined permission. At model deployment time, the deployment framework creates systemPermission objects based on the permissions defined in the data model configurations.

The definition of systemPermission is in the primordial model. The external title for systemPermission is "System Permission," which is used in which is used in system messages that display in the log files.

1.6.1.1 Attributes for systemPermission

The attributes for systemPermission, shown in Table 1-54 are defined in the primordial model.

Table 1-47 systemPermission Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
name	primordial	String	Name	Must not be null. Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256
displayName	primordial	String	Display Name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000

1.6.1.2 Relationship Paths for systemPermission (primordial)

The relationship paths shown in Table 1-48, are defined in the primordial model.

Table 1-48 systemPermission Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
sys_applicable_permissions	system_permission	one-to-many	sysPermissionAssociation
n/a	system_permissions	many-to-many	systemResourceType
system_privilges	system_permission	one-to-many	systemPrivilege

1.6.2 systemPrivilege

The systemPrivilege object type represents the association between system permissions and system resources. systemPrivilege objects are mapped to system roles to represent that the members of that system role have the system permission with respect to the system resource (and due to the all pattern, to objects associated with that type). At model deployment time, the deployment framework creates one systemPrivilege for each systemResource for each applicable systemPermission (applicable system permissions are those mapped to the systemResourceType associated withe the systemResource).

The base definition of systemPrivilege is in the primordial model and extended in the standard model. The external title for systemPrivilege is "System Privilege," which is used in which is used in system messages that display in the log files and application server console.

1.6.2.1 Attributes for systemPrivilege

The attributes for systemPrivilege, shown in Table 1-49 are defined in the primordial model.

Table 1-49 systemPrivilege Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
name	primordial	String	Name	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=256
displayName	primordial	String	Display Name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000

1.6.2.2 Relationship Paths for systemPrivilege (primordial)

The relationship paths shown in Table 1-50, are defined in the primordial model.

Table 1-50 systemPrivilege Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
system_resource	system_privileges	many-to-one	systemResource
system_permission	system_privileges	many-to-one	systemPermission
sys_role_privilege_mappings	system_privilege	one-to-many	sysRolePrivilegeMapping

1.6.2.3 Related Audit Objects for systemPrivilege (primordial)

The related audit object, shown in Table 1-51, is defined in the primordial model.

Table 1-51 systemPrivilege Related Audit Objects (primordial)

Related Object	Incoming Relationship Path
sysRolePrivilegeMapping	system_privilege

1.6.3 systemResource

The systemResource object type represents a particular instance or group of system resources. Each is associated with a systemResourceType and adds a qualifier. The qualifier is intended as a mechanism allowing system resources to represent some subset of all resources of that type. When the Oracle Role Manager model is first deployed, the deployment framework creates one systemResource instance with the all qualifier for each systemResourceType object. systemResource objects are created and updated by deployment framework and cannot be modified by users.

The definition of systemResource is in the primordial model. The external title for systemResource is "System Resource," which is used in system messages that display in the log files and application server console.

1.6.3.1 Attributes for systemResource

The attributes for systemResource, shown in Table 1-52 are defined in the primordial model.

Table 1-52 systemResource Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
name	primordial	String	Name	Must not be null. Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256
displayName	primordial	String	Display Name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
qualifier	primordial	String	Qualifier	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=256

1.6.3.2 Relationship Paths for systemResource (primordial)

The relationship paths shown in Table 1-53, are defined in the primordial model.

Table 1-53 systemResource Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
system_resource_type	system_resources	many-to-one	systemResourceType
system_privileges	system_resource	one-to-many	systemPrivilege

1.6.4 systemResourceType

The systemResourceType object represents types of system resources (for example, person, abstractRole, itRole, or organization). When the Oracle Role Manager model is first deployed, the deployment framework creates one systemResourceType instance for each object type defined in the data model. systemResourceType objects cannot be modified by users and are normally not queried by them.

The definition of systemResourceType is in the primordial model. The external title for systemResourceType is "System Resource Type," which is used in system messages that display in the log files and application server console.

1.6.4.1 Attributes for systemResourceType

The attributes for systemResourceType, shown in Table 1-54 are defined in the primordial model.

Table 1-54 systemResourceType Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
name	primordial	String	Name	Must not be null. Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256
displayName	primordial	String	Display Name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
description	primordial	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000

1.6.4.2 Relationship Paths for systemResourceType (primordial)

The relationship paths shown in Table 1-55, are defined in the primordial model.

Table 1-55 systemResourceType Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
system_resources	system_resource_type	one-to-many	systemResource
sys_applicable_permission	system_resource_type	one-to-many	sysPermissionAssociation
system_permissions	n/a	many-to-many	systemPermission

1.6.5 sysPermissionAssociation

The sysPermissionAssociation relationship object type represents the association between system permissions and a system resource types. If a system permission is associated to a system resource type, this signifies that the associated system permission is applicable for resources of that system resource type. These associations are defined at the object-type level in the data model configurations. There is an implicit association between all system resource types and the any primordial-defined system permission.

At model deployment time, the deployment framework creates these objects based upon the data model configuration.

The definition of sysPermissionAssociation is in the primordial model. The external title for sysPermissionAssociation is "System Resource Type to Permission Mapping," which is used in system messages that display in the log files and application server console.

1.6.5.1 Relationship Paths for relevantRoleAttribute (primordial)

The relationship path shown in Table 1-56, is defined in the primordial model.

Table 1-56 sysPermissionAssociation Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
system_resource_type	sys_applicable_permissions	many-to-one	systemResourceType
system_permission	sys_applicable_permissions	many-to-one	systemPermission

1.6.6 sysRolePrivilegeMapping

The sysRolePrivilegeMapping relationship object types are, along with systemRole objects, the only user-modifiable parts of the internal security model. sysRolePrivilegeMapping objects describe which system privileges the members of a system role have. These mappings can be created or deleted through business logic to support whatever system role to system privilege combinations are required. At deployment time, the bootstrap deployment manager creates several of these to represent which privileges the system administrator role has by default.

The definition of sysRolePrivilegeMapping is in the primordial model. The external title for sysRolePrivilegeMapping is "System Role to System Privilege Mapping," which is used in system messages that display in the log files and application server console.

1.6.6.1 Relationship Paths for sysRolePrivilegeMapping (primordial)

The relationship path shown in Table 1-57, is defined in the primordial model.

Table 1-57 sysRolePrivilegeMapping Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
system_role	sys_role_privilege_mappings	many-to-one	systemRole
system_privilege	sys_role_privilege_mappings	many-to-one	systemPrivilege

1.7 Entitlements

The objects described in this section represent external privilege information that may be consumed by external identity management and provisioning systems. These objects, illustrated in Figure 1-6, have no impact on the internal security model.

The following objects are described in this section:

• itPrivilege

• itRolePrivilegeMapping

Figure 1-6 Entitlement Model Entity Relationship Diagram

1.7.1 itPrivilege

The itPrivilege object type represents an external entitlement. What that means to the external system is represented in the Oracle Role Manager system only in the itPrivilegeDetails CLOB attribute where information can be stored that is interpreted by the provisioning system or the actual system where the entitlement is applied. It is up to the external system, such as an access provisioning system, to interpret this data.

The base definition of itPrivilege is in the primordial model and extended in the standard model. itPrivilege has the manage and audit permissions. The external title for itPrivilege is "Entitlement," which is used in tokenized system privilege names, for example "Manage Entitlement objects."

1.7.1.1 Attributes for itPrivilege

The attributes for itPrivilege, shown in Table 1-58, are defined in both the primordial model and the standard model.

Table 1-58 itPrivilege Attributes

Attribute ID	Defined in	Type	Default Title	Constraints
description	standard	String	Description	whitespace (cannot have leading or trailing spaces) max-length=4000
displayName	primordial	String	Entitlement Name	Must not be null whitespace (cannot have leading or trailing spaces) searchable=true max-length=256
oimEntitlementId	standard	integer	OIM Entitlement Identifier	Must be unique. scale=19
itPrivilegeDetails	primordial	CLOB	Entitlement Details	max-length=100000000
resourceName	standard	String	Resource Name	max-length=256 whitespace (cannot have leading or trailing spaces)
uniqueName	standard	String	Uniquely Identifying name	Must be unique (case-sensitive=false). whitespace (cannot have leading or trailing spaces) max-length=256

1.7.1.2 Relationship Paths for itPrivilege (primordial)

The relationship path shown in Table 1-59, is defined in the primordial model.

Table 1-59 itPrivilege Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
it	system_privileges	many-to-one	systemResource

1.7.1.3 Related Audit Objects for itPrivilege (standard)

The related audit object, shown in Table 1-60, is defined in the standard model.

Table 1-60 itPrivilege Related Audit Objects (standard)

Related Object	Incoming Relationship Path
itRolePrivilegeMapping	it_privilege

1.7.2 itRolePrivilegeMapping

The itRolePrivilegeMapping relationship object type represents the link between IT roles and entitlements. When a link between an IT role and an entitlement exists, this indicates that any member of mapped business role has the mapped entitlement.

The definition of itRolePrivilegeMapping is in the primordial model. The external title for itRolePrivilegeMapping is "IT Role to Entitlement Mapping," which is used in system messages that display in the log files and application server console.

1.7.2.1 Relationship Paths for itPrivilege (primordial)

The relationship path shown in Table 1-59, is defined in the primordial model.

Table 1-61 itPrivilege Relationship Paths (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
it_role	it_role_privilege_mappings	many-to-one	itRole
it_privilege	it_role_privilege_mappings	many-to-one	itPrivilege

1.7.2.2 Related Audit Objects for itPrivilege (standard)

The related audit object, shown in Table 1-60, is defined in the standard model.

Table 1-62 itPrivilege Related Audit Objects (standard)

Related Object	Incoming Relationship Path
itRolePrivilegeMapping	it_privilege

1.8 System Infrastructure

The objects in this section have little in common other than they are used by the system for (typically) non-business-related operations. Most of them are used for back-end infrastructure and have no obvious presence in any normal user interface. All of the objects described in this section are defined in the primordial model.

The following objects are described in this section:

• auditEvent

• auditEventDetail

• baseBundle

• configuration

• localizedBundle

• pluginPack

1.8.1 auditEvent

The auditEvent object type represents the audit events that are caused during the lifetime of business transactions. It is used by the business logic layer to search for audit events, but has special access patterns. The auditEvent objects that would be returned by a search are limited to those events where the current user has the appropriate audit system privilege over the event's related object. auditEvent objects are updated by the Oracle Role Manager framework during business transactions.

The definition of auditEvent is in the primordial model. The external title for auditEvent is "Audit Event," which is used in which is used in system messages that display in the log files and application server console.

1.8.1.1 Attributes for auditEvent

The attributes for auditEvent, shown in Table 1-63, are defined in the primordial model.

Table 1-63 auditEvent Attributes (primordial)

Attribute ID	Defined in	Type	Default Title	Constraints
actorID	primordial	integer	Actor ID	Must not be null. scale=20
actorDisplayName	primordial	String	Actor Display Name	Must not be null. max-length=256
operationID	primordial	String	Operation ID	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=64
definitionID	primordial	String	Definition ID	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=64
operationTitle	primordial	String	Operation Title	Must not be null. whitespace (cannot have leading or trailing spaces) max-length=128
reason	primordial	String	Reason	max-length=4000
eventTime	primordial	datetime	Event Time	Must not be null.
transactionID	primordial	integer	Transaction ID	Must not be null. scale=10
auditStatus	primordial	String	Audit Status	Must not be null. Allowable values are approved, canceled, finalized, pending, rejected, or submitted. max-length=32

1.8.1.2 Relationship Paths for auditEvent (primordial)

The relationship path shown in Table 1-64 is defined in the primordial model.

Table 1-64 Relationship Paths for auditEvent

Outgoing ID	Incoming ID	Cardinality	Foreign Type
auditEvent	details	one-to-many	auditEventDetail

1.8.2 auditEventDetail

The auditEventDetail object type represents the audit event details that are created during the lifetime of business transactions. The auditEventDetail objects that would be returned by a search are limited to those events where the current user has the appropriate audit system privilege over the event's related object. auditEventDetail objects are updated by the Oracle Role Manager framework during business transactions.

The definition of auditEventDetail is in the primordial model. The external title for auditEventDetail is "Audit Event Detail," which is used in which is used in system messages that display in the log files and application server console.

1.8.2.1 Attributes for auditEventDetail

The attributes for auditEventDetail, shown in Table 1-65, are defined in the primordial model.

Table 1-65 auditEventDetail Attributes (primordial)

Attribute ID	Defined in	Type	Default Title	Constraints
subjectKeyID	primordial	integer	subject Key ID	Must not be null. searchable=true scale=20
subjectKeyType	primordial	String	Subject Key Type	Must not be null. searchable=true whitespace (cannot have leading or trailing spaces) max-length=64
changeTime	primordial	datetime	Change Time	Must not be null.
changeInfo	primordial	CLOB	Change Information XML	max-length=100000000
oldSubjectState	primordial	String	Old Subject State	Allowable values are effective or non-effective. max-length=64
newSubjectState	primordial	String	New Subject State	Allowable values are effective or non-effective. max-length=64

1.8.2.2 Relationship Paths for auditEventDetail (primordial)

The relationship path shown in Table 1-66 is defined in the primordial model.

Table 1-66 Relationship Paths for auditEventDetail (primordial)

Outgoing ID	Incoming ID	Cardinality	Foreign Type
details	auditEvent	many-to-one	auditEvent

1.8.3 baseBundle

The baseBundle object type is where the default localization data is stored in XML form. It is used by the Oracle Role Manager deployment tools and not accessed for business purposes. The API base bundles are not in the database, but are instead in the class path.

1.8.4 configuration

The configuration object type is where the business configuration is stored in XML form. It is used by the Oracle Role Manager deployment tools and not accessed for business purposes.

1.8.5 localizedBundle

The localizedBundle object type is where the localizations are stored in property file form. It is used by the Oracle Role Manager deployment tools and read by way of the Oracle Role Manager administrative console; it is not accessed for business purposes. Both the baseBundle and the localizedBundle have a categoryID attribute indicating a relationship, but because some base bundles are deployed in the class path as opposed to the database, there cannot be relational integrity and hence no supporting relationship paths. This object is not accessed by business logic.

1.8.6 pluginPack

The pluginPack object type is where the pluggable custom Java business logic is stored in binary form. It is used by the Oracle Role Manager deployment tools and not accessed for business purposes.