What is the difference between DAC and RBAC?

Role-Based Access Control

Role-based access control [RBAC] is an alternative approach to mandatory access control [MAC] and discretionary access control [DAC] for the purpose of restricting system access to authorized users. RBAC is policy neutral. This makes it more flexible in the provision of access control with many of the features of both Discretionary Access Control [DAC] and Mandatory Access Control [MAC].

RBAC changed the way that authentication is addressed. MAC and DAC were previously regarded as the only models to provide access control. Thus an access model was either a DAC or a MAC model. RBAC is not truly in either category but supports the best features of both.

GEO-RBAC

The widespread deployment of location-based services and mobile applications, as well as the increased concern for the management and sharing of geographical information in strategic applications like environmental protection and homeland security, have resulted in a strong demand for spatially-aware access control systems. These application domains pose interesting requirements against access control systems. In particular, the permissions assigned to users depend on their position in a reference space. Users often belong to well-defined categories, and objects to which permissions must be granted are located in that space. Access control policies must grant permissions based on object locations and user positions.

As an example, consider a mobile application for the personnel and patients of a health care organization. Individuals are given a location-aware terminal with which they can request information services provided by an application server. The organization consists of individuals who have different functional roles [e.g., nurse, doctor, and patient]. We can notice that, depending on the organizational context, the services available to users may differ based on the functional roles of users. For example, the services available to nurses may be different from those available to doctors, not simply because of the individual preferences but mainly because of organizational and functional reasons. Further, the availability of services may depend on the position of the requester. For example, a nurse maybe allowed to request the record of a patient only when located in the department he or she has been assigned to. To deal with the requirements listed above, an access control model with spatial capabilities is needed. Since in location-aware applications users are often grouped in distinct categories, like nurse and doctor, RBAC represents a reasonable choice. However, conventional RBAC does not suffice to support such applications and needs to be extended with suitable constraints specifying location constraints, that is, constraints concerning the locations in which a given role can be accessed by a user. It is important to notice that locations can be physical, that is, expressed as coordinates in the reference space, or logical, that is, expressed in terms of spatial objects [such as the city of Milan, the West Valley Hospital] that have a semantics that are relevant to the specific application domains. When dealing with location-based applications it is also important to take into account relevant standards for the representation of spatial objects; one such standard is the one by the Open Geospatial Consortium [26].

GEO-RBAC is a recently developed model that directly supports such types of location constraints. It is based on the notion of spatial role that is a geographically-bounded organizational function. The boundary of a role is defined as a geographical feature, such as a road, city, or hospital, and specifies the spatial extent in which the user has to be located in order to use the role. Besides a physical position, obtained from a given mobile terminal such as a global positioning system–based vehicle tracking device or a cellular phone, users are also assigned a logical and device-independent position representing the feature in which the user is located. Logical positions can be computed from real positions by using specific mapping functions and can be represented at different granularities, depending on the spatial role played by the user. If the user is located inside the spatial boundary of the role that has been selected [activated] during the session, the role is said to be enabled. To specify the type of spatial boundary of the role and the granularity of the logical position, GEO-RBAC has introduced the concept of spatial role schema. Spatial roles are specified as instances of role schemas.

As RBAC, GEO-RBAC encompasses a family of models:

Core GEO-RBAC includes the basic concepts of the model, thus the notion of spatial role, role schema, real/logical position, and activated/enabled role.

Hierarchical GEO-RBAC extends the conventional hierarchical RBAC by introducing two distinct hierarchies: one over role schemas and one over role instances.

Constrained GEO-RBAC supports the specification of separation of duty [SoD] constraints for spatial roles and role schemas. Since exclusive role constraints are important to support the definition and maintenance of access control policies in mobile contexts, SoD constraints are extended to account for different granularities [schema/instance level], dimension [spatial/nonspatial], and different verification time [static, dynamic at activation time, dynamic at enabling time]. The resulting set of constraints developed for GEO-RBAC represents the first comprehensive class of constraints for spatially-aware applications.

Even though GEO-RBAC provides a comprehensive model for location-based access control, many issues still need to be investigated, such as architectural issues and session management.

Role-based access control

Role-based access control [RBAC] is a model of access control that, similar to MAC, functions on access controls set by an authority responsible for doing so, rather than by the owner of the resource. The difference between RBAC and MAC is that access control in RBAC is based on the role the individual being granted access is performing. For example, if we have an employee whose only role is to enter data into a particular application, through RBAC we would only allow the employee access to that application, regardless of the sensitivity or lack of sensitivity of any other resource he might potentially access. If we have an employee with a more complex role—customer service for an online retail application, perhaps—the employee’s role might require him to have access to information about customers’ payment status and information, shipping status, previous orders, and returns, in order to be able to assist said customers. In this case, RBAC would grant him considerably more access. We can see RBAC implemented in many large-scale applications that are oriented around sales or customer service. While this provides much greater granularity of security, it is also much more labor intensive to implement and manage.

Nondiscretionary Access Control

Role-based access control [RBAC] defines how information is accessed on a system based on the role of the subject. A role could be a nurse, a backup administrator, a help desk technician, etc. Subjects are grouped into roles, and each defined role has access permissions based upon the role, not the individual.

RBAC is a type of nondiscretionary access control because users do not have discretion regarding the groups of objects they are allowed to access and are unable to transfer objects to other subjects.

Task-based access control is another nondiscretionary access control model related to RBAC. Task-based access control is based on the tasks each subject must perform, such as writing prescriptions, restoring data from a backup tape, or opening a help desk ticket. It attempts to solve the same problem that RBAC solves, except it focuses on specific tasks instead of roles.

2.3.3 Role-Based Access Control

RBAC systems are based on a user’s roles and responsibilities. Users aren’t given access to systems, roles are assigned to users, and access is granted to roles. In an RBAC system, roles are centrally managed by the administrator. The administrator determines what roles exist within their company and then maps these roles to job functions and tasks. Roles can effectively be implemented using security groups. You start by creating a security group representing each role and you assign permissions and rights to these groups. Then you simply add the appropriate users to the appropriate security groups, depending on their role or job function.

Since access is defined based on roles and specific job functions, you have more knowledge of what access users really require to perform this job. This aids in being able to grant access based on the principle of least privilege. The principle of least privilege states that users should be given the minimum amount of rights needed for them to do their job. Role-based access models also lend themselves to easier delegation. Delegation allows you to give administrative rights to someone else. You don’t have to give them full administrative rights. You can specify certain rights for them or certain objects for them to have administrative rights over.

RBAC systems can be difficult to implement. This is in part due to the large amount of up-front work that must be done. A lot of effort is required to identify all the various roles within an organization. It’s a little easier in a newer organization. But in a large, already-established organization it can take quite some time to identify all the necessary roles and configure your systems to recognize and make use of these roles.

Most Internet-based service providers use some sort of RBAC system. This makes it easier for them to automate user creation and access activities. Service providers have to deal with thousands and thousands of users. They can’t spend much time figuring out what access each user needs so they just determine which role to place the user in and the user is automatically given the appropriate rights.

Role-Based Access Control [RBAC]

Role-Based Access Control systems are based on a user's roles and responsibilities. Users aren't given access to systems; roles are. In an RBAC system, the roles are centrally managed by the administrator. The administrators determine what roles exist within their companies and then map these roles to job functions and tasks.

Roles can effectively be implemented using security groups. You start by creating a security group representing each role. Then, you assign permissions and rights to these groups. Next, you simply add the appropriate users to the appropriate security groups, depending on their roles or job functions.

Because access is defined based on roles and specific job functions, you have more knowledge of what access users really require to perform this job. This information aids in being able to grant access based on the principle of least privilege. Role-Based Access models also lend themselves to making it easier to implement delegation. Delegation allows you to give administrative rights to someone else. You don't have to give them full administrative rights. You can specify certain rights for them or certain objects for them to have administrative rights over.

Role-Based Access Control systems can be difficult to implement. This is in part due to the large amount of up-front work that must be done. A lot of effort is required to identify all the various roles within an organization. It's a little easier in a newer organization. But in a large, already established organization, it can take quite some time to identify all the necessary roles and change your systems so that they recognize and make use of these roles.

Role-Based Access Control

Role-based access control [RBAC] is a method whereby only authorized users can gain access to an environment and the sessions contained in the environment, as shown in Figure 11.1. Some refer to RBAC as role-based security due to the roles an organization creates to assign permissions to users, who perform specific functions, and such users acquire their roles and rights when their account is created. In Active Directory, either the users are in a department that assigns rights by department or the users have customized access based off their role to perform a job function. Referring to the model in Figure 11.1, use the following conventions:

Subject [S]—person or agent

Role [R]—job function

Permission [P]—authorization to access a resource or utility

Session [SE]—mapping, including S, R, and/or P

Subject Assignment [SA]

Permission Agent [PA]

Partial Instructional Role Hierarchy [RH]—≥[where x≥y requires x to inherit permissions of y]

Subjects are allowed multiple roles.

Roles are allowed to contain multiple subjects.

Roles are allowed to assign multiple permissions.

Permissions can be allocated to multiple roles.

Operations can be allocated to multiple permissions.

Permissions can be allocated many operations.

Whereas a constraint positions a provisional rule on the possibility of inherited permissions from contrasting rules; it can thus be utilized to attain applicable partitions of duties. As such, a user should not be permitted to both create a login or to empower such an account creation. RBAC is comprised of three principal guidelines:

Role assignment: A subject can implement permission once the subject has been designated or has allocated a role.

Role authorization: A subject’s dynamic role requires permission for the subject. Refer to rule 1, above, which warrants users only inherit roles for which they are sanctioned.

Permission authorization: A subject can employ permission merely if the permission is approved for the subject’s functional role. Refer to rules 1 and 2; rule 3 confirms users can only carry out permissions for which they are allowed.

Several additional controls can be applied on top of the former three rules, and roles can be combined in a hierarchy where higher level roles consider permissions retained by subroles. In larger organizations, typically those with over 500 users, administrators tend to combine MAC or DAC.

As previously mentioned, RBAC can be referred to as an adaptable secure access control. RBAC diverges from access control lists [ACLs] in that it appoints permissions to exclusive operations for users to perform their job functions, rather than to low-level data objects. Let’s say an access control list could be utilized to allow or deny write access to a certain file system, but it is unable to dictate how that file could be changed.

As an example, in financial systems, an operation may seek to create a new trading account or to create a new database for a particular trading product. The assignment of the permission to perform a particular operation is meaningful in this instance, since the operations are so granular with meaning to an application. You would not want college interns creating new trading accounts utilizing real money and would prefer that only an administrator of the risk department had those rights. Even concerning trading limits, imagine if traders could go into the application and raise their trading limits themselves. Risk controls are put into place to protect assets and rights.

RBAC is well suited to separate liabilities, ensuring that more than two people are involved in authorizing critical operations. Integrating RBAC benefits access control policies and aids the IT infrastructure where Active Directory, SQL Server, and any other proprietary applications are concerned.