Available online at www.sciencedirect.comScienceDirectAvailable online at www.sciencedirect.comProcedia Computer Science 00 (2016) ediaProcedia Computer Science 111 (2017) 260–2678th International Conference on Advances in Information Technology, IAIT2016, 19-22December 2016, Macau, ChinaContainer based testbed for gate security using open API mashupDongwoo Kwon, Hyeonwoo Kim, Donghyeok An, Hongtaek Ju*Department of Computer Engineering, Keimyung University, Daegu, Republic of KoreaAbstractIn this paper, we propose a container based testbed for the gate security system for a smart campus. The security systemincorporated two-factor authentication, ID card based identification and face recognition, and authorization which wereimplemented using an open application programming interface (API) mashup. We analyzed requirements to provide an efficientand flexible testbed to developers and testers working simultaneously. Then, we designed and constructed a container basedstructure to satisfy the requirements including lightweight virtualization technology and dynamic private domain namemanagement. Finally, we present the automation script to build the testbed and test the security system. 2015 The Authors. Published by Elsevier B.V. 2017 The Authors. Published by Elsevier B.V.Peer-review under responsibility of the organizing committee of the 8th International Conference on Advances in InformationPeer-review under responsibility of the organizing committee of the 8th International Conference on Advances in InformationTechnology.TechnologyKeywords: Container; gate security system; open API mashup; smart campus; testbed; virtualization.1. IntroductionWith the advance of virtualization technology, a number of information and communication technology (ICT)services have been developed based on server virtualization solutions, such as VMware vSphere1, Citrix XenServer2,Microsoft Hyper-V3, and Docker4. Virtualization technologies provide scalable hardware resource management toincrease hardware resource utilization, leading to cost reduction, efficient service operation, and productivityimprovement5.We have been developing a gate security system that combines ID card and face recognition based authenticationto strengthen security for a smart campus. The essential functions of a gate security system are user authentication* Corresponding author. Tel.: 82-53-580-5234.E-mail address: [email protected] 2015 The Authors. Published by Elsevier B.V.Peer-review under responsibility of the organizing committee of the 8th International Conference on Advances in Information Technology.1877-0509 2017 The Authors. Published by Elsevier B.V.Peer-review under responsibility of the organizing committee of the 8th International Conference on Advances in Information Technology10.1016/j.procs.2017.06.062

Dongwoo Kwon et al. / Procedia Computer Science 111 (2017) 260–267 Dongwoo Kwon et al. / Procedia Computer Science 00 (2016) 000–000261and authorization, and various open application programming interfaces (APIs) have been employed, such asFace 6, Lambda Labs7, Betaface8, and Kairos9 for face recognition and biometrics based user authentication; andStormpath10 for user management and authorization. This open API mashup enables us to meet the requirements ofhigh service quality for specific functions with low cost, while decreasing research and development spending.To develop and test the gate security system, we also built a testbed using Linux containers11,12 as thevirtualization technology. The gate security system consisted of eight modules, including face recognition, tagdetection, and role based access control (RBAC) modules. Each module is independent of the others to supportscaling, and data exchange between the modules is conducted via Java message service (JMS). Docker was used tobuild the testbed, because the containers, which share the kernel and part of the operating system (OS) without ahypervisor, have higher performance and scalability13,14 than virtual machines12. It also allows simultaneousexecution and testing of multiple module sets on a physical machine for a number of developers and testers, andfrequent start-up and shutdown operations of the module containers.For efficient and flexible development and testing of the gate security system, the testbed should provide dynamicdomain name management, interoperation of the software configuration management (SCM) system and testbed,integrated log analysis, public IP address assignment for the module containers, etc. This paper analyzes therequirements of the testbed in detail for a gate security system development using open API mashup. We design thecontainer based testbed structure to meet the indicated requirements, and describe the workflow between themodules in the testbed and external services. We discuss and implement the gss-test shell script to automaticallybuild the testbed using latest source codes.The rest of this paper is organized as follows. In Section 2, the gate security system using open API mashup isintroduced and discussed. Section 3 analyzes the requirements to build an efficient and flexible testbed. Thecontainer based testbed is designed based on the requirements, and the shell script is introduced. Section 4 reviewsrelated work regarding building testbeds, and we conclude the paper and discuss future work in Section 5.2. Gate security system using an open API mashupA gate security system provides physical security and its essential functions are authentication and authorization.We adopted two-factor authentication, ID card based identification and face recognition, to strengthen security. IDcard based authentication has very high accuracy and low complexity, but identity theft risk by acquisition andreplication. In contrast, face recognition, i.e., biometrics based authentication, has relatively less opportunity foridentity theft, but lower accuracy and very high complexity. Combining these authentication methods, the proposedgate security system reduces identity theft risk and retains high authentication accuracy.Open API services were employed to implement the face recognition module, including Face , Lambda Labs,Betaface, and Kairos. An IP camera deployed at the gate detects visitor’s faces, and captured images are stored in afile transfer protocol (FTP) server. The images are forwarded to the face recognition service platforms by an internetof things (IoT) adapter module. Face recognition APIs are then applied to images after combining using a simplethreshold based ensemble method. The open API mashup for face recognition enables us to use high performancealgorithms with low cost.For ID card based identification, tag detection and tag reader modules on an Arduino board15 were implementedusing the Open Connectivity Foundation (OCF) IoTivity framework16 for radio frequency identification (RFID) tags.The RBAC module for user authorization was implemented with two-factor authentication utilizing Stormpath, anopen API service for user management. The results of the permission by the RBAC module were notified toregistered visitors by a short message service (SMS) notification module implemented using an SMS API.A web interface was provided to register visitors and manage authorization, which included campus managementand usage statistics. The web server was separated from the gate security system. The gate security system providesrepresentational state transfer (REST) APIs17, and the web interface requests data from the module using RESTAPIs.To support scaling and load balancing, modules in the gate security system were independent and exchange datavia the message router module. The message router module was implemented with Apache ActiveMQ18 as JMSQueue, and messages are exchanged using pre-defined queues. Message flow between the modules is shown in Fig.1.

Dongwooal. / ProcediaComputerScience111 (2017)260–267DongwooKwonKwonet ProcediaComputerScience00 (2016)000–000262Fig. 1. Message flow between the modules in the gate security system using open API mashup.All modules in the gate security system were implemented using the Java development kit (JDK), ApacheCamel19, and the Apache Maven20 build tool. Apache Camel is a framework based on enterprise integration patterns(EIP) for enterprise application integration (EAI).3. Container based testbed for gate security system developmentWe analyze testbed requirements for gate security system development, and subsequently design the containerbased testbed structure. The gss-test shell script is introduced to support automated testbed building and systemtesting.3.1. Testbed requirementsThe gate security system modules should be deployed independently onto virtualized machines to support scalingand load balancing due to availability and stability under heavy load. Each independent module communicates withthe others via the message router module. For a module in development or integration testing, a virtual machine setincluding all modules is required with hardware device access, where the new module is a development version andthe others are stable versions.Multiple virtual machine sets should be executed and tested on a physical machine connected to commonhardware devices, such as the IP camera and RFID reader. This is required to support a number of developers andtesters simultaneously working on the same machine to overcome the limitation of requiring a quantity of commonhardware devices. Therefore, the server virtualization solution should be relatively lightweight and ensure highperformance to execute simultaneous multiple virtual machine sets on a physical machine.Private domain names should be registered and used in the virtual machines for module communication, ratherthan IP addresses hard coded in source codes or configuration modifications, due to flexible multiple test set supportand IP address assignment by dynamic host configuration protocol (DHCP). This means that the same privatedomain name should be assigned for the same modules in multiple virtual machine sets. For example, if the private

Dongwoo Kwon et al. / Procedia Computer Science 111 (2017) 260–267 Dongwoo Kwon et al. / Procedia Computer Science 00 (2016) 000–000263domain name of the face recognition module in set A is face-recognition.gss, then its private domain name in set Bshould also be face-recognition.gss. Thus, each domain name system (DNS) for the virtual machine sets should beisolated.Conversely, private domain names for common hardware devices, such as IP cameras and RFID readers,connected to a physical machine should be managed by a common DNS, to enable multiple virtual machine sets toshare the hardware devices.Logs generated from the modules of the virtual machine sets should be collected and integrated. An analysisplatform for the integrated log database should also be provided for development support and software qualityimprovement. SCM should be provided to control and manage changes in the source codes of the modules usingdistributed SCM software, such as Git21 or Mercurial22. Module updates in the SCM should be automaticallyreplicated to running modules in the testbed.Finally, the testbed should provide an automated building method, which should enable rapid start-up andshutdown operations of virtual machine sets to facilitate building and rebuild them.3.2. Container based testbedWe selected Linux containers as the virtualization technology and Docker as the container solution to executeand test multiple module sets on a physical machine. Linux containers is an OS level virtualization technology thatshares the kernel and part of the OS without a hypervisor. It limits and isolates system resources using controlgroups (cgroups) and namespaces of the kernel. Thus, it is very lightweight and has high performance compared tovirtual machine solutions13,14.Docker based on container technology provides automated deployment of the applications with union filesystems, such as the advanced multi-layered unification file system (AUFS)23. The Docker daemon was installed inthe gate security system and all modules in the system work on Docker containers, as shown in Fig. 2. The baseimage of the module containers is the GSS-test image, except for the message router module container, which isstored in the Docker private registry server. The GSS-test image includes the JDK, Apache Maven, Git client, etc.The message router module is based on the JMS server image including Apache ActiveMQ.3.3. Testbed structureFigure 2 describes the structure of the container based testbed for gate security system development using anopen API mashup, satisfying the testbed requirements. The container hosts files are used for local domain nameresolution to enable isolation between container sets. All hosts files of containers that belong to a same container setkeep matching IP address to host name information. They are updated when a module container is started and shutdown. This dynamic domain name management is automatically conducted by the gss-test script.The common DNS using Internet Systems Consortium (ISC) BIND24 was adopted for private domain namemanagement of common hardware devices. Its zone file describes host name and IP address matching informationfor IP cameras, Arduino devices for RFID readers, REST API modules, Camera FTP servers, and tag detectionmodules. This zone file is managed by testbed administrators on request from developers and testers. Figure 3 showsthe DNS mechanism to support multiple module container sets on the testbed.The DHCP server assigns public IP addresses to all containers in the testbed, deployed using ISC DHCP25.Pipework26 script, software defined networking tools for Linux containers, connects the virtual network interfaces ofthe containers to the physical interface of the gate security system using the assigned public IP addresses.The Git server for SCM was imp