Policy Based Access Control (PBAC) is a response to what observers such as Ethan Ayer, CEO of Resilient Network Systems, called “the perfect storm for data-sharing in collaborative work ecosystems,” a tempest caused by the rapid growth of the cloud, BYOD, IoT, SaaS, IaaS, mobility applications and related technologies. It swept away recognizable enterprise perimeters and rendered access control solutions such as RBAC and ABAC inadequate to the task at hand.
As David Ferraiolo, Larry Feldman, and Greg Witte, of the Computer Security Division Information Technology Laboratory of the National Institute of Standards and Technology, an institute associated with the U.S. Department of Commerce, point out, in many access control approaches, “the decision is rendered based on the user’s identity, or indirectly through predefined attribute types… assigned to the user.” These two approaches are RBAC and ABAC, respectively. In both, access determinations are made at multiple access-points with RBAC relying on decisions being made regarding whether a requesting party has the quality of being within a role permitted to access, while ABAC relies on the access determination being made based on specific policies linked to attributes of the requesting party. This was an effective strategy when working within systems of limited scale and which had clearly defined network perimeters.
As Martin Kuppinger writes, that despite the debate on whether attributes should replace roles, “[M]ost RBAC approaches in practice rely on more than purely role (i.e. on other attributes), while roles are a common attribute in ABAC. In practice, it is not RBAC vs. ABAC, but rather a sort of continuum.” It is more accurate to imagine this as continuum as being expressed along two axis: (1) an increasing policy basis for access control decisions and (2) an increasingly finer granularity for access control decisions.
Both RBAC and ABAC have some key problems. They are cumbersome and difficult to set up and manage, and they have a built-in bias towards a static approach that is increasingly ineffective within the dynamic systems within which access decisions need to be made. Ferraiolo, Feldman, and Witte note that one problem is the challenge of associating permissions or capabilities directly to users or their attributes. Another is that “the identity, group, and role qualifiers of a requesting user are often insufficient for expressing real-world access control policies.” For example, in a large environment with many resources, individuals, and applications, there can be disparate attributes and access control mechanisms among the organizational units. It is often necessary to harmonize access control across the enterprise in order to meet enterprise governance requirements.
Another problem RBAC and ABAC have is that they distance those in organizational leadership roles who have core business-objectives in mind from the access control decision-making that impacts the enterprises’ abilities to achieve those objectives. On the one hand, it is clear to all that enterprise success is based on the sustained, smooth capacity to share information between departments and beyond traditional organizational boundaries (remote employees, customers, suppliers, vendors and partners). On the other hand, it is equally clear that core business interests were, and still are, also threatened by the leakage of information that could damage customer trust, an enterprise’s competitive advantage based on confidential business data, or place it in violation of information protection regulations. Balancing these competing needs requires a technical solution that enables core business-owners to be within the access control decision-making loop.
An approach was needed that would provide a new authorization standard protocol capable of scaling and building on existing IAM, while providing an access-control solution according to context-based security policies. Out of this need, PBAC was born. It is a model that enables enterprises to address the need to implement access controls based on abstract policy and governance requirements. One way to look at PBAC, in fact, is that it is a standardization of the ABAC model at an enterprise level in support of specific governance objectives.
Essentially, PBAC combines attributes from the resource, the environment, and the requester with information on the particular set of circumstances under which the access request is made, and uses rule sets that specify whether the access is allowed under organizational policy for those attributes under those circumstances. This means that a policy-driven, workflow engine discovers, organizes and resolves information or attributes to provide the necessary context for more informed decision making about access. PBAC is specifically designed to be integrated as middleware or a micro-service into an organization’s existing system, thereby enabling SMEs and enterprises to leverage their existing investments and to ease adoption.
If we return to the previously mentioned continuum, PBAC represents a significant, qualitative leap forward along the axis of the policy basis for access control decisions, while not representing a significant change with respect to the fine granularity of access control. By taking this approach, PBAC enables organizations to have a more uniform access control model throughout the organization that is clear, auditable, and visible—one that enables decisions on access to be more easily made by those with a view of the business interests to be served and protected.
PlainID sorts out the mess associated with authorizations and access management in fast paced organizations. With PlainID’s third-generation entitlement platform, Authorization Decisions can be used as a service within the company. You can now set standards easily, and use one policy many times over to save resources.
