A Basic ABAC (Attribute Based Access Control) Primer
What is ABAC?
Attribute Based Access Control is an effort to shift the paradigm of granting resource access to a specific user to granting access based on the value of a user’s attributes. While user authentication is still required the access is no longer granted via a specific ACL. Instead at the point of authentication a decision is made based on the value of specific attributes whether or not access should be granted.
This approach significantly decreases the administration required to maintain data security. It also ensures that data is available real time to those who need it and are authorized to view/use it. No longer are provisioning request required in order to gain access to the data since access is evaluated and granted real time.
ABAC provides particular advantages when it is deployed in a Federated environment. Access is determined by the agreement between the two entities (business, organizations, governments, etc…) and then is enforced by the Policy Enforcement Point (PEP) at the time of access. Each entity maintains autonomous control of their identities.
For the public and private sector, the policies, the attributes, and metadata need to be defined to ensure seamless operation and protect information assets. This allows the enterprise to leverage attributes, metadata, and digital policies to secure access to resources in a flexible and robust decision and enforcement mechanism. ABAC enables the transition away from access control based solely on identity through evaluating and enforcing policies by leveraging enterprise sources of access control policies, attributes, and data in support of dynamic operating environments.
Why ABAC Matters
ABAC can facilitate secure information sharing by providing a greater emphasis on leveraging policies, attributes, and metadata to allow access to information in a controlled manner. Think RBAC (role Based Access Control) down to a fine-grained level through access control decisions and enforcement with interfaces for certificate validation, policy retrieval, and attribute retrieval.
Using ABAC, digital policies are defined and managed by policy administrators to protect specific resources. By doing so the decision and enforcement rules can be removed from the systems administrator layer of the enterprise and into the control and governance branch of enterprise.
The policies can then be derived from compliance and information assurance regulations defined by HIPAA, Sarbanes-Oxley, FERC, HSPDs, etc. ABAC thus enables a flexible means of securely sharing and protecting information through the enforcement of policies applicable to specific resources.
Access to information will then be governed by policies that can be rapidly created, modified, and consumed by IT systems. The policies will define the rules and conditions under which someone is authorized for access by using user characteristics, or attributes, and resource characteristics, or metadata, as opposed to membership to a resource ACL.
|Policy Enforcement Point (PEP)||The PEP, similar to a Policy Agent or Webgate (for you SSO folks out there) intercepts user requests to resources and enforces access control decisions. The PEP’s main function is to grant or deny user access to the resource and enforce workflow obligations or constraints on the interaction. The PEP can also support user authentication, by checking the status of a user’s credentials and verifying authentication assertions.|
|Policy Decision Service (PDS)||The primary function of the PDS is to render an access control decision based on a policy. This is calculated through access control decisions based on the security context of the interaction between the user and the application or resource being protected. The security context is comprised of access control parameters including policies, user attributes, resource metadata, and environment attributes. The PDS can retrieve the access control parameters from sources at various levels of the enterprise to render a decision.|
|Policy Service (PS)||The PS retrieves access control policies from a policy store. Typically, the PDS will use the PS to request the applicable policies pertaining to the security context of a transaction. Rules typically are utilized in a collection, known as Policies to be called up by the PS. If you can build a basic IF, THEN, ELSE statement then you can build rules for your policies.|
|Attribute Service (AS)||The AS retrieves user information from an attribute store. The AS retrieves user information associated with a user from variety of authoritative identity stores including, but not limited to, LDAP and database stores.|
The only thing I left out is a Policy Administration Point (PAP). Essentially an interface to create and maintain Policies. This can reside on a separate server or client machine depending on vendor. In certain cases, the PAP is nothing more than an XML editor.
Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.
Tags: ABAC, AS, Attribute Based Access Control, Attribute Service, Attribute Store, Axiomatics, Bitkoo, Cisco, Epok, Jericho Systems, Keystone, Layer 7, NextLabs, Oracle Entitlements Server, PAP, PBAC, PDP, PDS, PEP, Pericore, Policy Based Access Control, Policy Decision Point, Policy Decision Service, Policy Enforcement Point, Policy Service, Policy Store, PS, Quest, Rossin, Siemens, Todd, Todd Rossin, Vordel, XACML