Attribute Based Access Control matches attributes of a person requesting access as well as attributes of the resources being requested against a policy

Is ABAC a better method for secure info sharing?

Access control, the chore of deciding who can get access to digital resources and then enforcing those decisions, can be a challenging task in large organizations and becomes even more daunting when information must be shared across agency lines.

The Federal CIO Council has identified a scheme called Attribute Based Access Control (ABAC) to promote information sharing, but implementing ABAC can be complex. The National Institute of Standards and Technology has released draft guidelines for implementing this method of access control.

ABAC matches attributes of a person requesting access, as well as attributes of the resources being requested, against a policy that defines who is allowed to receive access and under what conditions. The scheme was first outlined in the OASIS Extensible Access Control Markup Language in 2003, but without a formal definition and implementation guidance, ABAC solutions were developed and deployed without a common set of requirements.

NIST’s draft Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, addresses that problem.

“Despite the clear guidance to implement ABAC, to date there has not been a comprehensive effort to formally define or guide the implementation of ABAC within the Federal Government,” the NIST report says. “This document brings together many previously separate bodies of ABAC knowledge in order to bridge gaps between available technology and best practice ABAC implementations.”

The call to use ABAC came in Version 2 of the CIO Council’s Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, published in 2011.

SP 800-162 provides a definition of ABAC and a description of its functional components, along with planning, design, implementation and operational considerations for employing it within a large enterprise. Under the scheme, the owner of the resources being protected assigns attributes to each object and creates rules for what attributes in a user will allow access. This allows use of detailed access control policies without prior knowledge of the person requesting access and for an unlimited number of subjects that might require access.

Attributes can include such things as a person’s name, affiliation, clearance level, Social Security number or eye color, and together these attributes create a persona tied to a job. There can be different personas for different jobs (such as a Monday-Friday job and a weekend job), the report says. A subset of attributes can be held in a credential or token that can be used for authentication.

NIST calls a person’s attributes subject attributes, because objects, such as a remote automated device, also can have attributes.

But actually deploying the system is not easy, NIST says. “When deployed across an enterprise for the purposes of increasing information sharing between diverse organizations, ABAC implementations become much more complex — relying on the existence of extensive attribute management infrastructures, machine readable policy ontologies and interoperable access control mechanisms deployed to uniquely diverse networks.”

The report offers a set of principles for implementing ABAC:

  • Establish the business case for ABAC implementation. What are the costs and risks of developing/acquiring new capabilities and transitioning away from old capabilities?
  • Understand the operational requirements and overall enterprise architecture. What objects will be exposed for sharing? How will subject attributes be shared and how will object attributes be used? What are the access control rules, and how are they captured, evaluated and enforced?
  • Establish or refine business processes to support ABAC.
  • Develop and acquire an interoperable set of capabilities. How are subject attribute capabilities integrated with identity management capabilities? How are diverse or special needs for identities handled? How are subject attributes shared and maintained?
  • Operate efficiently. How are subject attributes managed for disconnected and disadvantaged users? Are interface specifications available for new participants? How is quality and timeliness of data measured and enforced? How is liability for data loss or misuse of data managed?

Comments on the draft guidelines should be sent May 31 to vincent.hu@nist.gov with "Comments SP 800-162" in the subject line.

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above