Occurrence Security [ HP System Dictionary XL Gen. Ref. Vol. 1 ] MPE/iX 5.0 Documentation
HP System Dictionary XL Gen. Ref. Vol. 1
Occurrence Security
The security scheme for entities is exactly the same as that for
relationships, and is accomplished by two parallel sets of operations,
one for entities and one for relationships. In the following paragraphs,
therefore, occurrence can mean either entity or relationship.
Figure 5-1 outlines the security scheme for occurrences. Note that the
boxed text in the sections labeled 'Scope Capability' and 'Linked Scope
Access' lists the capability of the scope. The text in parentheses shows
the actual access the scope has to an occurrence. This access is
determined by the combination of occurrence sensitivity and scope access
rights, which are explained in detail on the following pages, and
illustrated below.
In the example, note that a scope having create capability can read or
modify an occurrence whose sensitivity is set to public modify, but
cannot modify an occurrence whose sensitivity is set to public read,
unless that scope is either the owner of the occurrence or has been given
modify access to the occurrence by its owner.
Figure 5-1. Occurrence Security
The security for any occurrence depends on the following:
* The access rights of the current scope to that occurrence.
* The sensitivity of the occurrence.
Access Rights
The access rights of a scope to an occurrence are determined by whether
the scope owns the occurrence or is just associated with it. Association
and ownership are discussed below.
Occurrence Ownership. When a scope owns an occurrence, it has all rights
to that occurrence, and can therefore read it, modify it, transfer its
ownership to another scope, or even delete it. It can also allow another
scope access to the occurrence by associating the occurrence with that
scope. Note that the DA scope always has all rights to all occurrences.
The security of an occurrence applies to all versions of that occurrence.
When you create an occurrence, if no other version of that occurrence
exists, the current scope becomes the owner scope. If another version of
that occurrence already exists, then the current scope must be the DA
scope or the owner scope of the existing version of the occurrence.
Occurrence/Scope Association. An association between an entity or
relationship occurrence and a scope is an explicit access capability
granted to that scope by the owner scope of that occurrence. When a
scope is associated with an occurrence, its rights to that occurrence are
dependent upon the type of association it has. Associations between
scopes and occurrences can be either of two types:
* Read Access, which gives the associated scope the capability to read
the occurrence. Further information about retrieving information
about occurrences is located in Chapter 4 of the HP System
Dictionary/XL Intrinsics Reference Manual (32256-90002). Refer to
the intrinsics SDGetEnt, SDGetEntList, SDGetRel, and SDGetRelList,
which are used to retrieve information about occurrences.
* Modify Access, which not only gives the associated scope the
capability to read the occurrence, but also allows it to change the
values of most of its attributes.
To modify an occurrence, the associated scope must also have create
capability, and if creating links, must also have read access to the
common domain entity or common domain relationship involved in the
link.
When an occurrence is associated to a scope, all versions of that
occurrence are associated with the scope.
A scope can delete occurrence associations it has created from any
occurrence/scope association. It can also delete occurrence/scope
associations from itself. For a local domain occurrence to be linked to
a common domain occurrence, the owner scope must have at least read
access to the common domain occurrence. Only the owner scope or DA scope
can modify the link to a common domain occurrence. Note that a scope
that has access to a common domain occurrence can also read the names of
all of the local domain occurrences that are linked to that common domain
occurrence.
A two step process is required to modify an occurrence/scope association
(change the association between an occurrence and a scope).
* Delete the current association.
* Create a new association.
Further details on associations are located in the descriptions of
intrinsics SDAddEntScope, SDAddRelScope, SDDeleteEntScope and
SDDeleteRelScope in Chapter 4 of the HP System Dictionary/XL Intrinsics
Reference Manual (32256-90002).
Sensitivity
Sensitivity is an attribute of an occurrence. It is set to one of three
values when you create the occurrence, and can be changed only by its
owner scope or the DA scope. The three values are:
0 = Private sensitivity: Only the DA scope or the scope that owns the
occurrence is allowed access to it, unless the scope assigns access to
other scopes through occurrence/scope associations.
1 = Public Read sensitivity: Any scope with at least read capability
may read the occurrence. The DA scope or owner scope can assign other
scopes modify access to the occurrence through occurrence/scope
associations.
2 = Public Modify sensitivity: Any scope with read capability may read
the occurrence. Any scope with at least create capability may read and
modify the occurrence.
You should determine the sensitivity of an occurrence carefully. If you
do not specify the sensitivity when you create the occurrence, it
defaults to the value specified in its attribute edit, or to private, if
no attribute edit exists. If you change the sensitivity from public to
private, all scopes that previously had access to this occurrence will no
longer have access, unless that occurrence is explicitly associated with
them.
Specific Restrictions
System Dictionary provides security that is specific to entities and
security that is specific to relationships. These are discussed here.
Only the DA scope or the owner scope can create or delete a synonym for
an entity. Any scope with at least read access to an entity can list all
of an entity's synonyms.
Only the DA scope or the owner scope can change the scope-owner and
sensitivity attribute values of an occurrence, even if other scopes have
modify access to the occurrence.
NOTE If a scope deletes an entity it owns, then all relationships
involving that entity are also deleted, even if the scope does not
own or have access to all those relationships.
Example of Entity Security
The next two pages provide an example of how you could set up security
for specific scopes and entities in System Dictionary, and then modify
them to increase the access of each scope.
You define Scope1 and Scope2 in the dictionary with create and read
capability. You define Scope3 in the dictionary with read capability.
A user opens the dictionary with the scope Scope1. This user creates the
file File1 and the record Record1, both with sensitivity set to private,
and element Element1 with sensitivity set to public modify. Scope1 is
the owner of these three entities. Only Scope1 or the DA scope can
delete these entities.
Another user opens the dictionary with Scope2. This user creates element
Element2 with sensitivity set to public read and element Element3 with
sensitivity set to private. Scope2 is the owner of these entities. Only
Scope2 or the DA scope can delete these entities.
The table below lists each of the entities the scopes have access to at
this point. Note that neither Scope2 nor Scope3 have access to File 1 or
Record 1, and that Scope3 has at most have read access to an entity
because it has just read capability.
Table 5-1. Security Example
-----------------------------------------------------------------------------------------------
| | | |
| SCOPE | ENTITIES | ACCESS CAPABILITY |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| Scope1 | File1 | modify, delete, read |
| (create, read) | Record1 | modify, delete, read |
| | Element1 | modify, delete, read |
| | Element2 | read |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| Scope2 | Element1 | modify, read |
| (create, read) | Element2 | modify, delete, read |
| | Element3 | modify, delete, read |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| Scope3 | Element1 | read |
| (read) | Element2 | read |
| | | |
-----------------------------------------------------------------------------------------------
To allow Scope2 and Scope3 access to File1 and Record1, Scope1 associates
these entities to those scopes. Both Scope2 and Scope3 are given read
ScopeAccess to Record1, Scope2 is given modify ScopeAccess to File1, and
Scope3 is given read ScopeAccess to File1.
The table below lists each of the entities the scopes have access to
after these changes were made. Note the addition of File 1 and Record 1
to Scope2 and Scope3.
Table 5-2. Security Example After Modifying Scopes
-----------------------------------------------------------------------------------------------
| | | |
| SCOPE | ENTITIES | ACCESS CAPABILITY |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| Scope1 | File1 | modify, delete, read |
| | Record1 | modify, delete, read |
| | Element1 | modify, delete, read |
| | Element2 | read |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| Scope2 | Element1 | modify, read |
| | Element2 | modify, delete, read |
| | Element3 | modify, delete, read |
| | File1 | modify, read |
| | Record1 | read |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| Scope3 | Element1 | read |
| | Element2 | read |
| | File1 | read |
| | Record1 | read |
| | | |
-----------------------------------------------------------------------------------------------
To create a relationship between File1 and Record1, the scope must be
either the DA scope, Scope1, or a scope with create capability and at
least read access to File1 and Record1 which includes Scope2 but not
Scope3. Again, Scope3 is only able to read from the dictionary because
it has just read capability. If Scope2 creates a relationship between
File1 and Record1 then Scope2 becomes the owner of that relationship.
Only Scope2 or the DA scope can delete that relationship. Only Scope2,
the DA scope or a scope with modify access to that relationship can
modify that relationship.
MPE/iX 5.0 Documentation