Access Control Tracking (CSUAACT)

Edit online

The Access Control Tracking verb allows you to track the usage of ACPs for a defined span of time, and also allows you to query that tracking information.

Use the Access Control Tracking verb to start or stop tracking of access control points (ACPs) that are queried by applications. You can also use this verb to maintain ACP tracking information. Some key points to consider are:

  • Tracking is started, stopped, and maintained on a per role basis, for one or more role IDs at a time.
  • Tracking of ACPs occurs between START and STOP requests.
  • Whenever an application, that is running under a role ID that is being tracked, causes an ACP to be queried, this ACP is tracked.
  • ACP information is returned on the basis of the selected role ID.
    • Data size: CSUAACT uses the same access-control-point list data structure and transfer semantics as the Access Control Maintenance (CSUAACM) verb. Both verbs also share the same transfer size limitations, if any. It is deemed unlikely that role tracking data for one role passes the maximum data transfer size for a platform since typically data for a single role is returned.
    • If a SIZEDATA request for a given list of roles results in an error that indicates the total size is too large to transfer, try reducing the size of the list of roles by dividing it into multiple queries.
  • Tracking configuration and data is retained inside the cryptographic coprocessor until cleared by a specific request or re-initialization.

To use this verb, do the following:

  1. Specify the desired function to perform in the rule array. Choose whether to start or stop access control tracking, whether to retrieve collected tracking data or the size of that data. You can also choose to query if tracking is enabled, or clear tracking information.
  2. Use the role_ID parameter to optionally identify one or more 8-character role IDs to be tracked. If no role IDs are specified (that is, the role_ID_length variable is 0), the verb operates on the default role, which all users may use.
  3. Specify a buffer large enough to receive any output data.
Note:
  1. Tracking of role IDs has minor performance implications. From the initialization of a role ID tracking structure after a START until it is cleared, either by the CLRDATA option of this verb or by a reinitialization of the CCA application in the coprocessor, two identical copies of the tracking structure are maintained. One is an in-memory copy, and the other is an in-storage copy. The in-memory copy serves to provide the least impact on performance, while the in-storage copy serves to survive a power outage. During the period that a role ID is being tracked, any attempt by that role to access an ACP causes the role ID access control point list of the in-memory copy to be checked. When an ACP (offset) in the list is checked and found to be set to B'1' (at least one access attempt for this ACP, whether successful or not, has been recorded), no further processing is performed. Otherwise, the offset in both the in-memory and in-storage lists is changed to B'1' from B'0'. This update to both lists only occurs once per ACP accessed.
  2. Access control data structures describes the roles and role structures and provides examples of access control data structures for the roles.
  3. You can also perform ACP tracking with the help of the panel.exe utility. Refer to panel.exe default syntax as of CCA 8.4 and to Using panel.exe to control ACP tracking.

This verb does not need to document any Restrictions nor Usage notes.