COS 80011 Web Application Architectures Lecture 10 Access Control.

COS 80011Web Application Architectures

Lecture 10Access Control

© Swinburne University of Technology2

What is Access Control?

Access Control Matrix and Access Control List

Role-Based Access Control User-Role Assignment Role-Permission Assignment

Attribute-Based Access Control

Context-Aware Access Control Context-Aware User-Role Assignment Context-Aware Role-Permission Assignment

Outline







Outline


Access control is one of the fundamental security mechanisms

needed to protect computer resources (and/or services) against unauthorized access according to a security policy

policy – is a rule (who can access what) verifying whether a subject (user) is allowed to carry out a specific

action (operation) on an object (resource) it is a mechanism to determine whether a request from a user to

access resources in a system should be permitted or denied

Access Control (I)


It has three major components

subjects – represent the users in a system performing actions on an object

objects – represent the resources that are being protected by the system

operations – represent all the actions that the subjects can perform on the objects

Access Control (II)


Access Control Models/Technologies

- Access Control Matrix or Access Matrix (AM)- Access Control List (ACL)- Role-Based Access Control (RBAC)- Attribute-Based Access Control (ABAC)- Context-Aware Access Control (CAAC)- Extended RBAC Models: TMAC (team), OrBAC (organization), …- ABAC Models: XACML, …- …

Access Control (III)


Traditional forms of Access Control AM, ACL, RBAC, … file systems, operating systems, database systems, …

Access Control on the Web XACML (OASIS standard Web-based AC), XACML for RBAC, … Domain-specific inputs converted to the XACML Request Context.xml

(PEP) XACML core policy framework or XACML RBAC implementation

using (J2SE, CORBA, etc.), resources are exposed as Web services (PDP, PIP, PAP)

XACML Response Context.xml is converted to the domain-specific outputs (PEP)

Access Control (IV)







Outline


Access Control Matrix or Access Matrix (AM)

access control technology has a long history that started in the late 60s

it was first introduced by Lampson in 1971, who introduced a formal, mathematical description of a basic access control model named Access Control Matrix

<Lampson, Butler W. (1971), Protection, Proceedings of the 5th Princeton Conference on Information Sciences and Systems>

Access Control Matrix (I)


Access Control Matrix or Access Matrix (AM)

the first basic model of access control is the AM a formal security model in computer systems characterizes the rights of the subjects with respect to the objects describes the relationships between subjects and objects in a system

<Lampson, Butler W. (1971), Protection, Proceedings of the 5th Princeton Conference on Information Sciences and Systems>

Access Control Matrix (II)


Access Control Matrix: It has three components

a set of Objects O, a set of Subjects S, and an Access function A an Object is an entity in the system which has to be protected a Subject is an entity that has access to the Object which Subjects can access which Objects is determined by the

Access function

Access Control Matrix (III)


Access Control Matrix

the rows of the Access function are labelled with the Subject names and its columns by the Object names.

element Ai,j specifies the access which Subject i has to Object j each element or cell of the matrix consists of a set of strings called

access attributes, such as read and write, which are typical access attributes

Access Control Matrix (IV)


AM Implementations

operating systems database systems

Access Control Matrix (V)


AM Implementations

a rectangular array of cells, with one row per subject and one column per object

Access Control Matrix (VI)

file1 file2user1 read, write read, write, execute

user2 read execute

user3 write read

Table: A rectangular array


Access control list (ACL)

- each column in an Access Control Matrix (AM) is translated to an Access Control List (ACL)

- the ACL contains entries for each subject defining the operations that the subject can execute on the given object

Access Control List (I)


Access control list (ACL): it specifies

- which users or system processes are granted access to objects- what operations are allowed on given objects

<Access Control List: Google patents,

http://www.google.com/patents/US20130145028>

Access Control List (II)


ACL Implementations

File System ACL: A file system ACL is a data structure (table) containing entries that specify individual

user or group rights to specific system resources. resources - programs, files, etc.entries – access control entries (ACEs).

Access Control List (III)


ACL Implementations

File System ACL - used to administrate file permissions for example, a file has an ACL that contains (Bob, delete) this gives Bob permission to delete the file.

<MS Windows, Unix/Linux Operating Systems>

Access Control List (IV)


ACL Implementations

File System ACL – access ACL and default ACL (Red Hat Linux)an access ACL is the access control list for a specific file or

directory. a default ACL can only be associated with a directory; if a file

within the directory does not have an access ACL.default ACL uses the rules of the default ACL for the directory.ACLs can be configured per user or per group.

<https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-acls.html>

Access Control List (V)


ACL Implementations

File System ACL – access ACL and default ACL (Red Hat Linux) the setfacl utility sets ACLs for files and directories.

# setfacl -m rules filesuse the -m option to add/modify the ACL of a file/directoryrule formats u:uid:perms, g:gid:perms

# setfacl -m u:bob:rw /cos80011/waa

<https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-acls.html>

Access Control List (VI)


ACL Implementations

SQL-based systems relational database systems networking ACLs

Access Control List (VII)


Advantages easy to implement, simplicity and flexibility are the keys effective in closed and relatively unchangeable systems

Disadvantages do not allow modelling the global policy rules by which permissions

can change in any particular system they do not have adequate functionalities to maintain the users and

objects in the large-scale systems, where more than one user need same object

AM and ACL (VIII)







Outline


Role-Based Access Control (RBAC)

- a well accepted access control model based on the role of the user is Role-based Access Control (RBAC) was introduced to tackle the problems: global policy rules, large-scale systems

- first RBAC, Ferraiolo et al (RBAC92)- the RBAC92 model has been subsequently extended by Sandhu et al

(RBAC96)

<Sandhu et al (RBAC96): http://dl.acm.org/citation.cfm?id=226710>

<Ferraiolo et al (RBAC92): http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf>

Role-Based Access Control (I)



- in RBAC, it is not important to identify the individual who makes the access request, but to know his position in the structure of an organization

- this concept is known as a role in RBAC- the authorizations are not assigned directly to a particular user, but to

the user’s role

Role-Based Access Control (II)



- user group and user role – roles are closely related to the concept of user groups in access control

- however, a role brings together a set of users on one side and a set of permissions on the other

- whereas user groups are typically defined as a set of users only

Role-Based Access Control (III)


Role-Based Access Control (RBAC): three main concepts- RBAC ensures that only an authorized user is given access to a

certain resource, and is based on a user’s role in an organization- users, roles, and permissions in a simple/basic RBAC model- users – subjects are typically represented by users, who are

assigned to roles and are granted membership into the roles based on their credentials and responsibilities in an organization

- roles – roles represent a job function, describing the authority and responsibility conferred on a user assigned to that role, within an organization

- permissions – permissions are assigned to roles, permissions contain resources and operations (the operations are allowed on the objects/resources)

Role-Based Access Control (IV)


Role-Based Access Control (RBAC) Model

Role-Based Access Control (V)

UUser

RRole

PPermi-ssion

UserAssignment

UA

PermissionAssignment

PA

Figure: Basic RBAC Model


Role-Based Access Control (RBAC) Model

- U, R and P are the users, roles and permissions respectively- UA is a many-to-many user to role assignment relation

- PA is a many-to-many permission to role assignment relation

Role-Based Access Control (VI)

U

P


Role-Based Access Control (RBAC): ESP Submissions (Assignments)

- user-role and role-permission assignments (policies)

Role-Based Access Control (VII)

User Role Permission<s7021046, ******> Student <Assignment2, submit>

<akayes, ******> Tutor/Marker <Assignment2, marking>

<acolman, ******> Lecturer/Convenor <Assignment2, marks release>

Table: Relationships among users, roles and permissions


Role-Based Access Control (RBAC): Role Hierarchy- also called role inheritance- for structuring roles to reflect an organization’s lines of authority and

responsibility- the senior roles can inherit all permissions from the junior roles- the senior roles can have permissions in addition to those inherited

from the junior roles

Role-Based Access Control (VIII)


Role-Based Access Control (RBAC): Role Hierarchy Example- The lecturer role (senior role) can inherits all permissions from the

staff role (junior role)- The lecturer role can have own permissions also

Role-Based Access Control (IX)

UniversityUser

Staff

Lecturer

Student

UGS TutorPGS

Figure: Role Hierarchy


Role-Based Access Control (RBAC): Other RBAC Concepts

- RBAC Session (users can create and terminate sessions, to activate/deactivate roles)

- RBAC Constraints (predicates that can apply to the UA and PA relations)

Role-Based Access Control (X)

<Sandhu et al (RBAC96): http://dl.acm.org/citation.cfm?id=226710>


Role-Based Access Control (RBAC): Patient Medical Records Management

- user-role assignments

Role-Based Access Control (XI)

User userID

Jane Jane00X

Mary Mary00X

Bob Bob00X

Role roleID

Registered Nurse RN00X

Primary-care Physician

PP00X

Emergency Doctor

ED00X

Specialist Physician

SP00X

Physician P00X

User-Role Assignments (UA)

<Jane00X, PP00X>

<Jane00X, ED00X>

<Mary00X, PP00X>

<Bob00X, RN00X>

<Jane00X, SP00X>



- role-permission assignments

Role-Based Access Control (XII)

Permission <resource, operation>

<Electronic Health Records (EHR), write>

<daily medical records (DMR), read>

<Past Medical History (PMH), write>

Role -Permission Assignments (PA)

<ED00X, <EHR, write>>

<RN00X, <DMR, read>>

<P00X, <DMR, write>>

<P00X, <PMH, write>>

<SP00X, <EHR, read>>



- The specialist physician role (senior role) can inherits all permissions from the physician role (junior role)

Role-Based Access Control (XIII)

HealthcareUser

Physician


Nurse

Figure: An Excerpt of Healthcare Role Hierarchy


Registered Nurse

Nurse Manager

Emergency Doctor



Role-Based Access Control (XIV)

Physician



Emergency Doctor

UA<Jane00X, PP00X>

<Jane00X, ED00X>

<Mary00X, PP00X>

<Bob00X, RN00X>

<Jane00X, SP00X>

PA<ED00X, <EHR, write>>

<RN00X, <DMR, read>>

<P00X, <DMR, write>>

<P00X, <PMH, write>>

<SP00X, <EHR, read>>

Role roleIDRegistered Nurse RN00X


PP00X

Emergency Doctor

ED00X


SP00X

Physician P00X


Role-Based Access Control (RBAC): main part

Role-Based Access Control (XV)

Role

Resource

Operation

Organization


Advantages simplifies management of permissions effective/useful model in large-scale systems/domains

Disadvantages the user-role and role-permission assignments are static without

taking into account the dynamic attributes, such as the location of users

this makes a less effective solution in today’s open and dynamic environments

Role-Based Access Control (XVI)







Outline


Attribute-Based Access Control (ABAC)

- a new access control paradigm where access rights are granted to users through the use of policies which combine attributes together

- the policies can use any type of attributes (user attributes, resource attribute, etc.)

- it is a rule-based approach to access control, it does not use the concept of a role

- the building blocks in the ABAC model are the attributes- an ABAC policy specifies which constraints need to be satisfied

based on the attributes (e.g., user age is greater than 20) in order to grant access to an object

Attribute-Based Access Control (I)


Attribute-Based Access Control (ABAC)- the formal definition of basic ABAC is composed of four parts: access

control related entities, attributes of entities, policy representation, and policy evaluation

- entities – requestor (Req), resource (Res), action (Act), environment (Env)

- attributes of entities (e.g., attributes of environment (Attr(Env)) – the current date or time)

- policy specification – the definition of access control policies- policy evaluation – the process of making an access decision based

on the security policy

<ABAC, http://www.mcs.anl.gov/uploads/cels/papers/P1367.pdf>

Attribute-Based Access Control (II)


Attribute-Based Access Control (ABAC): policy evaluation

- an access control decision is made by the evaluation function (), access control decision function, ADF

- it takes the attributes of the requestor, the resource, the action, the environment as parameters

Attribute-Based Access Control (III)


eXtensible Access Control Markup Language (XACML)

- is the standard that implements attribute-based access control- a standard XML-based protocol for access control policies- suitable for a variety of application environments (e.g., Web-based)- uses the attributes of subject, resource, action, and environment- this framework contains PEP, PDP, PIP, and PAP

<OASIS XACML 3.0 (2013), http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf>

Attribute-Based Access Control (IV)


eXtensible Access Control Markup Language (XACML): four main components

- Policy Enforcement Point (PEP)- Policy Decision Point (PDP)- Policy Administration Point (PAP)- Policy Information Point (PIP)


Attribute-Based Access Control (V)


XACML Data Authorization Framework

Attribute-Based Access Control (VI)

Figure: XACML Data Flow Diagram<OASIS XACML 3.0 (2013), http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf>


XACML Data Authorization Framework: when access request comes from the access requesters (users)

- the PEP intercepts the access requests from users and sends the requests to the PDP (through the context handler)

- the PDP makes access decisions according to the security policy (policy set) written by the PAP

- the PDP uses the attributes of the subjects, the resources, and the environment obtained by querying the PIP (via the context handler)

- the access decision given by the PDP is sent to the PEP(through the context handler)

- the PEP sends either permitted or denied request to the users according to the decision of PDP

Attribute-Based Access Control (VII)


XACML Implementation

Domain-specific Inputs (from the requesters) converted to

XACML Request Context (.xml) XACML Policy (.xml) XACML Response Context (.xml)

converted to Domain-specific Outputs (back to the requesters)

Attribute-Based Access Control (VIII)


Language Model of XACML

Attribute-Based Access Control (IX)

Figure: XACML Context and Policy



Advantages easy to implement/setup very useful model in small-scale systems/domains

Disadvantages when the number of users is high, the number of authorizations can

become extremely large, which complicates the administration tasks this brings high complexity of security administration and significant

cost of management of growing large-scale systems it does not provide adequate functionalities for dynamic access

permissions

Attribute-Based Access Control (X)







Outline


Static Access Permissions AM ACL RBAC ABAC XACMLDynamic access permissions (to dynamically make access control decisions)The dynamic user-role and role-permission assignments

Access to medical records of patients should be dynamically controlled depending on the location and request time of users. Normally, a nurse that is not located in the hospital should not have access to medical records of patients. Moreover, this access is allowed only during her ward duty time, and knowing the relationship between patient and nurse.

Context-Aware Access Control (I)


RBAC has become the most widely used access control model The CAAC model adopts RBAC concepts and extends its

user-role and role-permission assignments CAAC incorporates the dynamic attributes (context

information) into both user-role and role-permission assignments

Context-Aware Access Control (II)


CAAC Policy Framework

<A. S. M. Kayes, Jun Han, and Alan Colman, A Semantic Policy Framework for Context-Aware Access Control Applications, TrustCom 2013, http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6680911&tag=1>

Context-Aware Access Control (III)


Dynamic Context-Aware Environments

Shift from desktop environments to dynamic environments described by Mark Weiser, where users need seamless access to various resources at anytime from anywhere even when they are on the move

Pervasive/Ubiquitous environments Privacy and security of accessing resources/services is of greater

concern Context information

Context-Aware Access Control (IV)

<Mark Weiser, Some computer science issues in ubiquitous computing, Comm. ACM 1993, http://dl.acm.org/citation.cfm?id=159617>


Context Information and Context Awareness

Dey, Context information is defined as any information that can be used to characterize the situation of an entity and Context awareness is the ability to use context information to provide relevant information and/or services to the user

Our focus is “CAAC Model” Context-aware access control (CAAC), decision making based on the

context information, reauthorization of access if context changes

Context-Aware Access Control (V)

<Dey et al, A Conceptual Framework for Context-Aware Applications, PUC 2001, http://www.tandfonline.com/doi/abs/10.1207/S15327051HCI16234_02#.U29vNfmSzzg>


Application Scenario

Context-Aware Access Control (VI)

Figure: User-to-Resource Access Scenario in Context-Aware Environments

Users from different locations

Users from different devices

A Patient in an Emergency Health Condition

Users atdifferent times

Organization

UserResources


Application ScenarioContext-Aware Access Control (VII)

Figure: Healthcare Scenario

UserResources

Healthcare

Patients’ Medical Records

A patient Bob who is in the emergency room due to a heart attack. While not being Bob's usual treating physician, Jane, a

medical practitioner at the hospital, is required to treat Bob and needs to access Bob's electronic health records from the

emergency room.


Application ScenarioContext-Aware Access Control (VIII)


UserResources

Healthcare


After getting emergency treatment, Bob is shifted and has been assigned a registered nurse Mary, who has regular follow-up visits to monitor his health condition. Mary needs to access

several types of Bob's records (daily medical records and private health records) from the general ward.


Application Scenario

Context-Aware Access Control (IX)


UserResources

Healthcare


Different users with different roles from

different environments for

different intentions

Privacy and security


Main Challenges/Requirements

(Req1) - representation of context entities and context information relevant to access control (context model)

(Req2) - inferring high-level context information from the available information (reasoning model)

(Req3) - incorporating dynamic contextual information into access control policies (policy model)

Context-Aware Access Control (X)


Context-Aware Access Control (XI)

Figure: CAAC Model


CAAC Model Concepts (elements) Users(U) – a user is a human-being (who is a service requester)

interacting with a computing system, whose access request is being controlled (e.g., Jane, Mary)

Roles(R) – a role reflect user's job function within the organization (e.g., healthcare domain)

Resources(Res) – a resource is an object protected by access control that represents the data/information container (e.g., patient’s electronic health records)

Operations(Op) - an operation is an action that can be executed on the resources (e.g., read, write)

Permissions(P) - permissions are the approvals to perform certain operations on resources, by the users who initiate access requests

Context-Aware Access Control (XII)


CAAC Model Concepts (elements) Context Information(CI) – context Information used in an access

control decision is defined as any relevant information about the state of an entity or the state of a relevant relationships between entities (e.g., location of the patient, social or interpersonal relationship between doctor and patient)

Policies(Pol) – two sets of policies: the context-aware user-role assignment policies and context-aware role-permission assignment policies

Context-Aware Access Control (XIII)


Context-Aware Access Control (XIV)

Figure: CAAC Model


CAAC Model Concepts (relationships) Role Hierarchy(RH) – it supports the concept of role inheritance (like

RBAC). The role is considered in a hierarchical manner in that if a permission assigned to a junior role, then it is also assigned to all the senior roles of that role

Resource Hierarchy(ResH) – the resource is also considered in a hierarchical manner in that if a user has the right to access a resource with the highest granularity level, then he also has the right to access the lower granularity levels of that resource

Operation Assignment(OpA) – each operation could be associated with many resources, and for each resource could be granted to many operations

Context-Aware Access Control (XV)


CAAC Model Concepts (relationships) Context-Aware User-Role Assignment(CAURA) – a many-to-many

mapping between a set of users and roles, when a set of dynamic contextual conditions are satisfied

Context-Aware Role-Permission Assignment(CARPA) – a many-to-many mapping between a set of roles and permissions, when a set of dynamic contextual conditions are satisfied

Context-Aware Access Control (XVI)

CAUR

CARP


Context-Aware Access Control (XVII)

Figure: CAAC Model

Context Ontology

Policy Ontology


Advantages dynamic access permissions (dynamic access control decision

making) dynamic user-role and role-permission assignments efficient model in today’s dynamic and context-aware environments

Disadvantages implementation efforts

Context-Aware Access Control (XVIII)


Access Control AM ACL RBAC ABAC XACML CAAC

Review


Semantic Web Semantic Technology Ontology Concept OWL, DL and SWRL Ontology-Based Framework for Access Control XACML-Based Framework for Access Control XACML for RBAC

Next


ABAC, Core XACML – attribute-based RBAC – role-based

CAAC – ?

Questions?


ABAC, Core XACML – attribute-based RBAC – role-based

CAAC – role- and attribute-based

[email protected]

(dblp: A. S. M. Kayes)

Questions?

https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&sqi=2&ved=0CCoQFjAA&url=http://www.informatik.uni-trier.de/~ley/pers/hd/k/Kayes:A=_S=_M=&ei=NtFtU46FI9Crrgek_oD4AQ&usg=AFQjCNH1S7Yal4bylYbJtmtA_GSz76fbSg&sig2=qBjlGMDQ1cecnOz-c9mhhg





COS 80011 Web Application Architectures Lecture 10 Access Control.

Documents

Transcript of COS 80011 Web Application Architectures Lecture 10 Access Control.