High level security is a key requirement in hypermedia/web applications. The systems opening to the Internet makes the research effort to move towards protecting the information transmission (i.e. SOAP messages, policy descriptions. . . ), but little attention is paid to what the user can do with the system. Role-based access control (RBAC) allows to formulate the organization's resource access policy in a natural way, so a role-based access model for hypermedia will make it easier to integrate the security design with the rest of the system design. In service oriented architectures, an access policy service would allow to gather the management and deployment of the security policy in distributed and heterogeneous environments. This paper describes a role-based access control model for hypermedia called MARAH, and its implementation as a web service. An use case of the model in the design of the ARCE application is also discussed.
The industry and research community trend towards the
openness and interoperability among systems is very clear,
what makes very important the adequate resource
protection. The balance between service providing and asset
protection becomes an strategic issue, so the security design
has to be more than an implementation/deployment aspect:
security is a first-class element whose requirements should
be taken into account throughout all development process.
This design integration would help to face the security
analisys and design [
Hypermedia/web applications are implemented in a variety of platforms, where the information is probably distributed and heterogeneous, and the access context can be very different each time. There is a clear need for a model that considers these issues and makes it possible to express the access policies in a flexible way. From an architectural point of view, it is recommended to keep some separation between the security controls and the controlled resources themselves, what makes the Web Services paradigm a perfect deployment platform to test our ideas.
MARAH is a role-based access model for hypermedia applications, that works with concepts of the hypermedia domain (i.e. contents or links), and is based on the RBAC model. RBAC articulates the access policy around the role concept: instead of granting permissions directly to system users, permissions are assigned to roles, and users are assigned to the roles they can play, acquiring its permissions. The role represents job functions, responsibilities or qualifications in the context of some organization, and groups both the permissions and the users allowed to use them.
The use of roles and proper hypermedia abstractions to express the access rights makes it possible to integrate MARAH in a development method, due to designers can decide about what the access policy is while designing other system aspects, such as navigation or content layout. This facilitates the policy definition, because now access control is not performed on the application code in terms of classes/objects, database tuples or other paradigm, but protected resources are the elements of a hypermedia design, that have a correspondence with one or more systems responsible of the information generation.
MARAH is available as Web Service, with the goal of
providing the access policy information in a concrete
domain. The implementation covers the core RBAC standard
[
Initially MARAH was defined as an unique model,
specifically designed for a hypermedia reference model
called Labyrinth[
Next subsection introduces the core RBAC model, as previous requirement to define the core MARAH model.
The core RBAC is one of the four model components
defined in the RBAC reference model, and “defines a
minimum collection of RBAC elements, element sets and
relations in order to completely achieve a Role-Based Access
Control system” [
Sets of Users, Roles, Operations and Objects respectively. • U A ⊆ R × U
A many-to-many mapping user-to-role assignment relation. • assigned users : R → 2U
The mapping of a role r onto a set of users allowed to hold it. Formally, assigned users(r) = {u ∈ U | (u, r) ∈ U A}. • P ⊆ 2OP S× O
The set of permissions. A permission represents an approval to execute an operation on a protected object. • P A ⊆ P × R
A many-to-many relationship mapping the permissionto-role assignment relation. • assigned permissions : R → 2P
The mapping of a role r onto a set of permissions. Formally, assigned permissions(r) = {p ∈ P | (p, r) ∈ P A}. • Op : P → OP S
The permission to operation mapping, which gives the set of operations associated with permission p. • Ob : P → O
The permission to object mapping, which gives the set of objects associated with permission p. • S
The set of sessions. A session represents an user interaction period, where the user activates some subset of the roles she is assigned to. Each user can establish one or more sessions. • session users : S → U
The mapping of session s onto the corresponding user.
S r∈session roles(s) • session roles : S → 2R
The mapping of session s onto a set of roles. Formally, session roles(s) ⊆ { r ∈ R | (session users(s), r) ∈ U A} • avail session permissions : S → 2P
The permissions available to the user in a session. Formally, avail session permissions(s) = assigned permissions(r)
In addition to the sets, relations and functions, the RBAC standard also defines the system and administrative functional specification for the core model. Administrative functions allow to create and maintain the RBAC sets and relations, administrative review functions allow to perform administrative queries, and system functions allow to creat and manage user sessions and make access control decisions.
The core of MARAH is based on a hypermedia metamodel that assumes two fundamental elements of this discipline: the distinction between container and content, and the information linking. As in RBAC standard, to apply MARAH in a concrete system, a mapping from the access model components to the system components has to be provided. Due to MARAH is an access control model for hypermedia, this mapping should not be very complex, as MARAH provides the proper abstractions representing protected objects. Starting from the core RBAC specification, the Core MARAH model provides three contributions.
The first of these contributions is the definition of the protected objects. The hypermedia metamodel assumed by MARAH defines four object types1 that can be identified in most hypermedia models: Nodes abstract information containers, they have whole meaning in the application context. Represent presentation units.
1These object types reflect the application information structure, regardless how the information is modeled (i.e. OO model), stored or generated to give place to such structure.
Contents individual pieces of information that are included in the nodes. They can be simple (e.g. text) or complex (e.g. video).
Anchors represent areas or fragments in the node or content representation space (i.e. characters, pixels, rows, seconds. . . ).
Links represent information connections, by means of relationships between a set of source and a set of target anchors.
Nodes and contents represent the system information, so they are the basis on which privileges are established. Anchors and links are used to represent relationships between information elements, so its definition is somehow tied to the elements in which are defined, and thus its access rights have to be derived from the permissions of these elements.
The second is the addition of relationships among objects. Core MARAH considers two relation types in the object set: Location reflect the spatial/temporal placements among objects. For instance, the inclusion of contents into nodes or the definition of anchors.
Linking represent associative connections between nodes and/or contents.
As explained later, these relationships are used to propagate access rights in a variety of situations, so the administration cost is reduced due to there is no need to specify the permissions for each object.
The third contribution is the addition of one abstraction level on top of the system operations, reducing the number of permissions assignments by means of a classification of operations. The classification groups the operations and allows to easily set permissions involving several operations.
Core MARAH is an extension of Core RBAC standard that defines the object types2, new elements and the relationships between the RBAC standard model, as shown in figure 1: • O = N ∪ C ∪ A ∪ L
Sets of nodes (N ), contents (C), anchors (A) and links (L) respectively. • OR = {loc, Ls, Lt}
Set of object relationships. Core MARAH defines three relationship types: Location. loc ⊆
O × O. If a loc b, there is a spatial/temporal relationship from object a to object b. For instance, if anchor a is defined to start in the third second of video b, then there is a location relation from the anchor to the video. 2Due to its generality, the RBAC standard leaves open this question.
user_sessions (UA) user_assignment (OR) object_ relationships Ls loc
session_roles
(PA) permission_assignment
ω
Core MARAH s n o i s s i m r e P
C A B R e r o C • ω : OP S → SC
Classification of operations function, that relates each operation with the manipulation type that its execution requires, for instance, ω(getLinksToTarget()) = B. • φ : R × { N ∪ C} → SC
The clearance function returns the highest manipulation ability that a role can do on an object. This value is set by the security officer for contents and nodes, • and involves the creation of a set of permissions in P for the object and the operations classified with a lower or equal category than the one specified. Formally, if administrator sets the following clearance φ (r, o) = E, then ∀op ∈ OP S | ω(op) ≤ E ⇒ P = P ∪ (op, o), P A = P A ∪ {(op, o), r}.
Q : S × O → SC ∪ 0 The authorization rule returns the highest manipulation ability available in a session for a given object. The value depends on the session active roles, the type and relationships of the involved object. The function is defined as follows: – For nodes and contents, returns the maximum of the session permissions: Q(s, o) =
S max(0 ∪ { p∈ASP(s),Ob(p)=o ω(Op(p)) ) } (ASP(s) = avail session permissions(s)). For the maximum, a total order is defined such as E > B > 0. The value of 0 indicates the absence of permissions for the object in the session3. – Anchors take directly the permission granted to the object on which are located.
Q(s, a) = Q(s, o) | aloco – For links, “B” access is allowed if there is access to at least one anchor in each link end. “E” access is allowed if all anchors have editing permissions: B Q(s, l) = E 0 if ∃a1, a2 | a1Lsl, a2Ltl, Q(if, a1) = Q(s, a2) = B si ∀ai, aj | a1Lsl, ajLtl, Q(s, ai) = Q(s, aj ) = E otherwise • θ : OP S × O × S → {0, 1}
The transition function checks if an operation can be performed on an object from a given session.
(1 if ω(op) ≤ Q(s, o), θ (op, o, s) =
0 otherwise
The Core MARAH model defines also a set of administrative and system functions, in order to create, maintain and query the different sets and relations, as well as creating user sessions and taking access control decisions.
Core MARAH is being implemented as web service. It
acts as policy decision point (PDP), independent of the
pol3The model does not provide an interpretation for this situation.
icy enforcement point (PEP) where the actions according
to the PDP take place, typically in systems responsible of
content generation, integration and/or delivery. Previous
implementations of MARAH were integrated in the
content server [
yes/no adaddUdRseorl(eJ(oNh1n)) assignUser(John, N1)
GET http://url.net
HTML Response
Structures &
Security Policy Web browser
Management tool
and RBAC standard have led to a broad service split in two
smaller cooperating subservices. This cooperation
gathers the transformation rules from MARAH components to
RBAC components described in previous section, in terms
of service operation execution. From the point of view of
the service clients, whether administrators or systems
implementing PEPs, this separation is completely hidden. The
service usage is very simple: first, access policy is notified
to the service. Then, the service is requested for access
control decisions involving operations, objects and roles
previously defined. Here the term access policy means the
definition of the set of objects and its relations, roles and
clearances. It is important to note that the adoption of the web
service paradigm and the creation of a policy service
separated from the PEP introduces new challenges, due to there
is a need to protect the information during transmission
between PEP and PDP. Due to the focus of this work is the
deployment of the abstract core access control model, and
taking into account the advances to come in the web
services security area [
The Core RBAC web service implements the Core RBAC administrative and system functional specifications, providing operations for: • Adding/removing users and roles, • Assigning/deassigning users to roles, and permissions to roles, • Creating/deleting sessions for an user and activating/deactivating some roles, • Checking the access.
In order to provide a general service, all elements (roles, users, permissions and operations) are identified by string tokens, whilst the service returns information using primitive types such as string lists or boolean values. Figure 3 shows part of the web service definition (WSDL) for Core RBAC service. functions, that, in addition to the functionality provided by Core RBAC, allow to: • Creating/deleting object instances, for each one of the four types, • Creating/deleting object relationships (location, source linking and target linking), • Granting/revoking clearances to roles, • Checking the access, by the transition function (θ ).
The Core MARAH service acts as client of the Core
RBAC service, and implements administrative and system
The Core MARAH service is being probed in an use case
of the ARCE system (networked application for emergency
situations), which goal is to facilitate the efficient aid
management in emergency situations among Latin-American
countries [
• Role N2 sends messages to N2 receivers, with mandatory copy to N1. The rest of receivers can be selected by the sender when composing the message. • Role N3 sends message to N3 users, with mandatory copy to N1. The rest of receivers can be selected by the sender, excepting N8, that can’t receive messages from N3.
The messaging subsystem has three pages: the message composition page, the message list page (provides a table with message subjects) and the message view page (showing one message). The system has been modeled as follows: • Nodes: the message composition, message list and message view are nodes. For each new composed message, a new node is generated representing it. • Contents: Each form element in the message composition page is a content. In the message list, there is a table which rows representing links to messages. In the message view page, the message title and text are also contents. Each new message generates contents for the text and title. • Anchors and links: from the message composition the user can navigate forwards and backwards to the message list. In this page, there is a link for each written message pointing to the corresponding message view node. • Clearances: The message composition and list nodes have the “B” category for everybody. The message composition form has checkboxes in order to select the receiver roles. These checkboxes have different permissions according to the information flow policy: – If the sender must send the message to the receiver, the checkbox has a “B” clearance, stating that the checkbox value can’t be modified – If the sender can choose if the receiver will read the message or not, then the checkbox has a “E” clearance – If the sender can not send the message to a receiver, there is no permission for the checkbox According to this modeling, table 1 shows the clearances for the contents of message composition node, for roles N2 and N3 (the symbol ∅ indicates that no clearance is assigned). Each checkbox is named using the destination role. It is important to note that the system implementation (PEP) is responsible for taking the right action according to the response of the PEP, what includes choosing presentation issues. Figure 5 shows the aspect of the generated pages in conformance with the policyfor roles N2 and N3, where the non-editable checkboxes appear disabled. If some receiver must be notified, the corresponding checkbox appears marked and disabled.
checkbox N1 checkbox N2 checkbox N3 checkbox N4 checkbox N5 checkbox N6 checkbox N7 checkbox N8
N2 B B E E E E E E
N3 B E B E E E E ∅
The messaging subsystem has been implemented in PHP due to this language offers SOAP functions that make it easy the coding of web service clients. The web server chosen to host the PHP pages is Apache. Nodes and contents are PHP objects that provide their information through the show() method, that includes a call to the Core MARAH service transition function. The PDP queries are performed by the class pdp.php, whose objects are built by providing the URL of the WSDL description of the Core MARAH service, as shown in figure 6.
Each node and content in Core MARAH corresponds to a PHP object, but nodes keep references to the objects representing their contents (and thus implementing the loc relation), as shown in figure 7, where a generic node code is shown. Using this mechanism, a PHP node will perform several queries to the PDP during its dynamic generation. The process for the generation of the message composition node (see figure 5) is as follows: once policy is notified to PDP, an authenticated user tries to visualize the page, so PHP calls show() on the PHP object implementing the page. First, the node checks access for itself, using context information that includes the user name and session identifier. After querying the PDP and checking the transition function value for the “B” category, the node starts to show its own contents, according to its own source code.
Each content to show is a PHP object, that is notified to show itself by the show() method. In order to show its information, the transition function has to return 1 for the content itself, so the PDP is queried again. When the content includes anchors or other contents, the process is repeated again, so each HTML element sent to the client has been filtered by the access control mechanism, and so it is an allowed element. In this way, a given sender can not select roles for which sending a message is prohibited, because the contents that allow this action are skipped or otherwise disabled from the page.
Once the sender writes the message title and body, selects the receivers and sends the message, the system does the following: • Generate a new node n representing it, including the message title and body in its contents. Define an anchor t and include it in the node. • Add the message title content in the message list page, creating an anchor s for it • Create a new link, whose source is the s anchor, and the target is t. • Set the clearances corresponding to the new node for the selected roles, using the checkbox information. If a role Ni is marked, then φ (Ni, n) = B.
Now we illustrate how links are skipped in the message list node. When processing this node, each table row represents a link to a message. In order to get access to a link, one of its sources and targets must be accessible. Since the target anchor takes the permission from the node in which is defined, the whole link has the permission of the destination. This implies that if the message is denied to some role, the link to it is too denied, so the PHP page will not add the corresponding row to the table. So, it can be said that there are one or more PEP for each object, but the PDP answers are provided by Core MARAH service. 5
This work presents a role-based access control model for hypermedia systems, and its deployment as a web service, in response to the need of separating the access control decision of the policy enforcement. Moreover, a prototype that uses the web service has been built, in the ARCE application context. The model is deliberately simple, because its design criteria are based on the modularity, flexibility and minimalism, in similar philosophy as the used in the core RBAC design.
There are several future work directions. Firstly, the
access model will be extended by adding several layers in
order to add more advanced features. The first one will
presumably be the Hierarchical MARAH, that will be based
on Hierarchical RBAC and will extend it by providing new
roles and objects relationships. This will allow to create
richer structures where the permission inheritance will
reduce even more the access rights management. Other
foreseen extension are the inclusion of context parameters [
Regarding the service, we plan to study how to apply the service in decentralized architectures where there are several PDP responsible of keeping parts of the enterprise-wide access policy. The PDPs can also be separated to some extent and be transformed into another service, able to generate an adequate version of the content according to the user, for instance using SMIL (http://www.w3.org/AudioVideo/).
Moreover, we will consider the integration with web
services security standards, particularly WS-Policy [
This work is part of the ARCE++ project (TSI200403394) funded by the Spanish Ministry of Science and Education (MEC) and a cooperation agreement between Universidad Carlos III de Madrid and Direccin General de Proteccin Civil y Emergencias (Ministry of the Interior).