How Does CA ACF2 for z/VM Work? › What is the User Identification String?

What is the User Identification String?

The user identification string (UID) groups users to make rule writing easier and more efficient. The UID identifies individual users or groups of users in rules for access to data and resources. Choosing the proper UID is the most important task you will do when implementing CA ACF2 for z/VM.

The UID is built at logon time for every user who accesses the system. When a user requests access to a protected object, the user’s UID is matched against the rule to check if the user can access the object. The UID is a 1‑ to 24‑character pseudo field constructed of logonid record fields. It enables you to add information such as department, group or project name, job responsibility, employee ID number, or other data necessary for determining access privileges. Your site can select which fields it uses, but it must use the same UID format for all users. The UID can include the fields supplied with CA ACF2 for z/VM or fields defined by your site. For example, you could specify that the UID be composed of five logonid record fields:

The first four fields are site‑defined and the logonid is an CA ACF2 for z/VM‑defined field. With this UID layout, each user defined to the system has a unique UID.

Suppose you had to define a UID for Ann Smith. She is employed with the True Lock Company in Chicago. Her user ID is TLCAMS. She works in the Marketing division in Department 02, with a Job function of 44. Ann’s UID would be CM0244TLCAMS.

The advantage of the UID is that you can define subsets of users in ways that the logonid cannot. The UID allows grouping of users by any character fields defined in the logonid record. When the data or resource owner writes rules, he determines who he wants to allow access to the object.

The following examples illustrate the power and flexibility the UID provides:

• UID(C)
• UID(****86)
• UID(*M**44)
• UID(******TLCAMS)

In this example, all users in Chicago match the UID value; all users with job function 86 in the True Lock Company match the UID value. All users in the Marketing division with function 44 match the UID value. Line number four of this example shows a UID value for logonid TLCAMS. If the UID is specified this way, Ann Smith (TLCAMS) matches this value regardless of what department or site she is transferred to, and what functions she performs there.

As you can see, the UID is very powerful and simplifies rule writing. To use the UID more effectively, it is critical that you design it carefully and correctly. After users have started creating rules, you cannot modify the UID without impacting many of your existing rules. You must also consider both the length and content of the UID. The format you select must apply to your entire organization, though you can use selected fields in the string to define different functions in different identifiable groups. The UID should be long enough to contain all meaningful data that is required for the proper generation of all rules. However, redundancy or using excessive characters can make the UID too long to use effectively.