Role-based Access Control in a RACF
environment
An investigation of some possibilities for enhancements
Lennie Dymoke-Bradshaw June 2011
With contributions from
Role based Access
•
In the past RACF has dealt with users as individuals.
•
It has been assumed that each user might require individually tailored access
levels and permissions.
•
This has served well in the past, but requirements have changed.
•
Todays environment must deal with
– A Rapidly changing workforce
– A need for responsibilities to be managed independently of people
– A far tighter need for audit controls
– A more consistent alignment of security requirements with personnel structures
– More regular and tighter compliance reporting
– Requirements for a more readily understandable view of permissions
•
A role-based access control system can provide much of this, but RACF is not best
placed to take advantage.
•
We recognise there may be situations in which a single user inhabits a Job role.
– However there are still advantages to maintaining Job roles (responsibilities) independently of users (people).
How does access control work with RACF currently?
• RACF current uses a user-based model for managing access to resources.
• Each resource profile has an access list, and there are entries in each access list granting or denying access.
• These entries can be for the USER.
• Each USER must also be a member of at least one GROUP.
• The GROUP may also be used in an access list (but the USER entry takes precedence if present).
• If a USER is a member of more than one GROUP, and multiple GROUPs are in an access list, then the entry with the highest access takes precedence.
– This processing can be altered by negating the system-wide option “List of Groups”, but this is rarely seen nowadays.
• Each USER profile also has other privileges, authorities and attributes such as AUDITOR, RESTRICTED, PROTECTED, CLAUTH.
• Each USER profile has attributes related to USER Segments. These apply information and controls for other operating system and subsystem components. Examples are TSO, CICS, OMVS.
• Some resource profiles have a second access list called the Conditional Access list. If access is not granted by the standard access list then it may be granted by this second list which includes various conditions.
What challenges are faced by RACF installations in
attempting to implement Role-Based Access?
Most enterprises using z/OS (or z/VM) maintain large RACF databases with a large number of users. These organisation typically have a large turnover of staff, so that the creation, deletion and
modification of user definitions is a major part of the security administration. In many cases, attempts have been made to organise using a Role-Based approach, but this frequently involves many controls outside of RACF, and special processes or panels written to achieve this. These are some of the issues facing such organisations.
1. The Creation of a new user profile is frequently performed by using an existing user as a model. However, there are no controls to ensure that all users with a Job role have the same access or attributes.
2. While this process of creating a userid using another userid as a model can be performed using priced RACF add-on packages, or home-grown routines, there is no functionality within the base product.
3. Some installations create specialised USER profiles to act as these Job roles, but these can be a security exposure as they are not associated with any particular person, but can still be used to gain access to resources.
4. There is no function available to compare one User profile with another, to confirm adherence to the Role Based approach
5. When “temporary” access is required, it is frequently granted, and then not withdrawn, but only from a single user, thus breaking the Role-Based relationships.
What challenges are faced by RACF installations in
attempting to implement Role-Based Access?
Continued….
6. When access changes are needed to a Job role this may be achieved by granting access to a
group. In this case the Role-Based access is maintained. However, if is performed by connecting a user to a new group, then all users within the Job role need to have the same CONNECT
command issued.
• Note that if access was granted to a resource by placing a group in an access list, then this may alter access for more than one Job role.
7. When a Job role has to be split, such as when a small number of people are given some administrative responsibility there is no simple way for this to be achieved.
8. There is no current method of grouping all the users within a Job role, other than using a naming convention or some other locally devised construct.
9. If members of the Job role have attributes not associated with Access, such as Auditor, Special, Restricted or have CLAUTH authorities, then these have to be separately managed.
10. If User profiles are to have attributes and capabilities set via RACF segments other than the base segment (e.g. for TSO, CICS or OMVS) then further processes have to be put in place to manage this.
11. If access to a resource is granted at the User level then this frequently breaks the Role Based approach.
12. If an installation defined Role Based access method is devised, then separate controls have to be in place to determine which users have authority to modify the authorities of the Role.
What benefits could accrue if Role Based controls were
built into RACF?
a. The set of Job roles can largely be derived from a personnel chart.
b. The attributes of each Job role can be decided more easily by examination of the Job role’s responsibilities.
c. The Job roles can be maintained and managed using less commands.
d. The assignment of users to Job roles can become a more easily managed task.
e. The comparison of authorities between Users and Job roles can be more easily achieved.
f. The examination of the capabilities of a particular User can be derived from the associated Job role definition.
g. The moving of a User from one Job role to another is more easily achieved. h. The decommissioning of Users can be more easily achieved.
i. The creation and deletion of Job roles can be more easily achieved.
j. The adjustment of access for a Job role can be achieved in a more consistent manner. k. The assignment of special privileges or restrictions can be more consistently managed.
l. The management of RACF Segments associated with Users can be achieved more easily and more consistently.
This will result in,
1) more accurate reporting of roles and responsibilities. 2) Simplified auditing of roles and users
Terminology
•
Role or Job role
–
This defines the responsibilities of a number of people
usually within a personnel chart or organisation chart.
–
A collection of permissions
•
Permissions (object-action pairs)
–
Access list entries granted by PERMIT command
–
User and Group attributes
•
SPECIAL, PROTECTED, RESTRICTED, NOTERMUACC, etc
–
CLAUTH values
–
INTERVAL values
Proposal 1: TEMPLATE user
The first approach we discuss uses a new attribute for the USER profile
which for now we shall refer to as a TEMPLATE attribute.
1.
A USER profile having the TEMPLATE attribute cannot be used in
any authorisation decision.
–
It cannot be used to logon, start a started task, run a batch job, or be
used in a RACROUTE REQUEST=VERIFY macro, which results in the
running of work.
2.
A new process here called “UserCopy” will be provided to create a
USER profile from a USER profile with the TEMPLATE attribute.
3.
A new process here called “UserCompare” will be provided to
compare one USER profile with another and produce either,
–
A list of differences, or
Proposal 1: TEMPLATE user with UserCopy process
• During the UserCopy process all attributes and permissions from “Clerk” are copied to “Bill”.
– Group connections and authorities are copied
– Segments are copied
• There has to be a customisable masking mechanism to specify those items which are required to be unique to users
– Name
– UID
– Home directories
– … other fields (e.g. in CSDATA segments)
User: Clerk
(Template)
UserCopy
User: Bill
Request for new user called “BILL” for Role “Clerk”
Proposal 1: TEMPLATE user with UserCompare process
• During the UserCompare process all attributes and permissions from “Clerk” are compared to “Bill”.
– Group connections and authorities are compared
– Segments are compared
• There has to be a masking mechanism to specify those items which are required to be unique to users
– Name
– UID
– Home directories
– … other fields (e.g. in CSDATA segments)
User: Clerk
(Template)
UserCompare
User: Bill
List of differences between Billand Clerk
(and optionally commands to reconcile differences)
Proposal 1: TEMPLATE user
•
This approach provides a mechanism for most installations to
introduce a Role-Based system, and provides basic tools for the
maintenance of the Users within each role.
•
If a USER profile has changes made to it which fall outside the Job
role definition (as defined by the TEMPLATE user profile), then we
have mechanisms to bring matters back into line.
•
However, this would provide a system which cannot be mandated.
It still needs regular checking to ensure that USER profiles do not
diverge from TEMPLATE user profiles.
•
There is no automatic adjustment of permissions, and the
permissions are still held at the USER level, when really they should
be held at the Job role level.
•
For this reason we have an alternate proposal for a mechanism
which can be used to manage permissions and attributes in a more
consistent manner.
Proposal 2: New RACF Construct: Jobrole
The second approach we discuss uses a new construct. The nature of this construct we do not mandate in any sense. It could be managed using a new RACF class. It could be similar to the TEMPLATE user discussed in Proposal 1. Or it could be something entirely different. However, we simply refer to it as a “Jobrole”.
•
The Jobrole is sufficiently similar to a USER that it can be used to specify all user
attributes, group connections and permissions.
•
The Jobrole will have the ability to have multiple USER profiles “associated with” it.
•
A user can be “associated with”
one and only one
Jobrole.
•
When determining the access capabilities or permissions of the user
• The attributes of the userare ignored
• The attributes of the Jobrole will be used
•
There still is a need for a customisable masking mechanism to specify those items
which are required to be unique to users
– Name
– UID
– Home directories
Proposal 2: New RACF Construct: Jobrole
User Initialisation: Current
User Initialisation: Proposed
User: Bill
RACROUTE
REQ=VERIFY
ACEE
User: Bill
(linked to Jobrole Clerk)RACROUTE
REQ=VERIFY
ACEE
Jobrole:
Clerk
Proposal 2: New RACF Construct: Jobrole
•
With this new mechanism the building of the ACEE is achieved by finding the
Jobrole associated with the user, and building from it and the user profile.
•
All access permissions and attributes are taken from the Job role.
•
All attributes which are unique to the user are taken from the user profile,
– E.g. Name, UID, Home, etc.
•
Any requirements for access permissions will be made to the Job role.
– User ACEEs will automatically get the new or changed permissions or attributes.
•
There will no longer be any need to ensure that all users within a Job role have the
same access,
as they will have this automatically
.
•
The need for group connections to be specified at the user level will no longer be
needed.
•
Management of Job roles will replace the management of user profiles.
•
Group profiles can still be used to manage access to resources across multiple Job
roles.
Proposal 3: Restrict userids in access lists
•
The presence of User entries in the access lists of resource profiles becomes a
challenge in managing Job roles.
•
If there are userids in access lists then this breaks the Job role rules as one
member of a Job role will get access to a resource while another will not.
•
There are several ways to tackle this, and we present some alternatives,
recognising that customers may have different requirements in this area.
1. Firstly, there should be an option to be able to specify the Job role in the access list. The justification for this is simple. If the Job role is replacing the userid as the centre for
attribute and access specification, then it makes sense to allow the Job role to be used in place of the userid.
2. Have a system-wide option to disallow the checking of userids in access lists. This could be specified as,
o Mandated for everyone
o Only for ACEEs built using Job roles
o Not active
3. Provide a system-wide option to prevent userids being specified in the PERMIT command. Again this could be specified as,
o Mandated for everyone
o Only for ACEEs built using Job roles
