Ownable Resource Security › Authorizing Resource Access › Using Multiple Access Authorizations

Using Multiple Access Authorizations

For each resource access request, CA Top Secret conducts a security validation search to determine whether the access request is granted. Sometimes CA Top Secret encounters more than a single pertinent CA Top Secret entry during this search. For example, suppose USER01 requests READ access to the MAINT.0191 minidisk while control option AUTH(MERGE) is in effect. With this AUTH setting, both the user’s primary and all attached profile Security Records are always searched. In addition, USER01 is attached to profiles PROFA and PROFB.

During its validation search, CA Top Secret encounters two pertinent entries:

TSS PERMIT(PROFA)  VMMD(MAINT.)  ACCESS(MULTI)

TSS PERMIT(PROFB)  VMMD(MAINT.0191) ACCESS(READ)

Because the second PERMIT is a “better match” to the resource to which access is being requested, it governs whether the request is granted. Since it does provide authorization, the request is approved.

Multiple authorizations can be used to efficiently “tailor” elements in an overall security structure. Our example above might apply to a situation in which a large group of users (PROFA) are allowed to read a family of minidisks (MAINT.), while only a subset of this group (PROFB) are given the authority to update a particular member of this family (MAINT.0191). However, multiple authorizations may be employed carefully in order to avoid unexpected results.

To eliminate authorization ambiguities while still allowing users great flexibility in setting up their security restrictions, CA Top Secret uses a validation algorithm to determine whether a particular access request is granted. Refer to the “The Access Validation Algorithm” chapter in the General Concepts Guide for a description of how this algorithm operates.

CA Top Secret treats separate TSS PERMIT entries designating the same ACID and resource as discrete permissions rather than consolidating them into one combined permission.

To see the implications of these discrete permissions, consider these two sets of PERMIT commands:

Example A

TSS PERMIT(ALL) TERM(GRAF05DC) TIMES(08,17) DAYS(WEEKDAYS)

Example B

TSS PERMIT(ALL)  TERM(GRAF05DC)  TIMES(08,17)
TSS PERMIT(ALL)  TERM(GRAF05DC)  DAYS(WEEKDAYS)

In example A, the permissions are consolidated and follow AND logic: In other words, both conditions must be satisfied. To use terminal, you must log on Monday through Friday during business hours only.

In example B, the permissions are discrete and use OR logic, which means the logon attempt must be either during business hours or during the week.

Note that, in certain instances, the historical order in which multiple authorizations were made can determine which CA Top Secret error message is issued. For example, assume these two PERMITs have been entered in the order indicated:

TSS PERMIT(USER01)  VMMD(MAINT.)  ACCESS(READ)  DAYS(MON)
TSS PERMIT(USER01)  VMMD(MAINT.) ACCESS(UPDATE)  DAYS(TUES)

Now, if USER01 tries to update a MAINT minidisk on a Monday, CA Top Secret denies access and issues an error message telling USER01 that the request is denied because of no UPDATE access. However, if the order of the authorizations had been reversed, then the request is denied but the error message says that USER01 is only authorized to UPDATE the MAINT minidisk on Tuesdays.