There are basically two types of access control: authentication and authorization
Authentication is the act of confirming that a user’s identity for the purpose of granting them access to a protected resource such as a computer network, computer system or sensitive document. The level of authentication must match the sensitivity of the resource being accessed. In a low authentication environment a social login such as a Google ID or Facebook ID is usually sufficient. In a high authentication environment some form of biometric is also usually required.
Authorization, on the other hand, is the act of confirming a person’s entitlement to access a resource, usually a computer program. Authorization can be simple e.g. permit or deny, or complex i.e. grant access to the General Ledger but only during business hours.
Organizations are increasingly adopting authorization mechanisms because it gives them more fine-grained access control to protected resources, and matches the requirements of modern access control systems. Whereas authentication was quite adequate when we all logged into the corporate network in order to access a computer program, nowadays access is likely to be from a mobile device and a remote location. Authorization is therefore more appropriate because it can accommodate the increased complexity of different devices and multiple connection types.
So – authentication and authorization are like chalk and cheese, they are not simply extensions of each other, and this leads us into the discussion of RBAC and ABAC
RBAC and ABAC are two different things with very limited intersection. Role-based access control is often associated with authentication in that a person’s role will determine their access permission to protected resources. A role in this instance might be their position in the company or it might mean an AD group whose members have access to, or are authenticated, to one or more systems or applications in the company. RBAC is a tried and true mechanism that can significantly improve access control within an organisation and increase efficiencies.
ABAC on the other hand relies on the evaluation of identity and context variables against pre-determined policies. For instance, the Accounts Payable Clerk may only be able to access the accounts payable ledger when connecting from an on premise device during business hours.
For ABAC to work there are a few pre-requisites:
ABAC systems typically support authorization systems where fine-grained control to protected resources is required. Benefits are: the ability to centrally manage access control policy i.e. there’s no disparity between access granted to applications across the organisation, and the real-time nature of access decisions i.e. as soon as a particular attribute value changes, access control decisions based on that attribute will change.
Access Control is the reason for managing identities. It’s important that the identity management environment within an organisation supports the access control mechanism(s) being used. A strategic plan to ensure the IAM infrastructure development aligns with its access control requirements is recommended. The strategy should also incorporate authorization – it’s the future. Access control decisions should be externalised i.e. applications with internal access control logic should no longer be acquired or developed, and protocols such as XACML should be mandated.
This series of blogs looks at the major components of identity and access management to encourage discussion and raise awareness.
Graham Williamson is the author of “Identity Management: A Business Perspective”.