Oracle® Role Manager Developer's Guide Release 10g (10.1.4.2) Part Number E14614-02 |
|
|
View PDF |
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:
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.
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.
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.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 |
---|---|---|---|
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.) |
standard_permissions |
Delegate |
Have delegate permission for an object. (Used for role delegation.) |
|
standard_permissions |
Grant |
Have grant permission for an object. (Used for role objects for user-role assignments.) |
|
standard_permissions |
Manage |
Have management permission for an object (Includes create, update, and delete.) |
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:
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."
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 max-length=32 |
simpleDynamic |
primordial |
Boolean |
Simple Dynamic |
|
status |
primordial |
String |
Status |
Must not be null. Allowable values are Default is 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 |
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 |
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 |
The related audit object for abstractRole
, shown in Table 1-5, is defined in the standard model.
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.
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 max-length=32 |
simpleDynamic |
primordial |
Boolean |
Simple Dynamic |
|
status |
primordial |
String |
Status |
Must not be null. Allowable values are Default is 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 |
The relationship path shown in Table 1-7, is defined in the standard model.
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.
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 Default is |
|
isDelegatable |
primordial |
Boolean |
Can Be Delegated |
Default is |
|
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 max-length=32 |
|
simpleDynamic |
primordial |
Boolean |
Simple Dynamic |
||
status |
primordial |
String |
Status |
Must not be null. Allowable values are Default is 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 |
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.
The relationship path shown in Table 1-10, is defined in the standard model.
The related audit object for businessRole
, shown in Table 1-11, is defined in the standard model.
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.
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 |
|
isFinanceRelated |
standard |
Boolean |
Finance related |
Default is |
|
isHighRisk |
standard |
Boolean |
High Risk |
Default is |
|
isNpiRelated |
standard |
Boolean |
Non-Public Personal Information Related |
Default is |
|
isSoxRelated |
standard |
Boolean |
Sarbanes-Oxley Related |
Default is |
|
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 max-length=32 |
|
simpleDynamic |
primordial |
Boolean |
Simple Dynamic |
||
status |
primordial |
String |
Status |
Must not be null. Allowable values are Default is 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 |
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.
The relationship path shown in Table 1-14, is defined in the standard model.
The related audit objects for itRole
, shown in Table 1-15, are defined in the standard model.
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."
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 |
|
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 max-length=32 |
|
simpleDynamic |
primordial |
Boolean |
Simple Dynamic |
||
status |
primordial |
String |
Status |
Must not be null. Allowable values are Default is 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 |
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.
The relationship path shown in Table 1-18, is defined in the standard model.
The related audit object for systemRole
, shown in Table 1-19, is defined in the standard model.
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.
The relationship paths shown in Table 1-20, are defined in the primordial model.
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.
The relationship paths shown in Table 1-21, are defined in the primordial model.
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.
The attribute for relevantRoleAttribute
, shown in Table 1-22 is defined in the primordial model.
The relationship path shown in Table 1-23, is defined in the primordial model.
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.
The relationship path shown in Table 1-24, is defined in the primordial model.
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:
The object types shown in the diagram with solid borders are described in the following sections.
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.
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 Default is 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 |
The relationship paths shown in Table 1-26, are defined in the primordial model.
The related audit objects for abstractIdentity
, shown in Table 1-27, are defined in the standard model.
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."
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 Default is 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 |
|
|
standard |
String |
|
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 |
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 |
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."
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 The default is 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 |
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:
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."
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 |
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 asbuilding
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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:
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.
The attributes for hierarchy
, shown in Table 1-42 are defined in the primordial model.
The relationship path shown in Table 1-43, is defined in the primordial model.
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."
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 |
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."
The node relationship paths shown in Table 1-45, are defined in the standard model.
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."
The node relationship paths shown in Table 1-46, are defined in the standard model.
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:
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.
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 |
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 |
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.
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 |
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 |
The related audit object, shown in Table 1-51, is defined in the primordial model.
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.
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 |
The relationship paths shown in Table 1-53, are defined in the primordial model.
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.
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 |
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 |
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.
The relationship path shown in Table 1-56, is defined in the primordial model.
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.
The relationship path shown in Table 1-57, is defined in the primordial model.
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:
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."
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 |
The relationship path shown in Table 1-59, is defined in the primordial model.
The related audit object, shown in Table 1-60, is defined in the standard model.
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.
The relationship path shown in Table 1-59, is defined in the primordial model.
The related audit object, shown in Table 1-60, is defined in the standard model.
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:
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.
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 max-length=32 |
The relationship path shown in Table 1-64 is defined in the primordial model.
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.
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 |
The relationship path shown in Table 1-66 is defined in the primordial model.
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.
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.
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.