Internet: a world without perimeters

Which is one of the greatest challenges for companies today? Probably it's the disappearing perimeter of their computing network.  No longer is access to the corporate network constrained to a limited number of employees.  Instead, access to corporate information and services extends to anybody that has access to the Internet.  Because of this reason many corporations are opening up their systems to customers, business partners and service providers to enable self servicing models that provide economic benefits and enable choice.

When the word "privacy" has a new mean

Along with, and arguably, caused by this expanding network are growing privacy concerns.  Privacy legislation in both the health care and the financial industries has never been more active.  This legislation is requiring corporations to implement tighter controls over access to customer information.  Privacy introduces the element of choice, where true data owners have a voice in how their data is used.

In this page we will discuss the concepts of authorization across the Enterprise and present the new challenges of access control in today’s environment.  As more and more information resources are made available to an ever-increasing number of entities, traditional access control methods are becoming unmanageable.

Many great firms, as American Express , are also moving to split large applications into small, loosely coupled, self-contained components.  These components allow applications to be assembled more rapidly and are easier to manage than their monolithic predecessors.  They can also be shared with other components either within the enterprise or across organizational boundaries.  This has presented a new problem for securing applications.  No longer must an entity identify itself to a single application.  In a component-based architecture, a security context must be passed along to all components that are invoked during the execution of a transaction.

The other driving factor in these companies is the requirement to componentize security services so they are reusable, including Identity Management, authentication and authorization.  This requirement will reduce the overhead and maintenance required by current systems with disparate security systems and unmanageable security policies.  These services will be exposed to applications and users for consumption.

Authorization Overview

One of the most important requirement of any secure application is to provide controlled access to its resources. The access control is a mechanism that is used to limit access to only trusted entities that have a business need to use a particular resource. That thing can guarantee a control access that will help ensure the confidentiality, integrity, and availability of the application resources.

• Confidentiality ensures that information is disclosed only to authorized individuals. Authorized individuals are determined based upon company policy, regulations, and the principle of need-to-know. The principle of need-to-know is a concept where access to information is granted only when it is required to complete a job duty or task.

• Integrity protects resources from unauthorized modification whether those modifications are accidental or malicious. One safeguard for protecting integrity is the use of the least-privileged principle. The least-privileged principle ensures that users only have the necessary permissions to perform their job duties and nothing more.

• Availability ensures that system resources are accessible when needed and by those who need them.

There are various forms of access control. Some methods restrict physical access to resources while other methods implement administrative procedures. This paper describes authorization which is a logical method implemented in software. Authorization is the act of granting a subject access to an object. A subject refers to an entity with a known identity to the security domain and an object refers to any protected resource within the control of the security domain. A prerequisite of an authorization decision is the identification and authentication of the user that is attempting access . For additional information about authentication, refer to the Authentication Whitepaper.

Another prerequisite to performing an authorization decision is defining the security policy. A security policy defines the rules of the company regarding access privileges and these rules represent the policies and practices of the organization as well as the laws and regulations by which the organization must abide.

Managing access to resources refers to the process of defining a policy, implementing a policy, and enforcing that policy.

Using Anderson’s conceptual model, an authorization system consists of a security policy and a reference monitor (RF) .  The security policy contains the rules that grant or deny access to the organization’s resources.  The reference monitor is responsible for monitoring access to objects by subjects.  Access to objects is granted by going through the reference monitor.

The RF is responsible for enforcing the security policy and auditing all access attempts whether successful or not.  The audit information should be committed to persistent storage prior to allowing access to ensure that no access is allowed until a permanent audit record has been created.  To enforce accountability, audit information should include, but not be limited to, the following:

  • Date and time of access
  • Subject name
  • Object name
  • Access type (read, update, etc)
  • Outcome of access (success, or failure)
SOD1
sod2

Traditionally, audit information includes the subject as it is known by the local security domain.  In today’s world, the identity of the subject may not be known to the security domain that is enforcing the policy.

Instead, all that may be known about the subject are attributes needed to determine whether access is allowed.  In this case, the audit information must include a linkage back to the identity system that provided the attributes about the subject.

Logically, the reference monitor consists of a component that determines if access is allowed and a component that enforces the decision.  These components are called the policy decision point (PDP) and the policy enforcement point (PEP), respectively.

In this image, the PEP receives the initial resource request but relies on the PDP to evaluate whether the request should be fulfilled or not. The PEP supplies subject, object and operation data about the request to the PDP, which finds a corresponding policy and applies that logic to evaluate whether access should be granted or denied. The answer is sent back to the PEP, at which point the necessary action can be taken.

Determining Access

Determining whether access is granted can be based on discretion of the security administrator or it can be unavoidably imposed by the security system. Discretionary and non-discretionary access control methods are two distinct methods of determining access.

Discretionary Access Control

The most common type of access control is discretionary access control (DAC). With DAC, access to objects is granted explicitly by name. A name can be either a subject or a group of subjects. The primary distinction of DAC is that access is granted at the discretion of persons in charge of implementing the access control policy. Persons can be either the owner of the resources or the custodian of the resources.

In DAC, subjects are given explicit access to resources by entering privileges into an access control matrix (ACM).  The ACM consists of rows of subjects and columns of objects.  Entries within the matrix specify the type of access that is allowed.

The ACM is usually not implemented as such since it tends to be very sparse when a subject is not granted access to an object.  Instead, Access Control Lists (ACLs) are commonly implemented.  An ACL corresponds to a column in the matrix.  The list specifies the subjects that are permitted access and the type of access that is allowed.  When an access attempt is made, the reference monitor looks for the subject in the ACL and determines whether access is permitted.

The ACM can also be implemented using a capability list.  A capability list corresponds to a row in the access matrix.  During an access attempt, the reference monitor checks the capability list to determine if the object that is being accessed is included in the subject’s capability list.DAC allows for fine granularity when defining access control policies since access can be controlled on a “subject-by-subject” or “object-by-object” basis.  This, however, is also one of its weaknesses.  Managing access control policies on an individual basis can quickly become a tedious process when there are millions of subjects and objects.  In addition, when a subject’s duties change, revocation of permissions is not always obvious.

Non-Discretionary Access Control

Most access control policies can be described based on characteristics of the subject or the object being accessed.  For example, “allow all managers access to payroll information” is a policy based upon a characteristic of the subject (subjects that are managers) and the object (objects pertaining to payroll information).Implementing this same policy with DAC requires that the security administrator first identify all subjects that are “managers” and then grant those subjects explicit access to all “payroll information” objects.  This type of implementation requires constant maintenance of the access control policies subject change job titles and resources are added and deleted.
Instead, non-discretionary access control (NDAC) policies are defined based on attributes that describe the subject or object. NDAC imposes the security policy on all subjects of the system because the authorization decision is based only on these attributes. Data owners and custodians cannot selectively assign permissions on a subject-by-subject basis as permitted with DAC.

Often, a combination of a number of different factors must be taken into consideration when determining permissions. Such factors could include:

Attribute(s) of the subject

  • Role
  • Clearance level
  • Organization
  • Age

Attribute(s) of the object

  • Content
  • Classification

Relationship between the subject and the object

  • Object’s owner
  • Object’s creator

Relationship between the subject and another subject that has a relationship to the object

  • Advisor to the owner of the account
  • Parent to the viewer of a movie

Request context

  • Request submitter
  • Trading password
  • Origin of request (IP address)
  • Type of connection
  • Time of day

Historical context

  • Failed access attempts
  • Successful access attempts
  • Other materials already accessed

Attributes of the Subject

Many times access is dependent on some characteristic of the subject.  For example, implementing a policy that states “allow access if the subject is a band 35 or higher” is a policy that is dependent on something about the subject, specifically, the band level.  Defining policies based on subject attributes allows policy definitions to be more concise.  Instead of granting explicit access to every subject that is band 35 or higher (as with DAC), one policy statement can be made.  This also reduces the maintenance necessary as employees move between bands.

An important aspect of this example is that the policy really does not care to know the true identity of the subject.  An evaluation system that implements this policy only needs to ascertain the band level of the subject from a trusted source.  This is a departure from typical authorization implementations where the security system maintains all attributes of the subject on which authorization decisions rely.

The implementation of a subject-object relationship policy usually depends on some business relationship that is usually stored in the application.  The relationship can also be stored in the security system however this requires a duplication of the relationship and forces a synchronization process that is redundant, costly, and prone to error.  Edelen’s Adaptive Architecture Security Strategy and Design Patterns describes the concept of a dynamic role.  Dynamic roles are determined by business components based on the relationship between the subject and the object.  Business components are responsible for returning a dynamic role to the authorization system based on the object that the subject is attempting to access.  The use of dynamic roles allows complex relationships to be managed by business components while keeping the authorization policy central

While it may be tempting to implement access control policies based on numerous subject attributes, policies should strive to base the policy on a minimal of attributes; ideally, a singular subject attribute such as role.  Roles provide consistency in defining the security policy and are becoming the accepted method of describing access rights in security aware applications.

Attributes of the Object

Some access control policies are based on the content or context of the resource that is being accessed.  By using object attributes, policies can be implemented based on a grouping of objects.  For example, “Bob is allowed access to all proprietary information” requires that the access control system know something about the object.  In this example, the object attribute classification can be used to determine access rights.  Another example of object attributes combined with RBAC is the policy “Allow all MYCA CSRs the ability to reset any user id that has the MYCA service.”  In this case, the policy depends on both the subject’s attribute (CSR’s role) and the object’s attribute (services of the user.)

Access policies can often be described based on a relationship between the subject and the object.  For example, the statement “allow every cardholder access to view their card balance” is a concise definition of a security policy.  The same policy could be implemented with DAC using several million statements:

 

  • “allow Bob to view the card balance for card 3746 123456 01001”
  • “allow Alice to view the transaction history for card 3782 123456 01001”
  • “allow Elaine to perform any action on card “3731 123456 01001”

This is not a very efficient implementation since it requires constant maintenance of the security policy.  It is also possible that the true intent of the security policy is missed.  What happens if Alice is granted access to the wrong card? If Alice is issued a new card, she must wait until someone or some process adds her card to the ACL. Instead, the real security policy depends on a relationship between the subject and the object.  In this example, the security policy represents the relationship between Alice and the card balance for card 3782 123456 01001.

Subject-Subject-Object Relationship

Sometimes the relationship between the subject and object is not direct.  The policy “Allow a customer’s broker to execute trades on the customer’s behalf” is an example where the subject (broker) does not have a direct relationship with the object (customer’s brokerage account).  Instead, the broker has a relationship to the customer (he is the customer’s broker) and the customer has the relationship to the object (he is the owner of the account).  It is by this indirect relationship that access is granted.

sod3

It is also possible that the subject-to-subject relationship is not direct. Consider the case where the broker’s assistant (Para-planner) requires limited access to the customer’s account. The policy could be stated as “allow the broker’s Para-planner to view the account balances of all of the broker’s customers.

sod4

These types of relationship policies can be enforced using DAC however the policy cannot be stated in a concise manner.  For example, all Para-planners can be given explicit access to the accounts that they service at the discretion of the policy administrator.  However, when customers switch brokers or Para-planners are assigned to different brokers, the security policy must be modified to reflect these changes.  It is important to point out that while relationship-based access control can be very powerful, it can also be extremely inefficient if relationships are not implemented in an efficient manner.  It is assumed that applications implement an appropriate amount of denormalization of these relationships to provide efficient access for both business and security components.

Delegated 

Delegation is the act of passing on one’s access rights to another subject.  The subject could be another user of the system or a process that acts on the user’s behalf.  Delegation is the specific case of a subject-to-subject relationship.  For example, “Bob is allowed to send emails on behalf of Alice while she is away on vacation” creates a relationship between Alice and Bob.  Bob is Alice’s delegate while she is away on vacation.

The permissions that are passed can be either temporary or indefinite.  The delegator reserves the right to revoke the access permissions at any time.  The rights can also be delegated temporarily and then automatically revoked by the system or the applications at a specific date or after a specified period.  Since delegation encompasses assignment of a task, a job function, an application, or an entire identity, and can be context-based, the information relevant to delegation, including the context, would be an inherent part of the Identity Management system.

Delegated permissions are granted at the discretion of subjects that already possess the permissions to be delegated.  A subject must not be allowed to delegate permissions that they do not already have.

The right to delegate must also be controlled.  The policy should specify the subjects that are allowed to perform delegation as well as the permissions that can be delegated.  The policy should also specify the level of delegation that is permitted.  For example, if Alice delegates her email functions to Bob, can Bob in turn delegate those permissions to Bill? Delegation that is performed at the discretion of a user is not as simple as defining a relationship between a delegator and a delegatee.  Consider the case where Bob delegates his email functions to Alice.  Bob wants to grant Alice the right to read his email and calendar but Alice is prohibited from sending emails on Bob’s behalf or updating his calendar.  In this case, the access control system must maintain the rules that Bob has defined.  These rules may be different than the delegation rules that other users in the system decide to use.  In the case of discretionary delegation, concise security policies using relationships no longer apply.  Instead, discretionary access control policies must be implemented.

Request Context

Many access control policies take into account the context of the request.  Policies that enforce time and origin restrictions are examples of these types of policies.  For example, “brokerage trades can only occur during trading hours” imposes a time restriction.  Examples of origin restrictions are “security policies can only be administered from IP address 10.70.5.5.” or “the request must occur over a connection providing confidentiality.”  These types of policies ensure that the request originates from a secure location or over a secure connection. Another example of request context is a policy that requires a password to be submitted along with the request.  In this case, an attribute on the request must be compared to an attribute of the subject.

Historical Contest

Access control policies can also be based on events that have already transpired.  One example of this type of policy is known as the Chinese Wall of Security This policy attempts to prevent conflicts of interest by restricting access to information based on what the subject has already viewed.  This policy is implemented by classifying information into conflict-of-interest categories.  Once a subject has viewed information in a particular class, a “wall” is built around all other information in the same class.  The subject is forever forbidden from viewing information of the same class.  This type of policy is usually implemented at consulting firms where employees are restricted from viewing similar information from different companies.Another example of using historical context is during the enforcement of a dynamic separation of duty policy.  Some policies prohibit the same subject from system must take into account historical events that occurred on a transaction.  Dynamic separation of duty (DSD) is described in greater detail in the next section.

Discretionary Access Control provides a great deal of flexibility in defining access control policies however the administration of these policies often becomes a great burden to manage.  Role-Based Access Control (RBAC) is an attempt to alleviate this burden.

RBAC

The basic concept of RBAC is that subjects are assigned to roles and subjects acquire permissions by being members of roles (Figure 6.)  A role can represent either the subject’s placement within the organization (e.g., President, Vice President, Director) or the subject’s functional responsibilities (e.g., Programmer, Office Clerk, Payment Approver).  Implementation of roles will reduce the administration of policies (provided that there are fewer roles than subjects) because subjects can now be aggregated by role for policy definition.  With DAC, an entry in the ACM must be made for every subject requiring access to an object.  For example, if a job function required the assignment of ten permissions, the total number of entries in the ACM would be ten multiplied by the number of subjects.)  With RBAC, the same policy could be accomplished by assigning the ten permissions to a role.  As subjects require access, only one subject-role assignment is necessary.  More formally, the complexity of assigning privileges with DAC can be represented by the mathematical equation of O(S * O).  As for RBAC, the complexity is O(S * R) + O(R * O) where S is the subject, R is the role and O is the object.

RBAC can also be used to implement a separation of duty policy.  Separation of duty is a security concept that splits business operations into separate tasks so that one individual is not allowed to complete the business operation alone.  For example, it is not desirable to grant privileges of expense submitter and expense approver to the same person.  Assigning both capabilities to the same individual can lead to conflicts of interest when approvers are allowed to approve their own expense reports, reducing the assurance of data integrity.  To enforce separation of duty, some implementations of RBAC restrict which roles can be activated at the same time or for a given transaction.

sod5

Many vendor products now include support for RBAC however there currently is no consensus as to what features RBAC enabled systems are required to support. Ferraiolo and Sandhu et al have submitted a standard for RBAC to the National Institute of Standards and Technology. This proposal defines the core components of RBAC along with function specifications. The core components of the NIST standard are specified in the following sections.

Core RBAC

Core RBAC defines the requirements of user-role and permission-role assignment. These relationships can be many-to-many, i.e., a user can be assigned to more than one role and a single role can have many users. In addition, a permission can be assigned to many roles and a role can be assigned many permissions. Permissions represent the operations that can be performed on objects. Core RBAC also requires functionality for reviewing user-role assignments. While not required by core RBAC, reviewing role-permission assignments in addition to the user-role assignment may be useful in determining the rights associated to a role. Core RBAC also includes the notion of a session. Sessions allow selective activation and deactivation of roles at the discretion of the user. When a session is activated, a subset of the roles assigned to the user becomes the active role set. The user acquires the permissions of all roles within the active role set. The active role set can include all roles that the user is a member of or a subset of these roles however the implementation must allow a user to simultaneously exercise permissions from multiple roles. Error! Reference source not found. depicts the relation between users, roles and the user’s session. It also depicts the relationship between a role and a set of permissions (PRMS). In this diagram, a permission is represented as a relationship between an operation and an object.

sod6

The concept of role activation helps enforce the least-privileged principle.  This ensures that the user has no more access than is required to perform a specific task.  A user may be allowed to carry out additional functions by activating another role but is restricted to the privileges allowed by the active role set.  This can help protect against unintended actions by the user.  Core RBAC essentially specifies the functionality that can be obtained using traditional group-based access control where groups are analogous to roles.  Users are assigned to roles by being a member of a group.  Access (privilege) is then assigned by group.  To support core RBAC, users must be allowed to be members of more than one group simultaneously.

RBAC and Hierarchies

Many times the same permissions must be assigned to more than one role.  This is often the result of the natural hierarchy of an organization.  For example, a supervisor must be allowed to perform the same duties as the personnel for which they are responsible.  In addition, the supervisor is allowed to perform additional duties such as payroll administration.  It would be inefficient and possibly lead to inconsistencies in the policy to duplicate the common privileges for the supervisor when a role has already been defined.  Role hierarchies allow roles to inherit the permissions of other roles.

sod7

MAC

RBAC can be used to implement separation of duty policies.  With separation of duty, users are prevented from assuming simultaneous membership in roles where conflicts of interest could arise.  Static Separation of Duty (SSD) enforces the constraint at the time a user is assigned to the role.  The NIST proposal suggests using a {role-set, n} pair to restrict role assignment.  The role-set contains roles where conflicts could arise and n represents the number of roles from the set that could be assigned at the same time.  This allows for the implementation of policies where a user is allowed to take on two out of three conflicting roles but is prevented from taking on all roles in the set.

The Bell-Lapadula Model (BLM) requires that a subject’s clearance must be equal to or greater than the security level of the object being read (read-down).  A subject is also prevented from writing to objects classified at lower levels but may write to objects at the same or higher levels than their own.  In this model, information tends to flow to higher levels.  The intention of BLM is to maintain the confidentiality of the information. The Biba model is the logical conjugate of the BLM model.  This model is intended to protect the integrity of the data.  Biba uses the same mechanisms for controlling access however the relationship is inverted.  Subjects are permitted to read objects at higher levels but they are not allowed to change objects at higher levels. Due to its inflexibility, MAC is not typically deployed commercially.  It is described in this white paper as an example of another type of non-discretionary access control.

Enforcing the Decision

The enforcement of an authorization decision can be implemented either through custom application code, by the container in which the application runs, or some point along the path of access to the object.  When the application container enforces security, the container implicitly invokes calls to the security system to determine if access is permitted.  This is usually the desired method because security cannot be circumvented.  Access to all resources must invoke security.  This is an example of declarative security.

 

Many times declarative security is not sufficient when enforcing fine-grained security policies.  When fine-grained policies must be enforced, the application developer must explicitly invoke the security calls.  This is considered programmatic security.  Programmatic security is usually less desirable because it relies on the programmer to implement code that will invoke the security system.  This often leads to higher development and maintenance costs for the application as well as potential unauthorized access to resources.  Container invoked security calls are usually more rigorously tested and are subjected to fewer modifications than application embedded security.  For this reason, declarative security poses less of a risk. Other times, the container is unable to interpret the semantics of the policy.  For example, the policy “any person who is the subject of a document is allowed to view it” poses a problem for most container-invoked security since the container needs to know how to determine the subject of the document.  New technologies, such as XACML, are making declarative security a realistic option.  With these technologies, attributes included in the request can be parsed and used in the authorization decision.