An end-user might consider a computer system access point to be somewhat simple. Either you have a key – and you get in – or you don’t. If you have a key to the door, you get in. Some areas are special and requires a special key which only management has. Simple!
You have a username and a password. Whether or not you get in is a yes or no. Right?
Well, yes, but – unfortunately, that’s not quite the reality of things. There might be one section of that special area which the finance department should reach, but should not access the rest of the area. And the administrative personell need other areas, but should not see everything. And so it goes.
And how does it work beneath the surface. Here’s a very brief look at some options, just as an introduction and to get to dip your toes into the water of access control.
Access control models
MAC (Mandatory Access Control) assigns a particular access/security level for each resource object. In order for a subject to gain access to the resource, it has to satisfy certain conditions and security clearances. Only the administrator can grant and amend an objects security label or a user’s security clearance. (Sanyal and Iyer, 2013)
DAC (Discretionary access control) is a more flexible access control whereby various users can be given access based on the subject’s discretion, tracked in an Access Control Matrix (ACM). If a user or group is the owner of an object, they can then give access to other users and groups.
ITU-T access control standard X.812 uses access control enforcement function (AEF) and access control decision function (ADF) to determine whether an initiator is allowed to access the target. This is based on the access control policy rules.
AAA refers to a framework for controlling access to resources, policy-enforcement, auditing and service billing. AuthN checks a user’s authentication credentials while AuthZ authorises access rights, often in the form of an AuthzTicket (Doulamis et al., 2009).
RBAC (Role-based access control) accommodates, to some level, contextual support. It can give different access rights based on what role you are currently having: A team leader on duty should have more rights than if acting as a regular staff member. (Anderson, 2008, pp. 250, Ferraiolo, Cugini and Kuhn, 1995) If a user should be given rights by discretion (DAC) this can be accommodated by giving the user an extra role. If access level control should be used (MAC), RBAC can accommodate this as well. Permission enforcements are not placed on the resource or access object but on roles for the users.
Some potential obstacles with RBAC
Producing a potentially large volume or roles in the system, to the degree of it being unmanageable – called a “role explosion”. A mutual understanding of roles has to be achieved in order to maintain a unified way of working. (Karp, Haury and Davis, 2010) Not having a broad enough support for context, such as day vs night or war vs peace. (Karp, Haury and Davis, 2010)
This makes it possible to grant access to a database or facility but cannot give specific access rights once inside of the service-oriented application. For example, when working inside of a DBMS, a super user should have access to more functionality than a standard user – even though they are both allowed to access the system.
RBAC authorisation model could potentially be combined with AAA architecture for a stronger security handling of resources; whereby user authorisation has to be performed in addition to them having a role permitting them to access the resource. (Cisco, 2017, Demchenko et al., 2005)
XACML provides a policy language expressing rules for access control to various resources, defining application-specific profiles. It can be used with RBAC for access control on resources and defines which subject can take actions on a resource (S-R-A), even extending i to take the environment component into consideration (S-R-A-E).
Image: (Axiomatics, 2013)
RBAC, properly configured, will most likely work well for permission handling unless specific security measures need to be considered. If increased security is needed, RBAC could be used with AAA architecture and/or XACML for a comprehensive framework. Keep in mind though that this area of security and computing is in constant development and tomorrow a better system might be available.
Anderson, R. (2008) Security engineering: a guide to building dependable distributed systems. John Wiley & Sons. pp.1-1040.
Axiomatics. (2013) XACML 101 Tutorial – A note on the XACML standard [Online video]
Cisco. (2017) Cisco ACI AAA RBAC Rules and Privileges [Online] Cisco. Available from: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_KB_AAA-RBAC-roles-privileges.html (Accessed: 22.01.2019).
Demchenko, Y., Gommans, L., de Laat, C., et al. (2005) ‘Security architecture for open collaborative environment’, Anonymous European Grid Conference, Springer. pp.589-99.
Doulamis et al. (2009), ‘Networks for Grid Applications: Third International ICST Conference’, GridNets 2009.
Ferraiolo, D., Cugini, J. and Kuhn, D. R. (1995) ‘Role-based access control (RBAC): Features and motivations’, Anonymous Proceedings of 11th annual computer security application conference, pp.241-8.
Karp, A., Haury, H. and Davis, M. (2010) ‘From ABAC to ZBAC: the evolution of access control models’, Anonymous International Conference on Cyber Warfare and Security, Academic Conferences International Limited. pp.202.
Main image: neshom, Pixabay free for commercial use licence. https://pixabay.com/en/door-accessibility-lock-doorway-1089560/