Web applications security is a complex problem with several aspects. One aspect is access control according to specified security policy. Access control is accomplished by security model restrictions. This research is dedicated to developing security access control model for web applications. This work describes path-based RBAC model, which improves RBAC and allows flexible access control using request path (URI). Authors created guidelines to apply model's elements for real-world web applications. Developing web applications with model described allows reducing security risks.
Today modern Web applications and services are affected by several security
issues. Computer security is becoming increasingly important and actual.
According to Symantec security research [
Widely known security models include discretionary, mandatory, and
rolebased [
Currently, there are several security access control models. Some of them include
access control accomplished by discretionary matrix, mandatory levels, and
rolebased.
[
Discretionary security models are based on access control from subjects to
objects by using access control lists or access matrix. This family include security
model such as Harrison-Ruzzo-Ulman [
Mandatory access control – access control from subjects to objects based
on assigned confidentiality label for information contained in the objects and
permission entities to access information with such level of confidentiality. An
example of the mandatory model is Bell-LaPadula [
Role-based access control is a further development of the discretionary access control policy: permissions to system objects are grouped according to certain characteristics, forming role. Roles are intended to manage access control rules in a more simple way. These models do not take into account the specifics of web applications, in particular, the hierarchical organization of requests and links. The paper describes the adapted role-based security model that eliminates these problems. 3
The original role-based access control model [
→ 2
→ 2 → → 2
( authorized;
The model hierarchy (RH). while ∀ ∈ , ∃ ∈ such that ∈
( ); – function assigning for each user a variety of roles to which he – function assigning for each role set of access permissions, – function defining for each user session, on whose behalf it is – function defining for user a variety of roles for which he is authorized with current session; at the same time ∀ ∈ satisfies the condition ( )).
1 is defined as
0, at the same time introducing a role 4
To existing 1 model elements ”user”, ”role”, ”permission”, ”session” we added new elements taking into account web application features: ”token”, ”request”.
Definition 1. Token (Tk) – set of user attributes that allow him to carry out authentication in a system. Token is a pair <name, password>, or pair <public key, private key>.
Definition 2. Request (Rq) – set of information sent by the client to HTTP server. The request contains a set of headers, a unique resource identifier (URI), a set of parameters name/value, and a request payload (body).
A request belongs to the session, one session can handle multiple requests. Request and permission are tied by many-to-many relationship. On top of requests inclusion relation is defined.
Definition 3. Request A includes a request B (B ≤ A), if the path of a unique resource identifier (URI) of request A contains the path of the unique identifier of the resource request B with the initial position in the line within the same namespace, with len (Bpath) ≤ len (Apath), where len(x) – length of the string x.
A /
B /library
C /library/category D /library/book
Thus, the inclusion relation on top of requests set defines non-strict partial order.
Next, we define a function () mapping permissions to multiple requests RqA: → 2 .
Definition 4. Requests hierarchy (RqH) – inclusion relation defined on top of requests . For any ∈ the following condition is true: if , ′ ∈ , ∈ ( ), and ≤ ′, then ′ ∈ ( ).
Thus, the definition 4 makes it possible a flexible access control for individual requests, and all children requests.
Figure 2 shows a diagram of adapted security model elements. The model name is path-based role-based access control security model.
U Users
Tk Tokens
UA user
RH
R Roles
roles
S Sessions
PA requests P Permissions RqA
Rq Requests RqH
In [
Using the definitions 5.20 and 5.22 [
As a part of the mandatory access control, information flow is defined.
Definition 5. We assume that there is an information flow from request ∈ to request ′ ∈ if and only if there are roles , ′ ∈ , and session ∈ , such that (, ) ∈ ( ), ( ′, ) ∈ ( ′), and , ′ ∈ ( ).
Let’s formulate a proposition about the impossibility of forbidden information flows from the request with a higher confidentiality level to requests with a lower confidentiality level.
Proposition 1. If a role-based access model complies with liberal mandatory access control requirements, then for any requests , ′ ∈ , such that ( ) > ( ′), it is impossible to initiate information flow from to ′.
The proof is similar to theorem 5.1 [
Thus, the model described is safe in terms of information flows for requests with different confidentiality levels. 6
Security models described can be used in a wide range of applications. To apply these security models the system must meet the following requirements: – centralized access control – access control is carried out only in a single module without delegating to other units or systems; – principle of least privilege – provide the user only minimal set of privileges necessary for his work; – separation of duties support – tasks processed in the system may require multiple users to process one operation; – possibility of decomposition the system into separate components, which can be accessed using a variety of URIs, which are unique within the system.
When the above requirements are met, the system may be divided into different parts, each of them is uniquely identified by a URI. URI paths are described as access control elements and used to define a set of requests . This set includes all client requests and API calls provided by the system. Using request hierarchy is created that reflects the interaction and dependence between components.
In order to apply security model it is necessary to create a set of roles . The role defines a set of permissions that a user can perform. Examples of roles: ”user”, ”moderator”, ”registrar”, ”administrator”.
Next, the system should have defined set of permissions . Permissions define specific action or operation in the system, for example, ”create new user”, ”delete the document,” etc. One role can have many permissions. One permission can be assigned to many roles. Assigning permissions for roles is performed by function (). Permissions are non-overlapping and consistent. Elements from permissions map to a subset of requests using function (). One permission can have multiple requests. One request can be assigned to many permissions.
To maintain users a set of users is created, each of which have assigned roles from using mapping function (). One user can have multiple roles. One role can be assigned to multiple users. To identify a user the model includes a set of tokens . The elements of the set are pairs of <username, password>, or <public key, private key>. Each user can have multiple tokens. The token belongs to one user.
Once authenticated, authorized work of users is carried out by sessions. A session is a set of authorized user data, including a set of roles to which the user is authorized. Users can create multiple sessions. A session belongs to one user. Sessions can have additional data related to authorization or specific operation.
As an example, we describe application of extended path-based RBAC for publication system. The system allows users to create articles for public reading. Registered users can create and edit their articles. Editors have the ability to edit articles created by users. The administrator has access to all sections, including user administration. The system has two users, who write articles: Alice and Bob. John is an editor, and Martin is a system administrator. In addition, Martin can work as editor. The system provides a special role for anonymous users for public reading without editing articles.
Users : {Anonymous, Alice, Bob, John, Martin} Roles : {Viewer, User, Editor, Administrator}
Permissions : {”view article”, ”create article”, ”edit own articles”, ”edit all articles”, ”user management”, ”access control”, ”system maintenance”} Requests : { /articles/list, /articles/view, /manage/articles/list, /manage/articles/create, /manage/articles/edit, /manage/users/list, /manage/users/create, /manage/users/edit, /manage/permissions/roles, /manage/permissions/acl, /manage/system/settings, /manage/system/maintenance} Roles assignment for users: (Anonymous) → {Viewer} (Alice) → {User} (Bob) → {User} (John) → {Editor} (Martin) → {Editor, Administrator} Permissions assignment for roles: (Viewer) → {”view article”} (User) → {”view article”, ”create article”, ”edit own article”} (Editor) → {”view article”, ”create article”, ”edit all articles”} (Administrator) → {”user management”, ”access control”, ”system maintenance”}
Requests assignment for permissions: (”view article”) → {/articles/list, /articles/view} (”create article”) → {/manage/articles/create} (”edit own article”) → {/manage/articles/edit} (”edit all article”) → {/manage/articles/edit} (”user management”) → {/manage/users} (”access control”) → {/manage/permissions} (”system maintenance”) → {/manage/system}
As you can see from the example above, the developed models offer flexibility and simplicity for access control restriction that can be used in real-world web applications. 7
The paper describes extended path-based role access control model, which takes into account web applications features. New elements were defined: token, request, inclusion relation. The model created allows flexible access control for modern web applications.
Also extended path-based mandatory role-based access control model was created with additional sets: requests, security levels lattice, access types, roles, and permissions. Impossibility of forbidden information flows from higher to lower security levels was proven.
Authors created guidelines to apply model’s elements for real-world web
applications. Developing web applications according to these guidelines allows
reducing security risks. We use the model developed to enhance security in our
web applications [