The 10 misconceptions of using a policy-based approach for access control

The principle of Attribute Based Access Control (ABAC) has existed for many years. It’s the evolution from simple access control lists and role-based access control, to a highly flexible system for administering access based on the evaluation of attributes.

For authorization requirements, this separates the management of access control code from the application development lifecycle. In essence, it reduces the need to touch application code every time there is a business, regulatory or internal change. ABAC presents a centralized mechanism to create policies that hone and control who has access to what, and under what conditions. The policies are created once, and implemented across the application ecosystem.

As this approach gains mainstream acceptance, the benefits and ROI of using ABAC are widely understood, but there remain some common misconceptions that delay enterprises in adopting the technology quickly. Dispelling these myths will help get the development implementation team and business leaders alike on board.

1. Adopting ABAC will impact performance

False. System performance is a major concern from development teams. It seems like every time you introduce someone new to ABAC, and launch into a conversation about “a centralized server”, the conversation quickly halts to, “Hold on – is this going to slow things down?”. In short, the answer is no. A decision engine typically adds a minuscule amount of latency (single digit milliseconds).

2. Externalized Authorization makes the system more complex

False. ABAC makes it so you don’t pollute your application code with security rules. There are tradeoffs to consider when outsourcing functions to an external service, but the benefits outweigh the disadvantages. For the developer, the interface is very simple, send a package of attributes to the authorization service, then process the permit/deny response.

3. Dynamic Authorization requires a customer to consolidate their authentication

False. Externalized Authorization is a necessary complement to authentication and can be added even if you are already using multiple login credentials. Additionally, enterprises can enforce the use of stronger authentication credentials when accessing critical or sensitive resources and transactions.

4. Developers can do authorization themselves faster

False. IT lead time to set up authorization service does take some effort, but evaluations and pilot projects can be established very quickly. The one-time project investment of implementing an ABAC program generates many returns for future projects.

5. ABAC requires XML

False. If you don’t like XML or don’t understand it, you do not have to use it. Developers can also use JavaScript Object Notation (JSON) and Representational State Transfer (REST), and it will work just as well.

6. Developers can just write their own access control code when building the application

False. Maintaining logic built into an application is exponentially more costly and inefficient. In addition to the upfront developer cost when creating the application, the ongoing costs for shifting gears to develop security code and then recode each application individually each time it’s required can be quite significant.

7. Developers can create even more flexible code

False. While it might be true for a particular use case it is most likely not adaptable to other scenarios. Coding for every specific scenario is extremely time consuming, not to mention the amount of time that is required to adequately maintain the code.

8. Roles and group lists are all I need for access control in our custom-built applications

False. Externalized Authorization frees up your development team to focus on key initiatives and eliminates the need to write many extra lines of code to deal with complex access requirements. In addition, your application may not have the entirely needed context available to properly make authorization decisions – for example, the externalized authorization service can connect to almost any data source that provides additional user or resource context.

9. Managing policies is complicated

False. First off, you can rely on business owners, security officers or system administrators to create and manage access policies. But if you choose to manage your own policies, they are easily created using the Abbreviated Language for Authorization (ALFA) shorthand syntax.

10. ABAC is just a fad

False. In 2014 Gartner predicted “By 2020, 70% of all businesses will use ABAC as the dominant mechanism to protect critical assets up from just 5% today.” That same year The National Institute of Standards and Technology (NIST) released a guide on ABAC. Clearly ABAC is becoming the mainstream way enterprises and government agencies manage access control.

Dynamic access control delivered with ABAC gives you visibility and control of access. It allows you to grant or deny user access to data based on multiple factors, namely what, who, when, why, where and how. It’s being used by global enterprises to control access to applications, APIs, databases and Big Data.

Unlike earlier access control models, ABAC provides a multi-dimensional system that through its use of attributes and policies prevents role explosion, increases scalability, enables relationships, and externalizes authorization for ease of management control. It allows organizations to comply with complex regulations in a changing and demanding regulatory environment. Lastly, ABAC bridges the gap between business and IT. ABAC uses natural language policies that can be quickly analyzed and shared with auditors and compliance managers closing the loop on access reviews.

Put simply, this means you can ensure that your organization’s data is only available to the right people, at the right time, for the right reasons, and from the right location and device. If you have business critical or sensitive data that needs to be protected, you likely have a case for dynamic authorization.