HP 3000 Manuals

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