ABAC – Attributed Based Access Control

From IIW

ABAC – Attributed Based Access Control


Thursday 1G Convener: Don McNeece

Notes-taker(s): Susan Carevic

Tags for the session - technology discussed/ideas considered: Role Based Access Management, Attribute Based Access Manager, RBAC, ABAC


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: The question first came up of what is an attribute? Is it a role? Or any value associated with the user

Example Scenario was presented:

  • Role based Access Control (RBAC): Roles/groups set up. User wants access to a resource. Typically, roles or groups are created for the resource to look at. Person belongs to Employee can view HR information.
  • Process runs nightly to take attributes from a database and assign persons into roles based on their attributes.

Attribute Based Access Control:

Challenges:

  • Agreeing on attributes and deciding what they mean across organizations is one of the most challenging parts.
    • One way: associate the role with a function: each role as an assembly with functions as opposed to membership.
  • Role sprawl is the problem.

Attribute Characteristics in scenario:

  • don’t have to do with role, these could be contextual, such as time/location..
  • Contextual information
  • Authority
  • Entitlement
  • Applies to people and not devices.
  • Attributes can negate rights as well as grant

Goal:

  • What do I need to know about someone for them to be able to do X.
  • Minimum set of data to be able to resolve the person..
  • Need to figure out how to map attributes to privileges.

Problems with Roles (RBAC):

  • assumption that there is a top down entity that can figure out what people need. Role explosion
  • Delays
  • Permissions to attributes (applications don’t have access to attributes)
  • Mapping attributes to permissions
  • Reduced visibility: nothing ties to group name what people in the group are necessarily allowed to do.
  • Roles invariably overprovision employees. They will most likely receive resources they don’t need.
  • Roles: name means different things.. imprecise.

ABAC:

  • Policy
  • Common Words\definitions
  • Could lead to an “attribute explosion”
  • Applications need to be able to understand the attributes and API of applications.

Policy:

  • Trying to find a policy: does this person have permission to do this type of action.
  • Policy explains what attributes are needed to be able to do it.
  • So each set of attributes are associated with a policy.
  • Each set combined is effectively a role.

Some terms and definitions:

  • Role: collection of permissions
  • Groups: collection of users
  • Roles can be attributes
  • JWT pronounced “JOTS”

Advantage of ABAC over Roles:

Roles have “combinatoric” explosion problem. Set of attributes don’t have to be thought of as a role. When people change jobs, they get assigned to a different set of roles..eventually, attributes need to be changed.

Recommendations:

  • Delink to HR database. So that access can be based on relationships in the moment.
  • Approach Alan prefers: Use your attributes roles identities to get a set of access tokens. Send the access tokens along with the request, so that the service is free from having to figure out the attribute compilations.
    • Example: Navy Ship: policy calculation on shore, and sent back to ship. Use OAuth, go to AR for access tokens and use for access decision. Access token needs to include what the token is good for/what kind of requests. Only piece to add are the contextual pieces. .. doesn’t work for dynamic roles – in this case every RS becomes an AS.

IIW21 TH 1G ABAC Attributed Based Access Cont 1.jpg

Retrieved from "https://iiw.idcommons.net/index.php?title=ABAC_–_Attributed_Based_Access_Control&oldid=20295"