Access Control and Entitlement Management
Last updated
Last updated
Today, enterprise applications seek ways of enforcing security that allows the right people to access the right resources with restrictions enforced by enterprise policies. Identity and entitlement management systems, as a whole, attempt to address these security considerations. These systems help enterprise architects and developers in their application requirement implementations and try to significantly ease the burden of security-related implementations. These identity and entitlement management systems are governed by industry standard specifications, hence supporting security requirements for heterogeneous applications becomes easy.
Bellow describes the various types of access control.
Access control lists are the oldest and most basic form of access control. This type was primarily adopted for use in operating systems. This maintains a set of users and operations that can be performed on a resource as a mapping. This is easy to implement due to the use of maps. However, this is not scalable for larger user bases and can become difficult to manage.
Role-based Access Control (RBAC) is an approach used to restrict access to authorized users based on their role. This is a static permission model which provides access control. It is used by the majority of enterprises with more than 500 users.This access control type is used when all users are categorized into different roles. The roles define the resources that can be accessed by users assigned to that role. This type of access control reduces management overhead. These users and roles can also be externalized using user stores. These roles need to be managed carefully. There can be instances where a user is assigned to multiple roles. This is a subset of ABAC.Static permissions for roles can be given by updating permission tree in WSO2 Identity Server. Click here for information on Configuring roles and permissions.
Attribute-based access control (ABAC) defines a new access control paradigm whereby access rights are granted to users through the use of policies that combine attributes together.Here, authorization happens based on attributes. This access control type addresses the limitations of role-based access control to provide a more fine-grained approach. This can be based on the attributes of the user, the environment, or even the resource itself. This is more flexible when compared with the role-based approach. There is no need to know the user prior to granting access.
This type of access control addresses the requirement to have a more uniform access control mechanism. This helps larger enterprises to have uniform access control for the large amount of organizational units. This is helpful when carrying out security audits.This is the most complex form of access control. This involves specifying policies unambiguously using XACML and using authorized attribute sources in the enterprise. Here Policy Based Access Control(PBAC) (also called Rule-based access control) is an extension of ABAC where attributes are used in writing policies.
XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized by the Technical Committee of the OASIS consortium. XACML is popular as a fine grain authorization method among the community. However, there are aspects of XACML that surpasses other policy standards by being a fine-grained authorization mechanism.
Although XACML was introduced as a standard by OASIS in 2003, not many organizations that have adopted it yet. This is because most organization's lack of interest in moving towards a XACML based solution for authorization. The following can be some of the reasons for this:
Many software designer and developers lack a clear understanding of features, importance, and advantages of XACML.
It is comparatively difficult to implement a XACML solution when compared with a typical JDBC or hard-coded authorization system.
Performance of XACML-based authorization system may be less than adequate.
The complexity of defining and managing XACML policies.
However, current market trends indicate that there is some motivation for XACML-based authorization systems. This section includes some architectural and implementation details on XACML with an existing XACML engine.
To summarize, XACML describes both an access control policy language, request/response language, and reference architecture. The policy language is used to express access control policies (who can do what, when). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries(responses). The reference architecture proposes a standard for deployment of necessary software modules within an infrastructure to allow efficient enforcement of policies.
WSO2 Identity Server uses XACML as a tool for controlling access to applications.Recommended reading
For more information on XACML specifications and other related information, see the OASIS website.
Most of the organizations still use legacy systems with inbuilt authorization logic. Sometimes, one organization contains a large number of information systems and applications that each system or application uses for their own process for authorization. Today, authorization has become more complex because users within organizations and outside need access to shared data and have the need to collaborate efficiently. Therefore, this has been challenging task to manage these legacy systems, custom authorization systems. However, XACML offers a solution to this problem.
Most traditional authorization systems mostly have the following features:
Authorization logic is hard-coded into the source code.
Authorization logic is stored in databases that could only be readable and understandable by the underlying application
The following are the some goals that current organizations are looking at from an authorization system.
Can business managers (who should determine how access controls would be implemented) define and modify different authorization logic?
Can we find new IT technicians to manage these legacy systems? Especially when those who developed the system have left the organization?
Can different authorization logic be modified without any source code changes in a dynamic way?
Is authorization system capable of evaluating following rule? “X resource can be accessed by the Users who are from example.com domain and whose age is greater than 21 years old”
If we are going to implement a new information system with the organization, can we re-use the authorization logic of a legacy system?
Can we achieve a fine-grained authorization level without defining a large number of static combinations?
Are the authorization systems capable of answering the questions such as: “Can a user, Bob, transfer X amount from Y current account at 1.00pm?“
Clearly, the above goals cannot be achieved from a traditional authorization system. However, a XACML-based authorization solution can help to achieve all of these goals, because XACML:
is a standard which is ratified by OASIS standards organization.
is a policy language implemented using XML which is an industry standard.
supports Attribute-based Access Control (ABAC) and evaluation can be done with the additional data retrieved from Policy Information Point (PIP) which is defined by the XACML reference architecture.
ABAC is an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc.). This model supports boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. For example: IF the requestor is a manager, THEN allow read/write access to sensitive data.
contains reference architecture which is provided to externalize the authorization system. The Policy Decision Point (PDP) offers authorization as a service in your infrastructure. Authorization algorithms can be removed from the application logic and applications can query the PDP via their own Policy Enforcement Points (PEP).
provides fine-grained authorization with higher level of abstraction by means of policies and rules.
supports dynamic evaluation of policies by using the Policy Information Point (PIP).
can publish multiple policies into external PDPs.
Policy Decision Point (PDP) evaluates policies against access requests provided by Policy Enforcement Points (PEP). To provide the decisions, PDP may also need to query a Policy Information Point (PIP) to gather descriptive attributes about the user or any other missing attribute in the request. Policy Administration Point (PAP) is used to manage the PDP and PIP functionality.
The XACML reference architecture illustrated above is comprised of the following four 'building blocks'.
Policy Enforcement Point (PEP): The system entity that performs access control by making decision requests and enforcing authorization decisions. This is the entity that sends the XACML request to the Policy Decision Point (PDP) and receives an authorization decision.
Policy Decision Point (PDP): The system entity that evaluates an applicable policy and returns an authorization decision.
Policy Information Point (PIP): The system entity that acts as a source of attribute values. If there are missing attributes in the XACML request that is sent by PEP, PIP would find them for the PDP to evaluate the policy.
Policy Administration Point (PAP): The system entity that creates a policy or policy set and manages them.
