gennaro orizzonte
lacpi: lightweight
context-aware access control
system for cyber-physical
resources
laurea in ingegneria informatica
per la gestione d’azienda
Relatore: Prof. Gianluca Dini Correlatore: Ing. Alessio Bechini Correlatore: Ing. Michele Ficarra Università di Pisa
Scuola di Ingegneria
Dipartimento di Ingegneria dell’Informazione 2 ottobre 2014
“Se puoi sognarlo, puoi farlo.”
A B S T R A C T
Pitagora Project is carried out by 8 partners (1 LE, 5 SME, 2 RC) and tackles the main issues of airport management: collaboration, resource management, and crisis. The project will design, develop and test a prototype to create an innovative platform for an efficient and integrated management of airport infrastructures.
The goal of this thesis is the implementation of a software system which is capable of managing a privacy-aware access control system, based on in-formation retrieved from a critical infrastructure, such as an airport. More specifically, Università di Pisa, as partner of Pitagora Project, has been asked to deal with resources having high performance requirements, such as PTZ cameras, in order to grant or deny an authorization to control them on a fine-grained level.
Among all the existing access control models which had been analyzed, we selected the Context-Aware Access Control Model as the reference model. We then analyzed the technological solutions which are already available, starting with the de facto standard, XACML, and we evaluated whether an innovative approach such as OAuth 2.0 is able to satisfy our requirements.
Given the architectural complexity of both solutions and the strict per-formance requirements, we opted for a fine-grained and lightweight access control, introducing a new policy definition language formalized using the Backus-Naur Form (BNF) and actually implemented in XML code.
We also designed an evaluation method to take into account both the op-erative scenario and a reference architecture, that could be used as a generic access control solution for physical and cyber resources.
The reference model was implemented in collaboration with Thales Italia, using an extremely modular approach in order to decouple all modules from a functional and data representation standpoint.
The performance analysis showed the quality of our solution. More specifi-cally, in our reference scenario, our solution resulted more than 7 times faster than the XACML implementation.
People often represent the weakest link in the security chain and are chronically responsible for the failure of security systems. — Bruce Schneier, Secrets and Lies Experience is what you get when you didn’t get what you wanted. — Randolph Frederick Pausch, The Last Lecture
A C K N O W L E D G M E N T S
Dopo aver redatto più di cento pagine, sono arrivato a redigere le uniche che tutti coloro che prenderanno in mano quest’elaborato leggeranno.
“Cosa vuoi che sia, ormai il grosso l’hai fatto!!” penserete, ma invece non vi nascondo che in questo momento l’emozione è palpabile: mi stanno venendo in mente una marea di persone e di situazioni di cui vorrei raccontarvi.
Se ringraziassi singolarmente tutti coloro che nel bene (ed anche nel male) hanno contribuito alla mia crescita personale e professionale, probabilmen-te dovrei effettuare un’altra pubblicazione dedicata esclusivamenprobabilmen-te all’argo-mento.
Dunque, visto che non sono quattro parole scritte su un pezzo di carta a testimoniare la mia riconoscenza, sappiate soltanto che siete parte integrante della mia vita e resterete indelebili nei miei ricordi e nelle mie emozioni. È nella testa e nel cuore delle persone che si vive per sempre, non vedendo il proprio nome scritto su una Tesi. E voi, se stringete in mano questo elaborato, siete proprio lì.
Non posso però esimermi dal ringraziare la mia famiglia: ha creduto in me, mi ha “supportato” e “sopportato” affiancandomi nei momenti di difficoltà e sconforto, ma che soprattutto ha fatto e sta facendo enormi sacrifici per darmi quest’opportunità! Anche se non lo dimostro la mia stima e riconoscenza è pressoché illimitata.
Concludo porgendo il mio più sentito ringraziamento a coloro che (anche velatamente) non hanno creduto in me e che mi hanno ostacolato: mi avete reso più forte e combattivo, rendendomi capace di attingere a piene mani nel-le vasche della buona volontà e dell’abnegazione, con nel-le quali sono arrivato alla conclusione di questo lungo ed impegnativo percorso.
Pisa, 2 ottobre 2014 G. O.
C O N T E N T S
a b s t r a c t v
1 t h e p i ta g o r a p r o j e c t 1
1.1 Platform Vision 1
1.2 Effectiveness and Efficiency 2
1.3 How to make value 3
1.4 Architecture Design 4
1.4.1 Business Architectural Design 5
1.4.2 System Architectural Design 7
2 a c c e s s c o n t r o l m a na g e m e n t i n i t a i r p o r t s y s t e m s 11
2.1 Problem Description 11
2.1.1 Organizations Involved 12
2.1.2 Resources’ Identification 13
2.2 Operational Scenarios 16
2.2.1 Not Authorized Access 17
2.2.2 Fire at the Airport Terminal 17
2.2.3 Pandemic Disease 19
2.2.4 Aircraft Accident 20
3 a na ly s i s o f t h e s tat e o f a r t o f a c c e s s c o n t r o l m o d e l s 23
3.1 ACL - Access Control List 23
3.2 RBAC - Role Based Access Control 25
3.2.1 TRBAC - A Temporal Role-Based Access Control Model
27
3.3 ABAC - Attribute Based Access Control 27
3.4 PBAC - Policy Based Access Control 29
3.5 CAAC - Context-Aware Access Control 30
3.5.1 Context Definition 30
3.5.2 Context-Aware Access Control Model Survey 30
4 a na ly s i s o f t h e ava i l a b l e t e c h n o l o g y s o l u t i o n s 33
4.1 XACML - eXtensible Access Control Markup Language 33
4.1.1 XACML Architecture Overview 34
4.1.2 XACML Language Structure 36
4.2 OAuth 2.0 Authorization Framework 39
4.2.1 Protocol Flow 40
4.2.2 Authorization Grant 40
5 l a c p i: lightweight access control system by unipi 45
5.1 Scope 45
5.2 Requirement Analysis 45
5.2.1 Rule and policy combining 46
5.2.2 Combining algorithms 47
5.2.3 Multiple subjects 47
5.2.4 Policies based on subject and resource attributes 47
5.2.5 Multi-valued attributes 48
5.2.6 Policies based on resource contents 48
5.2.7 Operators 48
5.2.8 Policy distribution and Policy indexing 49
5.2.9 Abstraction layer 49
5.2.10 Actions performed in conjunction with the policy en-forcement 50
5.3 Policy Design 50
5.3.1 Definition 50
5.3.2 Formal Description of the Policy 51
5.3.3 Policy Design Problems 57
5.4 Policy Evaluation Method 58
5.5 Usage Example: A simple case study 60
6 t h e p r o p o s e d a r c h i t e c t u r e 63
6.1 Architectural design guidelines 63
6.1.1 Modularity and Maintainability 63
6.1.2 Flexibility 65
6.1.3 Reusability 65
6.2 Architectural Model 66
6.3 Description of the components 66
6.3.1 Policy Manager 68
6.3.2 Context Manager 68
6.3.3 Access Control Engine 68
6.4 Data Flow Description 68
7 d e s c r i p t i o n o f t h e i m p l e m e n t e d s o l u t i o n 73
7.1 Description of the development environment 73
7.1.1 Pitagora Reference Architecture Description 73
7.1.2 The middleware layer: Enterprise Service Bus (ESB) and OSGi Framework 75
7.2 Overview of the technologies used 78
7.2.1 JEXL - Java EXpression Language 78
7.2.2 JAXB - Java Architecture for XML Binding 79
7.2.3 Google Web Toolkit 79
7.2.4 Maven 80
7.3 Developed Solution Overiview 81
7.4 Ptz Control Data Model 81
7.4.1 Policy Configuration File Model 81
7.4.2 Condition List Structure and Logical Expression Model 83
7.4.3 Exception Model 90
7.5 Policy Manager 91
7.5.1 Data Model 91
c o n t e n t s xi
7.6 Context Manager 92
7.6.1 Data Model 92
7.6.2 Functionality Overview 94
7.6.3 How it works 96
7.7 Access Control Module 97
7.7.1 Data Model 97
7.7.2 How it works 108
7.7.3 The Access Control Decision on Pitagora Platform 110
8 p e r f o r m a n c e a na ly s i s 113
8.1 Description of testing environment 114
8.2 Analytical evaluation of the performance of LACPi 115
8.2.1 Analytical evaluation by Policy Increase 116
8.2.2 Analytical evaluation by Access Rule Increase 118
8.2.3 Analytical evaluation by Reference Policy 119
8.3 Comparative analysis: LacPi vs XACML 122
8.3.1 The test set 122
8.3.2 The test architectures 123
8.3.3 Test Results 124 8.4 Usability Analysis 126 8.4.1 Webapp demonstrator 127 9 c o n c l u s i o n a n d f u t u r e w o r k 129 i a p p e n d i x 131 r e f e r e n c e s 142
l i s t o f f i g u r e s xiii
l i s t o f f i g u r e s
Figure 1 Pitagora High Level Operational Concept 3
Figure 2 Airport Operational Objectives View 5
Figure 3 AIP Capabilities View 7
Figure 4 Layers of the SOA Reference Architecture: Solution View 8
Figure 5 Soa Actors Schema 9
Figure 6 Overview of Entities and Stakeholders organization 13
Figure 7 Fixed Surveillance Camera Component 14
Figure 8 An example of AXIS
ptz
Camera 15Figure 9 Standard Situation Scenario Constraints 16
Figure 10 Not Authorized Access Scenario Constraints 17
Figure 11 Fire Alarm Scenario Constraints 18
Figure 12 Pandemic Disease Scenario Constraints 20
Figure 13 Aircraft Incident Scenario Constraints 22
Figure 14 POSIX Access Control Lists Example 24
Figure 15 ABAC Architecture 28
Figure 16 XACML Data-flow diagram 35
Figure 17 PolicySet, Policy and Rule UML Relationship Diagram 36
Figure 18 OAuth 2.0 Protocol Flow 40
Figure 19 OAuth 2.0 Authorization Code Flow 42
Figure 20 LACPi Functional Diagram 59
Figure 21 LACPi Evaluation Flow 60
Figure 22 LACPi Reference Architecture Deployment Diagram 67
Figure 23 LACPi Start Up Procedure Sequence Diagram 69
Figure 24 Access Control Decision Sequence Diagram 70
Figure 25 Pitagora’s software layers 74
Figure 26 Modular Design 75
Figure 27 OSGi Hot Deployment Example 77
Figure 28 Modular Architecture Explaination 77
Figure 29 PTZ Context-Aware Access Control System Deployment
Diagram 82
Figure 30 Configuration Hierarchy Model 83
Figure 31 Policy Hierarchy Model 84
Figure 32 Access Rule Hierarchy Model 85
Figure 33 Logical Expression Hierarchy Model 86
Figure 34 Logic Operator Structure Model 87
Figure 35 Logic Operand Structure Model 88
Figure 36 Access Control Exception Model 90
Figure 37 Context Model 93
Figure 38 Pitagora Fire Alarm 93
Figure 39 Context Manager Interaction Diagram 96
Figure 40 Conceptual Policy Tree Model 98
Figure 41 Policy Tree Data Model 99
Figure 42 Decision Tree Growing 100
Figure 44 Policy Element Data Model Hierarchy 103
Figure 45 Resource Model Structure 104
Figure 49 Condition Data Model Hierachy 106
Figure 53 Access Control Module Composition Diagram 108
Figure 54 PTZ Control Startup Phase 109
Figure 55 Pitagora Platform HMI: Ptz Control Widget 111
Figure 56 The decisional process of Access Control Engine 112
Figure 57 LACPi Test Architecture 114
Figure 58 LACPi Startup time by Policy Increase Chart 117
Figure 59 LACPi Response time by Policy Increase Chart 118
Figure 60 LACPi Loading time by Access Rule Increase Chart 119
Figure 61 LACPi Response time on Access Rule Increase Chart 120
Figure 62 XACML Test Process 123
Figure 63 Response Time by Policy Increase - LACPi vs XACML
125
Figure 64 Response Time by Policy Increase - XACML vs XACML with Request 125
Figure 65 Response Time by Access Rule Increase - LACPi vs
XACML 126
Figure 66 Response Time by Access Rule - XACML vs XACML with Request 126
Figure 67 LACPi Test Application 128
l i s t o f ta b l e s
Table 1 LACPi Loading end Evaluation time by Policy Increase 117
Table 2 Loading time of XML Configuration file by Policy In-crease 117
Table 3 LACPi Loading end Evaluation time by Access Rule Increase 119
Table 4 LACPi evaluated against Reference Policy 121
Table 5 Identity Service Avg. Response Time 122
Table 6 Response Time by Policy Increase - LACPi vs XACML
Comparison 125
l i s t o f l i s t i n g s
Listing 1 XACML Base Policy Structure 38
Listing 2 LACPi Configuration Structure 60
Listing 3 An example of annotated class: LogicalExpression 89
1
T H E P I TA G O R A P R O J E C T
Airports are complex scenarios populated by a wide community of work-ers belonging to different business units or different companies: today, the business of airports management is mature in dealing with such complexity when operations and procedures are planned in advance, and airports are run in regular or expected irregular conditions.
However, during unplanned and unusual situations, airports are not ef-ficiently managed and consequences may range from minor ones such as blocking airport activities with a negative economical impact, up to the risk of human losses during crisis events. The purpose of Pitagora Project is to support the Airport environment in managing unusual and unpredicted conditions and ease and decrease costs of normal daily operations.
Pitagora achieves that by supporting the working community populating
the airport environment with data communication technology and smart in-tegration and automation of sub-systems which enhance flexibility, ease co-ordination and reduce the need of extensive plans and agreement among the different companies involved.
To deal with these challenges the Pitagora Project was born. It consists of Project Innovative technologies and processes for airport management, and is a project co-financed by the Regional Government of Tuscany (POR CReO - Bando Unico R&S 2012) and the European Regional Development Fund
(ERDF).
Pitagora is carried out by 8 partners (1 LE, 5 SME, 2 RC) and tackles the
main issues of airport management: collaboration, resource management, cri-sis. The project will design, develop and test a prototype to create an inno-vative platform for an efficient and integrated management of airport infras-tructures.
1
.1
p l at f o r m v i s i o n
The Pitagora Platform is a ”System of Systems’’ dedicated to airport oper-ations management. It is an Airport Integration Platform (AIP), a software environment which provides support for data communication technology and smart integration and automation (Business Processing Management) of sub-systems which enhance capabilities of handling the complexity of airport environments.
With the Platform is possible to enable an efficient and fluent coordina-tion and collaboracoordina-tion among flight operacoordina-tions, passengers and bags man-agement, security supervision, incidents resolution, business and assets ad-ministration within the airport.
Through AIP, users cooperate in managing passengers travelling within the airport with optimized resource allocation and enforcing security, be-cause it provides information on airplanes, passengers and goods flows, al-lowing the plan and supervision of their movements and the reporting of anomalies to security staff. It exchanges information among systems and op-erators and integrates sub-systems data and automated business processing. During unusual conditions, with airport priorities changing, every opera-tor using an AIP user interface on fixed or mobile terminals, is always able to quickly react by retrieving in real time up-to-date information on the overall situation, on his own tasks and instructions on how to execute them.
The Platform is used on operators’ workstations installed on the Control Center, as well as on other terminal devices belonging to other airport staff (at the gates, at the check-in desks, in screening and baggage handling ar-eas, in other airport facilities) as well as on mobile devices of the airport workforce.
AIP is a suite of IT services and customized user interfaces which runs on standard hardware components and uses standard technologies (server and client workstation computers, wall monitors, next generation mobile devices, Web based user interfaces, open protocols, standardized video flows, shared services and G.I.S1
cartography).
1
.2
e f f e c t i v e n e s s a n d e f f i c i e n c y
The Airport Integration Platform has a value for customers, because man-aging the community of workers and stakeholders who populate a modern airport is complex without integration.
But most information is not readily available when it is necessary to take decisions, especially in unusual situations.
Stakeholders find it easy, comfortable and efficient to work using dedi-cated user interfaces. It is essential to focus on interaction among people: it establishes a social network among the airport companies’ employees where communication of orders and duties is unambiguous, instructions are fast to follow and execute, goals and procedures are clear and everything is moni-tored in real time by supervisors. Staff roles become flexible and their alloca-tions can change in real time.
With the Pitagora Platform it is possible to handle the whole airport sys-tem with immediate effects, without being constrained to rigid procedures which do not find applicability out of ordinary situations.
The Platform is finely customized for each specific customer: every airport has different needs, different companies are involved and stakeholders have 1 A geographic information system is a computerized data management system used to cap-ture, store, manage, retrieve, analyze, and display spatial information. Data captured and used in a GIS are commonly represented on paper or other hard-copy maps. A GIS differs from other graphics systems because data are georeferenced to the coordinates of a particular projection system and this allows precise placement of features on the earth’s surface and maintains the spatial relationships between mapped features. As a result, commonly refer-enced data can be overlaid to determine relationships between data elements. [Chr99]
1.3 how to make value 3
different organizational models. The priority on the solution development is to reach a modularity level so that it is easy to provide an AIP solution adapted to specific airport parameters, such as airport organization and size, number and qualification of employees, number of passengers per year and airlines to serve. Platform core components have good quality and follow best architectural and design patterns so that it is easy to reuse them and customize the solution for the real airport needs.
The customer who buys an Airport Integration Platform finds that the efficiency and productivity of his employees are improved, less skills and less training are needed, and it is cheaper to serve passengers and companies using the airport services.
1
.3
h o w t o m a k e va l u e
The key to ensure value flow to customers is the understanding of customers requirements. Understanding what they need and when it is required its essential to manage a proper flow.
Figure 1: Pitagora High Level Operational Concept.
Pitagora Platform focuses on enabling collaboration and communication be-tween actors of different business units and different companies populat-ing an Airport by providpopulat-ing applications for information sharpopulat-ing, situation awareness and collaborative decision making.
Pitagora Platform monitors the status and health of Airport systems so to provide a complete picture of the situation and the reporting and analysis tools for Airport administration. To handle such amount of data, the plat-form provides a business processing and decision support framework, which automates events and data processing and provides interactive interfaces to selected users for collaborative decision making.
The Platform provides full security supervision and crisis management ap-plications to authorized users, enabling the management of alarms and inci-dents with the integration of unique information from systems and human work force within the Airport, so to manage unusual situations by providing or consuming information on the platform.
PITAGORA will guarantee to airports:
• An increase of the structure efficiency in terms of flights and traffic flow;
• A more efficient management of energetic and human resources, real time weighted on the basis of various work load and scenarios;
• The identification of the most critical parameters for the process man-agement and a consequent optimisation of the manman-agement itself; • The minimisation of reaction time in case of crisis with precise methods
for the management of different scenarios.
To achieve the goal, Pitagora Platform provides to the Airport community a suite of software applications and common software services. It integrates Airport information and adopts open standards that enable a coordinated management of flights, passengers and baggage handling operations, com-bined with security supervision, crisis management functionalities and sup-porting business and assets administration.
The information available on AIP is finally reused to improve passenger experience, by providing on new media devices updated information on the Airport situation, for entertainment, travelling or safety purposes.
1
.4
a r c h i t e c t u r e d e s i g n
The main task of an Airport is to manage passengers, aircrafts and goods transiting through it, ensuring security and safety and optimizing costs and revenues.
The Airport is owned by and Airport Company which has financial objec-tives. With the growing complexity of airports and traffic, the need to be supported by flexible data integration, communication and automation plat-form that exploits workers abilities and efficiency in managing both ordinary and extra-ordinary activities gains even more importance.
AIP is engineered as a Service Oriented Architecture (SOA): the system design is built on the concept of Services and on their interfaces. A Service-oriented Architecture (SOA) facilitates the creation of flexible, reusable assets for enabling end-to-end SOA-based business solutions.
The concept of service is considered here as the point where business and development meet. Different focus, but their activities are complementary:
1.4 architecture design 5
• Business considers the service in terms of people, processes and tech-nology;
• Development considers the service in terms of application code provid-ing an interface;
1.4.1 Business Architectural Design
The Airport Integration Platform is developed from the viewpoint of the Airport Company, which is the major stakeholder as it is the one directly man-aging the airport, collecting fees for services and facilities usage, sustaining costs for ensuring security and safety, and so the most involved in usage and maintenance of the product.
The diagram in figure2shows the breakdown of the goals that an Airport
Company intends to reach and which are supported by AIP. The operational objectives are enduring, they do not easily change over time.
Figure 2: Airport Operational Objectives View.
The following capability2
goals have to be supported by the AIP architec-ture:
c o l l a b o r at i o n
AIP establishes a true collaboration within the airport community, cross-ing the barriers of havcross-ing different business units and different compa-nies working in the same environment with different financial goals. Thanks to that collaboration, the procedures are easier to be used and running costs are decreased. The final goal of this collaboration is to en-sure an optimal service for the final passenger, minimizing unexpected service inefficiency which damages the overall reputation of the airport business.
i t a i d e d s a f e t y a n d s e c u r i t y
AIP exploits the full potential of IT Aided Safety and Security, includ-ing incident and crisis management, by crossinclud-ing the barriers of simply having integrated technical systems which perform simple actions on simple events. It has to support Security and Safety from low level alarms up to the management of workflow of incidents and crisis; that support has to reach and provide guidance to both airport work force and public. The key is to have Security and Safety engineered on the
human factor, providing user friendly services to both supervisor and supervised actors. The system has to contribute to the elimination of zones of informational “shadow”, where threats or priorities are hid-den and security and safety are not ensured.
r e p o r t i n g a n d a na ly s i s
AIP improves operational performance and efficiency by Reporting and Analysing the indicators and parameters evolution over time and sup-porting both short term consequences and long term planning of the airport business. The key concept of the modeling of parameters is to support the financial and economical aspects of the airport.
h e a lt h a n d s tat u s m o n i t o r i n g
By monitoring Health and Status the goal is to ensure and forecast availability and integrity of functionality, based on current, planned and statistical data about usage and maintenance. The Health and Sta-tus information has to encompass the whole airport systems and has to be consumed on centralized control basis, so to enable the inspection of cross-system impacts and consequences and so an adequate reaction, both on an automatic business processing basis or by manual interven-tion.
au t o m at i c b u s i n e s s p r o c e s s i n g e na b l i n g
AIP decreases efforts of operating routines. It has to reduce the overall workload of operators, both by executing autonomously processes and supporting decision making particularly during crisis event.
c o m m u n i c at i o n t e c h n o l o g i e s p o t e n t i a l i t y
AIP exploits the full potential of the state of art of Communication technologies, taking advantage of the wide popularity of modern IT ca-pabilities, which means reduced costs for special purpose sub-systems. It also enables the development of services for security or travels, based on the availability of such technologies.
pa s s e n g e r e x p e r i e n c e e n h a n c e m e n t
AIP enhances the Passenger Experience, reducing the stress of travel-ling either by extending the set of services provided or by offering new attractive ones base on innovation or comfort. Popular new technolo-gies should be considered.
To reach Airport’s goals and objectives, AIP needs to support capabilities with certain functionalities and implementation of resources. By analysing objectives, it is possible to identify system capabilities.
In the following figure 3, a diagram depicts the high level capabilities for
the Platform.
2 A capability is defined as the ability to deliver a specified type of effect or a specified course of action. Capabilities are required by the organization in order to achieve operational objec-tives, and are not directly delivered by the system, which rather supports the organization in achieving its goal.
1.4 architecture design 7
Figure 3: AIP Capabilities View.
1.4.2 System Architectural Design
The Platform follows the Open Group’s SOA Reference Architecture as blueprint for services classification and layering. Reference Architecture is a key en-abler for the achievement of the value propositions of a Service-oriented Architecture. Figure4outlines the layers of this reference model.
1.4.2.1 Service Oriented Architecture Overview
Service Oriented Architecture (SOA) is an architectural model for the cre-ation of systems residing on a network, which focuses on the concept of service. It is an evolution of distributed systems, created to integrate various systems, generally heterogeneous.
Abstractly, SOA can be considered as an architecture whose purpose is to obtain a decoupling among software agents interacting between them.
It is important to understand that SOA is a paradigm, a concept, a phi-losophy, and not, as erroneously believed, something real and immediately
Figure 4: Layers of the SOA Reference Architecture: Solution View.
usable. Is just a reference line to follow, a way of thinking that provides a guide for designing real architecture.
A formal definition is provided from the Organization for the Advance-ment of Structured Information Standards (OASIS) in the technical commit-tee specification [Est+09]:
SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations
A system built according to this paradigm, consists of applications, called services, well-defined and independent from each other, that reside on several computers in a network.
A service is intended as a unit of work, executed by a particular provider,3 to satisfy a particular need for a consumer of that service, who makes explicit request.
Each service provides a specific functionality and can use those other ser-vices have made available, creating, in this way, applications of greater com-plexity. Both roles of supplier and consumer of the service are covered by soft-ware agents on request of their implementers.
The architecture needs the presence of three actors:
• Service Provider • Service Consumer • Service Registry
1.4 architecture design 9
Figure 5: Soa Actors Schema.
The Service Provider is the software entity that provides a set of features, then is a service. To make this service available to who needs it, it must be reachable in the network, i.e published. For this purpose, there are the Service Registry, that collect the information relating to the service it provides.
The Service Registry, therefore, maintains the information, such as URL, access information, etc.. of all services available.
When a Service Consumer wants to use a service, make a request to the Service Registry, which will provide all the information relating to it. At this point, the consumer, can communicate directly with the Provider.
SOA, therefore, only defines the guidelines and specifications to which the components of the system must follow in order to define an architecture for this service model.
Among the technologies to build a SOA, to date, the Web Services (WS), which will be dealt in the follow, is definitely the most used.
3 General term for a (part of a) system that has the role of offering ("providing") a service, which might then be used/called by different consumers.
2
A C C E S S C O N T R O L M A N A G E M E N T I N I T
A I R P O R T S Y S T E M S
“The framing of a problem is often far more essential than its solution." Albert Einstein This quote does illustrate an important point: before jumping right into solving a problem, we should step back and invest time to improve our understanding of it. The definition of the problem is the focal point of all problem-solving efforts and this chapter aims to give comprehension of the details, analyze inferences, get to the fundamental facts and guide statements to get a solution.
2
.1
p r o b l e m d e s c r i p t i o n
The Pitagora Platform manages sensitive and personal data. There is a plethora of stakeholders who are interested in accessing these data. Of course, the ac-cess to these data must be granted, or denied, according to a strict security policy aimed at guaranteeing people privacy.
First of all, the security policy must be able to adapt to different situa-tions. An obvious form of adaptability is the country where the platform is deployed. Actually, different countries may have a different perception of privacy.
Second, the policy may not only depends on the subject and the resource but also on the context. For instance, the policy should take into considera-tion the changing operating condiconsidera-tions: in normal condiconsidera-tions, the policy may deny a certain subject’s access to a given resource. Such access can be instead granted in an emergency condition.
For example, considering that the Platform is able to receive real time po-sition data of aircrafts and service vehicles from the SMGCS,1
in a normal situation, the fire brigade, or the medical service may be denied to access the location of service vehicles, the identity of related drives, as well as any data related to them. However, in case of emergency, the access to these data must be granted in order to optimize the first rescue team operations.
Third, a grant/deny security policy could be too strict. More precisely, in traditional access control systems the access to all information is either 1 An airport Surface Movement Guidance and Control System (SMGCS) involving detection, in-tegrated processing and graphical display of the relevant, in particular the safety-relevant, positions and movements of aircraft, and optionally, vehicles, on airside (runway, taxiways, apron) and in the relevant airport airspace. At least one radar detects the positions and move-ments between airborne and parked positions of the aircraft. The relevant data are displayed after data concentration on the monitor of at least one controller station in graphical form and/or letter or number form [Cas+01].
granted or denied. However, in a complex system, forms of gradual grant-ing should be supported. Considergrant-ing again the above scenario, in normal operating conditions, the Airport OCC Operator must be able to access the position of a given service vehicle or operator. However, in this kind of sit-uation, a fine-grain knowledge of such information could be perceived as unnecessarily invasive from a privacy standpoint.
Therefore, the policy should specify that the access to a vehicle location has to be granted. The provision of such location is properly obfuscated to a certain extent in order to guarantee a normal level of privacy. However, in an emergency situation, the Airport OCC Operator needs a more precise, timely knowledge of the location of people and vehicles in order to effectively super-vise the rescue and recovery operations. Every stakeholder may experience different levels of obfuscations.
We will enrich Pitagora by means of a non-conventional access control system, that makes possible to flexibly and efficiently enforce an adaptable, context-based, gradual control of access to privacy-sensitive data. The system will be designed and implemented as a service consistently to the Service Oriented Architecture of the Pitagora platform.
2.1.1 Organizations Involved
The first step is the identification of the entities involved. The platform’s ar-chitecture targets the management of airport environment and so it involves the airport’s organization: the airport business is managed by an Airport Com-pany, whose employees provide services to Airlines Companies, Passengers and Goods transiting within the airport.
The Airport Company has to:
• ensure Safety and Security by involving National Police, Medical and Fire Brigate services within the Airport;
• comply with regulations under the supervision of the Civil Aviation Authority;
• manage subcontracting Third Party Companies which work inside the Airport field;
• achieve the financial goals of the Airport Owner.
When an IT solution is deployed within an airport, the above mentioned entities are directly involved by the main Airport Company and are impacted by the architecture of the platform.
The IT solution is developed from the Airport Company viewpoint, which is the major stakeholder since it is the one that directly manages the airport, collects fees for the services and facilities usage, sustains costs for ensuring security and safety, and so is the most involved in usage and maintenance of the product.
2.1 problem description 13
Figure 6: Overview of Entities and Stakeholders organization.
2.1.2 Resources’ Identification
In subsection2.1 it is presented a case where it is important to hide a data
for preserving privacy, or make it available to a user in order to improve its effectiveness. The example is referred to a “data”, in other words, a sequence of bit that represents an information. That represents a “cyber” resource, but in an airport there is a collection of Cyber-physical systems: sensor networks, radio frequency devices, etc.
Rajkumar et al. define in [Raj+10] Cyber-physical systems (
cps
) as “physicaland engineered systems whose operations are monitored, coordinated, controlled and integrated by a computing and communication core”.
The video surveillance is certainly the most popular
cps
, considered thatis a ubiquitous part in modern airport infrastructure.
All airports, even those of modest size, use different kind of cameras for different purposes:
• at all entrances and exits of the airport in order to capture images of people entering and leaving the airport;
• to cover all the open areas in order to obtain a continuous record of activities within the airport;
• around the areas of check-in from different airlines to obtain images related to the arrival of passengers and procedures for check-in and luggage delivery;
• at security controls to monitor congestion, suspicious activities, actual or potential clashes, and passengers who are potential threats;
• around tram or other transportations used to get to different areas of the airport;
• in all terminals and outputs, to monitor unusual activities and suspi-cious passengers during the boarding process;
• in the baggage halls to avoid theft and potentially dangerous objects; • to monitor the restricted areas and ensure the access only to authorized
personnel.
Surveillance systems should record what’s happening, 24 hours a day, ev-ery day. These video streams must be laboriously inspected by security per-sonnel in case of a severe accident, and must be continuously monitored, from the most innocuous situations, to the most critical ones, in which the optimization of airport operations can be further improved.
2.1.2.1 Fixed Cameras
The most common type of camera in surveillance environments is the one with fixed lens. These devices are relatively cheap, and can be distributed very easily to cover large areas (using a large number of different sensors). The arrival on the market of network cameras (IP cameras) has significantly reduced the difficulty of video cameras installation in every corner of the airport environments.
Figure 7: Fixed Surveillance Camera Component.
In fact, IP cameras, especially those with Power over Ethernet (PoE), re-quire minimal infrastructure for their installation. In addition to reducing the cabling and infrastructure necessary hardware, IP cameras offer more flexible ways to access it. Analog cameras need to send the analog flow to a dedicated server, in order to convert the signal from analog to digital, both for storage and for the analysis of the video. Instead, video streams from IP cameras can be directly stored, and multiple clients can simultaneously access to individual flows with much more ease.
The greater flexibility of IP cameras is one of the factors that facilitate the automatic analysis of the video content. The video may no longer be focused on the central server for processing or distribution, but individual streams
2.1 problem description 15
can be processed simultaneously by multiple analysis modules. Some man-ufacturers of cameras also offer a Software Developer Kit (SDK) that allows developers to implement analysis systems directly on the hardware of the camera.
The fixed cameras are the best choice for installation in a well-constrained or passage, where people do not tend to stand for long periods. Airport environments such as entrances and exits, or tram stations / trains, are typ-ical examples of installation scenario where fixed cameras can be used very effectively.
2.1.2.2
ptz
- Pan - Tilt - Zoom CamerasMany applications, such as Computer Vision, require high resolution images. For example, issues such as the identification of the car license plate or face recognition require a high level of detail over the interest area. This require-ment poses a problem with the zoom setting of a camera (i.e. control, in the case of active sensor).
Figure 8: An example of AXISptzCamera.
It becomes necessary to achieve two opposing objectives: to obtain the highest possible resolution of the object that is monitored, while minimizing the risk of losing it. Using a finite number of fixed sensors, there is however a fundamental limit to the total area that can be observed.
Maximizing both the coverage area that the resolution of each target ob-served thus requires an increase in the number of cameras installed. There-fore, these multi-camera systems have the disadvantage of being bulky and extremely expensive. So a system that uses a single sensor Pan-Tilt-Zoom (
ptz
) can be much more effective and economical if you are able to controlit properly in order to overcome the disadvantage given by having fewer sensors that observe the scene.
ptz
cameras (always in the IP network) and their low cost representan-other innovation that is changing the face of surveillance in the airport. In fact,
ptz
cameras are more suitable for application scenarios where the spaceto be covered is relatively large, but the number of people coming in and out is limited. Areas such as the arrival of baggage, where high-resolution im-ages of people and objects is essential for the assessment of possible threats, are particularly suitable for the implementation of systems based on
ptz
cameras.
Although
ptz
cameras offer higher resolution and overall quality of thetargets, the automatic use of these sensors requires sophisticated techniques for the control and localization of the camera. In fact, the automatic control of
ptz
cameras is currently a very active area of research.2
.2
o p e r at i o na l s c e na r i o s
This section gives a brief description of the operational scenarios through the existent process analysis and the definition of “Who”, can do “What”, “When” and “Where”, according to the Five W’s method.
The following tables define who are the actors involved, what operations can be made and under what constraints.
The operations considered are:
• View: the ability of watching the video stream of selected camera;
• Move: the ability to move camera using pan/tilt operations;
• Zoom: the ability to magnify/demagnify a subject;
• Preset: the ability of an operator to set the camera to automatically look at a certain area.
The scenarios are explained highlighting the differences from the “Stan-dard Operational Scenario”, detailed in Figure9.
View Move Zoom Preset
Police Officer Grant Deny Deny Grant
Airport OCC Op. Grant Grant Grant Grant
Duty Free Security Op.
Only in Duty Free Area, when shops are open.
e.g. 06-24
Only in Duty Free Area, when shops are
open. e.g. 06-24
Deny
Only in Duty Free Area, when shops are open. e.g.
06-24
Fire Brigate Grant Deny Deny Deny
Medical Center Op. Deny Deny Deny Deny
ACTORs NORMAL SITUATION
2.2 operational scenarios 17
2.2.1 Not Authorized Access
2.2.1.1 Process Overview
This scenario analyzes the management of a non-authorized access in a restricted area, via Pitagora Platform. The access violation is automatically detected by physical Access Control System (ACS) (e.g, forcing of a condi-tional access door) or can also be detected manually by Airport OCC Operator through the cameras.
The alarm is visualized by the Airport OCC Operator, that first alerts by phone the Police, asking them to check the real presence of access violation in the alarmed zone. In this case, the Police is responsible of capturing and identifying who committed it.
When the access violation is confirmed, the Airport OCC Operator, if the alarmed zone is a duty free area, starts by calling all Duty Free Security officers to support the localization of the suspect.
Once the Police declares that the alarm is ceased, it informs the Airport OCC Operator and the restore procedure is applied to set back to the normal airport operation.
2.2.1.2 Scenario Constraints
Let us consider now the application of the general guidelines outlined above, for Medical center Operators, firefighters and the Airport OCC Operator.
When an access violation is detected in a restricted area, the Police Officer is granted to slew cameras in full freedom, for identification purpose. For the proximity principle, if the area is under the Duty Free Operator jurisdiction, additional rights such as zooming are granted to the Duty Free Operator.
In Figure10 the scenario and the operations granted are detailed.
View Move Zoom Preset
Police Officer Grant Grant Grant Grant
Airport OCC Op. Grant Grant Grant Grant
Duty Free Security Op.
Only in Duty Free Area, when shops are open.
e.g. 06-24
Only in Duty Free Area, when shops are
open. e.g. 06-24
Only if Access Violation alarm is generated in Duty Free Area, when shops are
open. e.g. 06-24
Only in Duty Free Area, when shops are open. e.g.
06-24
Fire Brigate Grant Deny Deny Deny
Medical Center Op. Deny Deny Deny Deny
ACTORs NOT AUTHORIZED ACCESS
Figure 10: Not Authorized Access Scenario Constraints.
2.2.2 Fire at the Airport Terminal
2.2.2.1 Process Overview
A fire alarm is automatically detected by the Fire Alarm and Detection System (
fads
) (it can also be detected manually).The alarm is receipted by the Airport OCC Operator that first of all alerts by phone the airport fire brigades and the maintenance team asking them to
check the actual presence of fire in the alarmed zone. When fire is confirmed, the Airport OCC Operator starts by calling all the stakeholders involved in the fire emergency, in the following order:
• Fire brigades: who are responsible to manage the fire;
• Police: who is responsible to manage fire zone security and then be-comes responsible for the emergency procedures;
• Medical unit: which is responsible to manage injured people; • ATC: which is responsible to manage flight schedule disruptions.
Fire brigades ask for the evacuation of the terminal: Police gives start to the evacuation procedure with the collaboration of the airport personnel, and asks the Airport OCC Operator to play evacuation messages on the public announcement system.
The Airport OCC Operator activates the Public Announcement system (PA) and plays the evacuation messages in the alarmed zones.
Once Fire brigades declare the fire is extinguished, they can notify the Police that the airport can be restored. The Police informs the Airport OCC Opera-tor and the resOpera-tore procedure is applied to set back to the normal airport operation.
2.2.2.2 Scenario Constraints
In case of fire, the aim is to give the most possible freedom to the user re-sponsible for the resolution of the problem, namely the Fire Brigades.
The rights granted to the Airport OCC Operator derive from the need to allow the verification of the actual displacement by the airport.
The zoom is not granted to anyone except for the Police, as the identifying features are not necessary to get an overview.
The view rights are granted even to the Medical Center Operator, to better or-ganize rescue activities. Security policies for anti-shoplifting are suspended, except if the fire covers the Duty Free area.
In Figure11the scenario and the operations granted are detailed.
View Move Zoom Preset
Police Officer Grant Grant Grant Grant
Airport OCC Op. Grant Grant Grant Grant
Duty Free Security Op.
Only in Duty Free Area, when shops are open.
e.g. 06-24
Grated only if Fire Alarm is located out of
Duty Free Area, when shops are open. e.g.
06-24
Deny
Grated only if Fire Alarm is located out of Duty Free
Area, when shops are open. e.g. 06-24
Fire Brigate Grant Grant Grant Grant
Medical Center Op. Grant Deny Deny Deny
ACTORs FIRE ALARM
2.2 operational scenarios 19
2.2.3 Pandemic Disease
2.2.3.1 Process Overview
The Aircraft pilot alerts the Air Traffic Controller (
atc
) to inform that apassen-ger (or more than one) presents the symptoms of a pandemic disease.
atc
calls the Airport OCC Operator to report the pandemic alert for the specific flight that is expected to land in the airport.
The Airport OCC calls the National public health authority (
usmaf
) to informit about the pandemic alert.
usmaf
is in charge of coordinating the emergency situation.First of all it evaluates the level of pandemic alarm (unless it is not already defined) and then activates all the stakeholders involved:
• Medical service
• Airport direction
• Airlines
• Airport OCC
The Airport direction starts managing media and public information. The
usmaf
can also require the Airport OCC Operator to allocate aquaran-tine aircraft stand for the inbound flight. The Airport OCC allocates the new stand and communicates it to the
atc
. Theusmaf
asks the Airport OCCOperator to set up the “health route”: the Airport OCC Operator organizes the health routes and reserves/delimitates dedicated areas for the management of ill passengers. Once the aircraft is landed and parked in the quarantine stand, the medical screening process is started.
The Airport OCC Operator coordinates airlines to manage passengers from the inbound flight, and asks the medical unit to perform medical screening tasks.
At the end of the medical screening, the Airport OCC Operator reports to the
usmaf
and the airport direction their results.2.2.3.2 Scenario Constraints
In case of a Pandemic Disease, the aim is to give the highest possible freedom of action to the user responsible for the resolution of the problem, namely the Medical Center Operator.
The rights granted to the Airport OCC Operator derives from the need to allow the verification of the implementation of the “health route”.
The security policies for the purposes of anti shoplifting are suspended altogether, and the Police authority is set back to standard events.
View Move Zoom Preset
Police Officer Grant Deny Deny Grant
Airport OCC Op. Grant Grant Grant Grant
Duty Free Security Op.
Grant Only in Duty Free Area, when shops are
open. e.g. 06-24
Deny Deny Deny
Fire Brigate Grant Deny Deny Deny
Medical Center Op. Grant Grant Grant Grant
ACTORs PANDEMIC DESEASE
Figure 12: Pandemic Disease Scenario Constraints.
2.2.4 Aircraft Accident
2.2.4.1 Process Overview
This scenario describes the management of an aircraft accident assuming that the pilot communicates the Air Traffic Controller (
atc
) a technical problem onan aircraft.
The communication received by the
atc
triggers the emergency status;the aim of this phase is to plan and manage, based on the received informa-tion, the incident one that will follow when the aircraft will land. When the emergency is activated, different stakeholders will be involved to manage the events. Below a brief description is presented for the sequence of events, with the responsibilities of the main stakeholders.
The
atc
will activate the emergency through the Crash alarm system (ifavailable) or communicate with other stakeholders by dedicated telephone lines.
atc
will, in case of emergency:• communicate the emergency to the Fire Brigades, the Airport TLO,
cmt
, Police and Medical Services by phone or via crash alarm system;• in case of ground emergency, mute radio communications, stop aircraft departing and close the airport by diverting arriving aircrafts;
• in case of emergency with inbound flight, mute radio communications, organize ground movements in order to ensure the availability of the runway to the inbound aircraft, stopping departing and arriving air-crafts;
• give authorization to the Fire Brigades to get access to the maneuvering area with service vehicles to manage the incident.
As soon as the aircraft will land, the emergency status will be changed in an incident.
The Crisis Mangement Team (
cmt
) will manage the incident and all theneeded activities by coordinating the stakeholders. The
cmt
has the mainresponsibility of coordinating and managing the crisis event based on the updated information received; the
cmt
will also manage the relations withthe press and media.
2.2 operational scenarios 21
• Fire Brigades representatives • Medical Services representatives • Airport representatives
• Airport Police representatives • Embassy representatives
• Local and Regional government representative • Airlines
atc
, as soon as the aircraft is landed, will inform the involvedstakehold-ers providing detailed information on incident time, aircraft type and posi-tion of the aircraft on the runway. Each stakeholder, involved in the Emer-gency plan, will have its own responsibilities and will report directly to the
cmt
. A list of stakeholders and or main duties is detailed below:• Fire Brigades: will have the responsibility of managing the rescue ac-tivities on the field; based on the real time information on the accident scene the Fire Brigades will communicate with the
cmt
, report updatesand define the need of medical services if required. The Fire Brigades, after the first phase of the incident, plan and arrange the access of medical vehicles/ambulances and define the area used for non-injured passengers.
• Airline: is mainly involved in the management of passengers’ families and, during the first phase of the incident, communicates the passen-gers list to the Police and removes this critical information from Airport IT systems. The Airline staff, in coordination with the Airport Staff and the Police, will also provide support to the families. All the updates will be reported to the
cmt
where a representative of the Airlines isinvited.
• Medical Services: will manage and coordinate the medical needs, based on the updated information received from the Fire Brigades. Via
cmt
the airport medical service coordinates medical staff and vehicles/am-bulances.
• Police: manages the passengers list received by the Airlines. In conjunc-tion with airport staff, the Police has the responsibility of coordinating the access of all service/medical vehicles to the incident area. Finally, support is provided to monitor access rights and of the sensible areas, such as the press room and passengers families common area.
2.2.4.2 Scenario Constraints
In case of aircraft accident, the aim is to give highest possible freedom of action to the user responsible for ensuring public safety, namely the Fire Brigades and the Police Officer.
The rights granted to the Airport OCC Operator derive from the needs to allow the monitoring of relief operations. Zooming is not allowed to any user, with the exception of those in charge of coordination.
The view and move operations are guaranteed to the Medical Center Opera-tor to better organize rescue activities. The security policies for anti shoplift-ing purposes are suspended (Denied access to Duty Free Security Officer)
In Figure13the scenario and the operations granted are detailed.
View Move Zoom Preset
Police Officer Grant Grant Grant Grant
Airport OCC Op. Grant Grant Grant Grant
Duty Free Security Op.
Only in Duty Free Area, when shops are open.
e.g. 06-24
Deny Deny Deny
Fire Brigate Grant Grant Grant Grant
Medical Center Op. Grant Grant Deny Deny
ACTORs AIRCRAFT INCIDENT
3
A N A LY S I S O F T H E S TAT E O F A R T O F
A C C E S S C O N T R O L M O D E L S
Access control has been the subject of considerable research and develop-ments over the last 30 years. The
dod
5200.28-STD - Trusted ComputerSys-tem Evaluation Criteria, provided from USA Department of Defense and com-monly known as the “Orange Book” [Bra85] , defines two different types of access control:
discretionar y access control which restricts access to resources on the basis of the identity of the users. The most important feature of dis-cretionary access control is that each resource is required to have an owner, and the owner is able to control who can access the resources on his own.
mandator y access control which constrains the interactions of the users with the resources on the basis of security attributes associated with users and resources. A request from a user to access a resource is granted if certain inequalities comparing the security attributes of the user and the resource are satisfied. Unlike discretionary access control, changes in the authorization policies in mandatory access control are controlled by a higher authority, rather than individual users. In other words, system administrators define mandatory access control policies that can be centrally enforced for all users.
The role-based access control (
rbac
) is the first alternative to discretionaryaccess control and mandatory access control, because of its potential to re-duce the complexity and cost of access control administration. The basic idea of RBAC, as the name suggests, is to introduce the concept of a Role, which acts as a linker between users and permissions.
This chapter presents current access control models, including access con-trol lists, role-based access concon-trol, and the newest alternative as attribute-based access control and policy-attribute-based access control.
For the analysis of the strengths and weaknesses, it is based on the con-clusions of the Privilege (Access) Management Workshop held on 1-3 September 2009 at Gaithersburg, Maryland, facilities of the National Institute of Stan-dards and Technology (
nist
), sponsored bynist
and the National SecurityAgency (
nsa
) [SC09].3
.1
a c l
- access control list
As indicated in “
ietf
Internet Security Glossary, Version 2”[Shi07], AccessCon-trol List are a mechanism that implements access conCon-trol for a system resource by
enumerating the system entities that are permitted to access the resource and stating, either implicitly or explicitly, the access modes granted to each entity.
This definition is too general, but despite its haziness, Access Control List is the most widely used model of access control being used in operating systems such as UNIX and Windows. Windows Developer Support states that “an access control list (
acl
) is a list of access control entries (ace
). Eachace
in anacl
identifies a trustee and specifies the access rights allowed, denied, oraudited for that trustee. “[Cen14]
The concept is simple: each resource on a system to which access should be controlled, referred to as an object, has its own associated list of mappings among the set of entities requesting access to the resource and the set of actions that each entity can take on the resource.
A simple example is provided by UNIX-like operating systems. In a file system each file is associated to a data structure that holds the list of users that the operating system recognizes as a whole, along with a flag which indicates whether each user may read, write, execute, etc..
When an application or a user tries to perform an actions on the file, the op-erating system checks the file’s Access Control List and determines whether the requested action, for example read the file, is allowed. If the action is allowed for that application/user, the data is provided, otherwise the opera-tion fails.
Figure14shows an examples of POSIX Access Control Lists on Linux1.
Figure 14: POSIX Access Control Lists Example.
As indicated in [SC09], in cases where
acl
s need to be managed forhun-dreds of thousands or millions of users, and where in-memory data struc-tures do not scale well, databases may be used to store some of the ACL data.
3.2 rbac - role based access control 25
While widely used,
acl
s do have their limitations. The Access ControlList for a particular file, process, or other resource must be checked every time the resource is accessed, and it can be an inefficient means of providing access control.
Furthermore,
acl
s control not only user access to system resources; theyalso control application and system access as well. So in a typical computing session, the files a user tries to access perform
acl
lookups, the applicationshe tries to open perform
acl
lookups, the files and applications thoseap-plications open and modify perform lookups, and the system apap-plications perform lookups, and so on.
acl
s can also be difficult to manage in an enterprise setting where manypeople need to have different levels of access to many different resources. Selectively adding, deleting and changing
acl
s on individual files, or evengroups of files, can be time- consuming and error-prone.
3
.2
r b a c
- role based access control
Role-based Access Control (
rbac
) is an alternative access control model,re-spect to the
acl
paradigm.rbac
, is anist
standard, formalized in 1992by David Ferraiolo and Rick Kuhn [ST14].
rbac
is arguably the mostimpor-tant innovation in identity and access management since discretionary and mandatory access control [And01]. Unlike
acl
s, access to a resource isdeter-mined on the basis of the relationship between the requester and the owner of the resource, usually an organization. In other words, the requester’s role or function in the reference environment will determine whether access will be granted or denied.
The principle of controlling access entirely through “roles” created in the system that align to job functions, assigning permissions to those roles, and then assigning those roles to employees, seems obvious, but this approach not only is a model, but can be considered something to create value.
The Economic Analysis of Role-Based Access Control [ST10] of 2010, has an-alyzed the value of
rbac
for the enterprise and for the national economy.Report calculates savings from reduced employee downtime, more efficient provisioning, and more efficient access control policy administration, beyond the added security provided by
rbac
.nist
’srbac
research was estimatedto have contributed to increase the economic value up to $1.1 billion.
Role-based access control [FCK95] has emerged as the primary alterna-tive to discretionary access control and mandatory access control, because of its potential to reduce the complexity and cost of access control administra-tion in organizaadministra-tional systems. Therefore,
rbac
reduces the administrativecharge by introducing the idea of a role hierarchy.
The role hierarchy generally supports two different types of inheritance: permissions are inherited upwards and the set of roles available to a user is aggregated downwards.
For example, if role
a
is senior tob
in the role hierarchy, then anycan activate
b
. These two types of inheritance are called Permission usage andRole Activation respectively. In other words, a role hierarchy can be used to re-duce the number of explicit assignments in the user-role and permission-role relations
To clarify the notions presented in the previous section, we can summarize with three basic rules were required:
• Role assignment: A subject can execute a transaction only if the subject has selected or been assigned a role. The identification and authentica-tion process (e.g. login) is not considered a transacauthentica-tion. All other user activities on the system are conducted through transactions. Thus all active users are required to have some active role.
• Role authorization: A subject’s active role must be authorized for the subject. With the first above, this rule ensures that users can take on only roles for which they are authorized.
• Transaction authorization: A subject can execute a transaction only if the transaction is authorized through the subject’s role memberships, and subject to any constraints that may be applied across users, roles, and permissions. With first and second, this rule ensures that users can execute only transactions for which they are authorized.
Despite its many advantages (particularly when compared to the
acl
model),
rbac
has its own disadvantages. One of the most significant isindi-cated in [SC09]. The problem is that dividing people into categories on the basis of roles makes it more difficult to define granular access controls for each person. It is often necessary to create more specific versions of roles or devise other mechanisms to exclude specific individuals who fall into a particular role, but do not necessarily need to have the full rights accorded to other members of a group.
An example to understand the problem follows: let us consider a large organization, such as an airline which has subsidiaries all over the world. It might be necessary to split security officer employees across the various locations. Furthermore, it might be necessary to organize IT systems so that certain resources reside in particular locations with their own administration personnel. With such a setup, a generic “administrator” role might need to be decomposed into sub-roles on the basis of the type of resource to be ad-ministrated, and perhaps also based on the location that the resource serves. Giving to the administrator of Pisa site office the ability to administer IT systems at the New York headquarters might make sense; on the other hand, it might not. However, creating a generic role for IT Administrations, does not allow an easy differentiation between the two use cases, because in the second case undesired access to particular systems is granted.
To solve the problem we need the ability to differentiate individual mem-bers of a group and selectively allow or deny access on the basis of a granular set of attributes.
The Attribute-based Access Control (
abac
) model, presented in the3.3 abac - attribute based access control 27
3.2.1 TRBAC - A Temporal Role-Based Access Control Model
The importance of time-based access control requirements has been recog-nized only recently. The need for time-based access control requirement can be attributed to the growing relevance of process-based applications, particu-larly in e-commerce and web based application environments. Furthermore, the huge volumes of data available over the Internet based applications may have temporal characteristics which imply varying security risks or impor-tance to the available data. Such applications require support for time-based authorization policies [Jos+05].
Bertino et. al. in [BBF01], proposed a time-based access control model that supports temporal authorization and derivation rules, considered as an ex-tension of the
rbac
model that used periodicity expressions explained in[Ber+98]. It also provides formal semantics for the specification language.
trbac
supports periodic role enabling and disabling and temporalde-pendencies among such actions, expressed by means of role triggers. Role trigger actions may be either immediately executed, or deferred by an explic-itly specified amount of time.
The true innovation is the introduction of high level temporals operators (such as whenever or upon) to show temporal relations among temporal au-thorizations. However, the proposed model is not role based and so does not provide the benefits of
rbac
.3
.3
a b a c
- attribute based access control
Attribute Based Access Control (
abac
) is an access control model in whichthe access control decisions are made on the basis of a set of characteristics, or attributes, associated to the requester, the environment, and/or the resource itself. In [YT05] “attributes” are defined as “any security-relevant characteristics”. The ABAC Architecture is represented in figure15.
The architecture of eXtensible Access Control Markup Language, presented in section4.1, follows the same philosophy. The diagram reflects the following
logical actors involved in an ABAC model:
• Attribute Authorities (
aa
) are responsible for creating and managingthe attributes for subjects, resources, and the environment, respectively. As a logical entity, an AA may or may not store the attributes by itself (e.g., a Subject AA may choose to retrieve attributes from the organiza-tion’s LDAP directory), but it is responsible for binding attributes to an entity of interest, and plays an important role in the provisioning and discovery of attributes.
• Policy Enforcement Point (
pep
) is responsible for requestingautho-rization decisions and enforcing them. It is the point of presence for access control and must be able to intercept service requests between information consumers and providers. The most important security en-gineering consideration for the implementation of a
