OWASP Chicago 2016 - What is Attribute Based Access Control (ABAC)?
•Download as PPTX, PDF•
7 likes•2,567 views
In this presentation, I cover the history of access control, from simpler models e.g. access control lists (ACL) to Role Based Access Control (RBAC) and eventually Attribute Based Access Control (ABAC). I then discuss limitations of RBAC and how ABAC provides a better alternative using attributes and policies.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to OWASP Chicago 2016 - What is Attribute Based Access Control (ABAC)?
Similar to OWASP Chicago 2016 - What is Attribute Based Access Control (ABAC)? (20)
More from David Brossard
More from David Brossard (8)
Recently uploaded
Recently uploaded (20)
OWASP Chicago 2016 - What is Attribute Based Access Control (ABAC)?
- 1. What is Attribute Based Access Control? OWASP Chicago October 2016
- 2. © Axiomatics 2016 2 I know who you are…
- 3. © Axiomatics 2016 3 I know who you are… But how do I control what you want to do?
- 4. © Axiomatics 2016 4 A trip throughout the IT universe
- 5. © Axiomatics 2016 5
- 6. © Axiomatics 2016 6 Security
- 7. © Axiomatics 2016 7 Security IAM Identity & Access Management
- 8. © Axiomatics 2016 8 Security IAM EAM Externalized Authorization Management
- 9. © Axiomatics 2016 9 What is IAM? Access Management Identity Management Authentication Authorization User Management Central User Repository Identity & Access Management Providing the right people with the right access at the right time
- 10. © Axiomatics 2016 10 Overview of Existing Access Control Mechanisms
- 11. © Axiomatics 2016 11 Authentication (AuthN) username ******** Submit
- 12. © Axiomatics 2016 12 Authorization (AuthZ)
- 13. © Axiomatics 2016 13 Authorization (AuthZ) defined ⁃ Sometimes called Access Control ⁃ From a physical perspective (e.g. doors and locks) ⁃ Also known as (aka) ⁃ Externalized authorization ⁃ Dynamic authorization ⁃ Fine grained authorization ⁃ Entitlement management ⁃ “The function of specifying access rights to resources…*” ⁃ “To define an access policy*” ⁃ “Specifies what a subject can do*” * source: Wikipedia
- 14. © Axiomatics 2016 14 Legacy authorization models Access Control List • Named subjects or groups are directly associated with resource objects • File systems are a common example for the use of ACLs Group List • Common in LDAP directory systems and email services Role Based Access Control (RBAC) • Since 1992 • User Role Permission
- 15. © Axiomatics 2016 15 Role-Based Access Control & Limitations
- 16. © Axiomatics 2016 16 What is RBAC? ⁃ Role-based access control ⁃ Model formalized in 1992 by NIST ⁃ Access is granted via roles, instead of individual userID ⁃ A role is essentially a collection of permissions or entitlements Manager Senior Manager Admin Regional Manager Assistant IT Manager
- 17. © Axiomatics 2016 17 How does RBAC work? ⁃ Permissions are granted to each role based on requirements ⁃ Users are assigned to a specific role ⁃ Users can be also be assigned to multiple roles Permission Permission …
- 18. © Axiomatics 2016 18 Benefits of RBAC ⁃ Primarily used for administration-time access control ⁃ Gives administrators easier control of large user populations ⁃ Widespread and mature ⁃ Hierarchy of roles ⁃ Manager ⁃ US Manager ⁃ European Manager ⁃ Static segregation of duty ⁃ Purchaser role ⁃ Approver role
- 19. © Axiomatics 2016 19 RBAC was designed for a simpler world
- 20. © Axiomatics 2016 20 Limitations of RBAC ⁃ Role engineering ⁃ Determining the permissions roles will be assigned is time-consuming ⁃ Different business needs lead to new role hierarchies ⁃ RBAC requires attention all the time ⁃ In RBAC, the joiner-mover-leaver process is critical ⁃ Users can easily accumulate roles which leads to excess permissions ⁃ RBAC does not scale ⁃ Many organizations claim a 10-to-1 role-to-employee ratio This is the infamous role explosion
- 21. © Axiomatics 2016 21 Role Explosion
- 22. © Axiomatics 2016 22 RBAC – the Never Ending Sudoku… ⁃ Users ⁃ Roles ⁃ Permissions ⁃ Removing conflicting permissions from Role 1 and/or Role 2 may solve problem for user group 2 but create new problems for user group 1 and 3. SoD violation
- 23. © Axiomatics 2016 23 The Never Ending Sudoku cross-application SoD violation SoD violation SoD violation App 1 App 2
- 24. © Axiomatics 2016 24 RBAC is ego-centric ⁃ RBAC is self-centered ⁃ RBAC is mainly about who the user is ⁃ Identity-centric ⁃ RBAC doesn’t take into account other parameters ⁃ Object metadata ⁃ Actions ⁃ Environmental context ⁃ RBAC is not dynamic or context-aware ⁃ RBAC cannot cater to time, location, or risk
- 25. © Axiomatics 2016 25 RBAC is not paying attention… ⁃ RBAC is primarily implemented for admin-time access control ⁃ The user provisioning process ⁃ But also for access review and certification ⁃ For run-time access, RBAC has a limited role ⁃ Fine for simple use cases ⁃ In complex scenarios, the application must do the heavy lifting This is the infamous hard-coded access logic within applications
- 26. © Axiomatics 2016 26 Hundreds or thousands of if-clauses scattered all over your code… If project X is in planning phase then… else… If the user is member of project X then … else … If user is project lead then … else … If project X is in production phase then … else … If project X has been approved then … else …
- 27. © Axiomatics 2016 27 RBAC cannot handle relationships
- 28. © Axiomatics 2016 28 Why can’t RBAC handle relationships? ⁃ Example ⁃ Nurses can view medical records in their unit ⁃ Doctors can edit medical records of patients they are assigned to ⁃ How would one implement an assignment role? ⁃ Define a nurse_unit role? ⁃ Define the primary_physician role? ⁃ Does it scale? ⁃ How would one implement delegations? ⁃ Doctors can view medical records of patients assigned to other doctors for whom they are filling in for
- 29. © Axiomatics 2016 29 Is your access control broken?
- 30. © Axiomatics 2016 30 The Basic Elements of Attribute-Based Access Control
- 31. © Axiomatics 2016 31 Did you say ABAC? Externalized Centralized Policy Driven Attribute Based Standardized
- 32. 70% By 2020, 70 percent of enterprises will use ABAC as the dominant mechanism to protect critical assets, up from less than 5 percent today. Gartner, 2013 “ ”
- 33. © Axiomatics 2016 33 Policies Attributes
- 34. © Axiomatics 2016 34 Attributes are labels that describe anyone and anything
- 35. © Axiomatics 2016 35 Attributes are Multi-Dimensional Who What Where When Why How
- 36. © Axiomatics 2016 36 Attributes are Multi-Valued Department Department Sales EngineeringFinance Sales EngineeringFinance
- 37. © Axiomatics 2016 37 Policies bring attributes together to make it all work
- 38. © Axiomatics 2016 38 “Managers can view accounts in their region” “Customers can create transfers up to $1,000” “A user cannot approve a transfer they requested” “Tellers can view transactions in their own region”
- 39. © Axiomatics 2016 39 Policies Accessgrant deny&
- 40. © Axiomatics 2016 40 Policies that apply to a specific API or service Policies that apply across the enterprise / API sets Policies can be local or global
- 41. © Axiomatics 2016 41 Use ABAC to implement... Time-based policies “Deny access to the API outside office hours”
- 42. © Axiomatics 2016 42 Use ABAC to implement... Location-based policies “Cleveland players cannot hit a home run at Wrigley Field”
- 43. © Axiomatics 2016 43 Use ABAC to implement... Dynamic access control “Managers can view accounts that are in the same branch.”
- 44. © Axiomatics 2016 44 Use ABAC to implement... Dynamic Segregation of Duty “Employees cannot approve transactions they initiate.”
- 45. © Axiomatics 2016 45 Secure APIs start with ABAC... Any API Any Policy Any Attribute
- 46. © Axiomatics 2016 46 In ABAC, who gets to decide?
- 47. © Axiomatics 2016 47 Who gets to decide? User API I, Alice, want to view bank accounts Can Alice view account #123? Data
- 48. © Axiomatics 2016 48 The Guardian Angel
- 49. © Axiomatics 2016 49 Divide Responsibilities
- 50. © Axiomatics 2016 50 Authorization as Infrastructure User API I, Alice, want to view bank accounts Can Alice view account #123? Data APIGateway ABAC Authorization Service SQLProxy Which data can be retrieved?
- 51. © Axiomatics 2016 51 1.View record #123 6.View record #123 2. Can Alice view record #123? 5. Permit, Alice can view record #123 3. Evaluate policies Manage policies 4. Retrieve additional attributes ABAC Architecture
- 52. © Axiomatics 2016 52 ABAC, OASIS, NIST, & OWASP
- 53. © Axiomatics 2016 53 OASIS XACML – eXtensible Access Control Markup Language ⁃ Pronunciation ⁃ eXtensible Access Control Markup Language ⁃ OASIS standard ⁃ V 3.0 approved in January 2013 ⁃ V 1.0 approved in 2003 ⁃ XACML is expressed as ⁃ A specification document and ⁃ An XML schema ⁃ http://www.oasis-open.org/committees/xacml/
- 54. © Axiomatics 2016 54 What does OASIS XACML contain? XACML Reference Architecture Policy Language Request / Response Protocol
- 55. © Axiomatics 2016 55 ABAC research ⁃ NIST Special Publication 800-162 ⁃ Guide to ABAC Definition and Considerations ⁃ nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf ⁃ NIST Center of Excellence ⁃ Building blocks ⁃ Industry vertical projects ⁃ nccoe.nist.gov/
- 56. © Axiomatics 2016 56 HL7 - Health Level Seven International ⁃ The basis for healthcare interoperability ⁃ Defining common standards for structured content of healthcare data ⁃ Transport of that data between different systems ⁃ Applies to clinical and administrative data. ⁃ Founded in 1987 ⁃ One of the ANSI-accredited Standards Developing Organizations (SDOs) operating in health care ⁃ Widely adopted by vendors worldwide to define content. ⁃ HIPAA references several HL7 standards ⁃ HL7 has several workgroups including Security ⁃ Use Case: http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology
- 57. © Axiomatics 2016 57 ABAC & OWASP
Editor's Notes
- The IT landscape is a vast universe full of very different but connected galaxies. Think about it. You have the data galaxy, application galaxy, the web, log analysis, business processes, many more. And of course you have the Security galaxy. It is by no means a small galaxy. Far from it. It is vast, complex, and tricky to navigate.
- The universe The IT landscape is a vast universe full of very different but connected galaxies. Think about it. You have the data galaxy, application galaxy, the web, log analysis, business processes, many more. And of course you have the Security galaxy. It is by no means a small galaxy. Far from it. It is vast, complex, and tricky to navigate. Information security, sometimes shortened to InfoSec, is the practice of defending information from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction. It is a general term that can be used regardless of the form the data may take (e.g. electronic, physical). (source: Wikipedia) Security includes many different areas and specializations such as encryption, identity & access management, network security… Security addresses different concerns in different layers (think of the 7 ISO layers). Although the approach may be different due to technology (layer), the principles remain the same.
- The galaxy Let’s zoom in on a small galaxy (the “Milky Way”) high up there in the corner. Welcome to Identity & Access Management. Identity and access management (IAM) is the security discipline that enables the right individuals to access the right resources at the right times for the right reasons. IAM addresses the mission-critical need to ensure appropriate access to resources across increasingly heterogeneous technology environments, and to meet increasingly rigorous compliance requirements. This security practice is a crucial undertaking for any enterprise. It is increasingly business-aligned, and it requires business skills, not just technical expertise. Enterprises that develop mature IAM capabilities can reduce their identity management costs and, more importantly, become significantly more agile in supporting new business initiatives. Source: Gartner (http://www.gartner.com/it-glossary/identity-and-access-management-iam/)
- The Solar System Let’s jump straight into the Milky Way and continue on our journey. Welcome to the Solar System! EAM – Externalized Authorization Management – is a smaller area within the IAM space. It deals specifically with authorization or access control. And even more specifically authorization that has been decoupled from and removed from the applications themselves hence the name “externalized”. Gartner uses the term EAM while other firms e.g. Kuppinger Cole refer to Dynamic Authorization Management (DAM). Here are some useful references: EAM at Gartner: https://www.gartner.com/doc/2358815/technology-overview-externalized-authorization-management DAM at Kuppinger Cole: https://www.kuppingercole.com/report/leadershipcompass_damgw709664614
- What is an IAM Framework? Authentication Authentication is the area through which a user provides sufficient credentials to gain initial access to an application system or a particular resource. Once a user is authenticated, a session is created and referred during the interaction between the user and the application system until the user logs off or the session is terminated by other means (e.g. timeout). It usually comes with a password service module when the user ID /password authentication method is used. By centrally maintaining the session of a user, it provides Single-Sign-On service so that the user needs not logon again on accessing another application system or resource governed under the same IAM Framework. Authorization Authorization is the area that determines whether a user is permitted to access a particular resource. Authorization is performed by checking the resource access request, typically in the form of an URL in web-based application, against authorization policies that are stored in an IAM policy store. Authorization is the core area that implements role-based access control. Moreover, the authorization model could provide complex access controls based on data or information or policies including user attributes, user roles /groups, actions taken, access channels, time, resources requested, external data and business rules. User Management This area comprises of user management, password management, role/ group management and user /group provisioning. It defines the set of administrative functions such as identity creation, propagation, and maintenance of user identity and privileges. One of its components is user life cycle management that enables an enterprise to manage the lifespan of a user account, from the initial stage of provisioning to the final stage of de-provisioning. Some of the user management functions should be centralized while others should be delegated to end users. Delegated administration allows an enterprise to directly distribute workload to user departmental units. Delegation can also improve the accuracy of system data by assigning the responsibility of updates to persons closest to the situation and information. Self-service is another key concept within user management. Through self-profile management service an enterprise benefits from timely update and accurate maintenance of identity data. Another popular self-service function is self-password reset, which significantly alleviates the help desk workload to handle password reset requests. User management requires an integrated workflow capability to approve some user actions such as user account provisioning and de-provisioning. Central User Repository Central User Repository stores and delivers identity information to other services, and provides service to verify credentials submitted from clients. The Central User Repository presents an aggregate or logical view of identities of an enterprise. Directory services adopting LDAPv3 standards have become the dominant technology for Central User Repository. Both meta-directory and virtual directory can be used to manage disparate identity data from different user repositories of applications and systems. A meta-directory typically provides an aggregate set of identity data by merging data from different identity sources into a meta-set. It usually comes with a 2-way data synchronization service to keep the data in synchronization with other identity sources. A virtual directory delivers a unified LDAP view of consolidated identity information, and multiple databases containing different sets of users are combined in real time behind the scene. Source: Hong Kong Polytechnic University (http://www.polyu.edu.hk/ags/Newsletter/news0911/IAM_details.html)
- Now that you expose data more openly, you need to watch out for those gaps, those holes in the system. Either you lock everything down and you make sure only the relevant clients or individuals get access to the right data or you open up fully. Do you bake the access control inside the API itself? Do you for instance implement methods such as getMyProfile()? How do you make sure your API is secure but also future-proof and flexible enough to adapt to future needs? How do you make sure your API complies with national and international regulations?
- ABAC or Attribute-Based Access Control is the new authorization model flexible enough to secure your APIs, applications, and data stores all in one go, from one central place, in a consistent manner. ABAC is a NIST-backed initiative. XACML is the standard implementation for ABAC
- Two first-class citizens in ABAC: policies and attributes
- Attributes are key-value pairs. They can be used to describe anything and anyone. Attributes can be multi-valued. For instance citizenship = ‘Swedish’ and ‘Norwegian’. Attributes can be typed. An attribute could be a string, a number, a boolean, or a date. For instance: dateOfBirth isActive Balance In this example, the bottle could be described with the following attributes: Content Owner Volume Distributor… Attributes alone though are not enough. We need something to bring the attributes all together. We need a bit of chemistry.
- Attributes can relate to who, what, where, when, why, and how. Attributes cover all the grammatical functions of a sentence: the subject (who), the verb (what action), the object (what resource), and the contextual information (why, how, when, where…) Attributes can be sourced from multiple locations: databases, other APIs, the API message itself, authentication tokens (SAML, JWT…)
- Attributes can relate to who, what, where, when, why, and how. Attributes cover all the grammatical functions of a sentence: the subject (who), the verb (what action), the object (what resource), and the contextual information (why, how, when, where…) Attributes can be sourced from multiple locations: databases, other APIs, the API message itself, authentication tokens (SAML, JWT…)
- Policies are like the natural language Attributes are like the vocabulary Use policies to bind attributes together to create the authorization spark. Use policies to combine attributes and determine whether access should be granted or denied.
- Examples
- Policies can grant access… and deny access
- Policies can grant access… and deny access
- Dynamic access control that is applied on the fly based on the context of the interaction. Location and time as previously seen but also relationship: does the user own the data? Have a relationship to the data?
- Dynamic access control that is applied on the fly based on the context of the interaction. Location and time as previously seen but also relationship: does the user own the data? Have a relationship to the data?
- One of the main challenges when building APIs, business layers, applications, and data stores is that it is unclear where authorization decisions should be made and by whom. Should developers implement the logic? If so, where? As SQL statements? As logic inside a business process? Inside the application’s logic itself? Or within the API? What if we have different ways of consuming the same data sets? Does this require implementing different logic in different places? And how do I get a good overview of what is allowed, what isn’t? How do I prove I am compliant?
- Let’s look at a flow. Imagine a user Alice on the left-hand side trying to access data via an API on the right-hand side. Who gets to decide whether the call should be allowed? The API can handle authentication and basic authorization e.g. OAuth scopes. But what about finer-grained authorization? Who does the data belong to?
- We’ve heard many names for that component. And yes we’ve even heard Guardian Angel. This is the component you query in order to get a decision, an authorization decision. Can I do this? Yes, you can. No you cannot. The Guardian Angel is the one central point of decision making you go to in the enterprise for decisions. It is the same central point no matter the layer you are in, no matter the technology. It knows it all.
- Divide Responsibilities: API gateways are the muscles that enforce the decisions returned by the Brains. The Guardian Angel enables loose coupling and separation of concern between business logic and authorization logic. Much like you delegate authentication, logging, and other non-functional aspects of your app to infrastructure, so should you for authorization. In doing so, you will have 2 pieces: The brains – this is the part the Guardian Angel plays The muscles – this is the piece that enforce whatever the Guardian Angel says. In real life, the Guardian Angel is a bit like the judiciary system of a country and the police force plays the role of enforcement
- Let’s look at a flow. Imagine a user Alice on the left-hand side trying to access data via an API on the right-hand side. Who gets to decide whether the call should be allowed? The API can handle authentication and basic authorization e.g. OAuth scopes. But what about finer-grained authorization? Who does the data belong to?