Dimensions of attribute-based access control
ABAC can be seen as: * Externalized authorization management * Dynamic authorization management * Policy-based access control * Fine-grained authorizationComponents
Architecture
ABAC comes with a recommended architecture which is as follows: # The PEP or Policy Enforcement Point: it is responsible for protecting the apps & data you want to apply ABAC to. The PEP inspects the request and generates an authorization request from which it sends to the PDP. # The PDP or Policy Decision Point is the brain of the architecture. This is the piece which evaluates incoming requests against policies it has been configured with. The PDP returns a Permit/Deny decision. The PDP may also use PIPs to retrieve missing metadata # The PIP or Policy Information Point bridges the PDP to external sources of attributes e.g. LDAP or databases.Attributes
Attributes can be about anything and anyone. They tend to fall into 4 different categories: # Subject attributes: attributes that describe the user attempting the access e.g. age, clearance, department, role, job title # Action attributes: attributes that describe the action being attempted e.g. read, delete, view, approve # Object attributes: attributes that describe the object (or resource) being accessed e.g. the object type (medical record, bank account), the department, the classification or sensitivity, the location # Contextual (environment) attributes: attributes that deal with time, location or dynamic aspects of the access control scenarioPolicies
Policies are statements that bring together attributes to express what can happen and is not allowed. Policies in ABAC can be granting or denying policies. Policies can also be local or global and can be written in a way that they override other policies. Examples include: # A user can view a document if the document is in the same department as the user # A user can edit a document if they are the owner and if the document is in draft mode # Deny access before 9 AM With ABAC you can have an unlimited number of policies that cater to many different scenarios and technologies.Other models
Historically, access control models have included mandatory access control (MAC),Implementations
There are three main implementations of ABAC:Applications
The concept of ABAC can be applied at any level of the technology stack and an enterprise infrastructure. For example, ABAC can be used at the firewall, server, application, database, and data layer. The use of attributes bring additional context to evaluate the legitimacy of any request for access and inform the decision to grant or deny access. An important consideration when evaluating ABAC solutions is to understand its potential overhead on performance and its impact on the user experience. It is expected that the more granular the controls, the higher the overhead.API and microservices security
ABAC can be used to apply attribute-based, fine-grained authorization to the API methods or functions. For instance, a banking API may expose an approveTransaction(transId) method. ABAC can be used to secure the call. With ABAC, a policy author can write the following: * Policy: managers can approve transactions up to their approval limit * Attributes used: role, action ID, object type, amount, approval limit. The flow would be as follows: # The user, Alice, calls the API method approveTransaction(123) # The API receives the call and authenticates the user. # An interceptor in the API calls out to the authorization engine (typically called a Policy Decision Point or PDP) and asks: ''Can Alice approve transaction 123?'' # The PDP retrieves the ABAC policy and necessary attributes. # The PDP reaches a decision e.g. Permit or Deny and returns it to the API interceptor # If the decision is Permit, the underlying API business logic is called. Otherwise the API returns an error or access denied.Application security
One of the key benefits to ABAC is that the authorization policies and attributes can be defined in a technology neutral way. This means policies defined for APIs or databases can be reused in the application space. Common applications that can benefit from ABAC are: # Content Management Systems # ERPs # Home-grown Applications # Web Applications The same process and flow as the one described in the API section applies here too.Database security
Security for databases has long been specific to the database vendors: Oracle VPD, IBM FGAC, and Microsoft RLS are all means to achieve fine-grained ABAC-like security. An example would be: * Policy: managers can view transactions in their region * Reworked policy in a data-centric way: users with can do the action on ifData security
Data security typically goes one step further than database security and applies control directly to the data element. This is often referred to as data-centric security. On traditional relational databases, ABAC policies can control access to data at the table, column, field, cell and sub-cell using logical controls with filtering conditions and masking based on attributes. Attributes can be data, user, session or tools based to deliver the greatest level of flexibility in dynamically granting/denying access to a specific data element. OnBig data security
Attribute-based access control can also be applied to Big Data systems like Hadoop. Policies similar to those used previously can be applied when retrieving data from data lakes.File server security
As of Windows Server 2012, Microsoft has implemented an ABAC approach to controlling access to files and folders. This is achieved through dynamic access control (DAC) and Security Descriptor Definition Language (SDDL). SDDL can be seen as an ABAC language as it uses metadata of the user (claims) and of the file/ folder to control access.See also
References
{{reflistExternal links