Frameworks For Centralized Authentication And Authorization by Ken Erikson Thesis of 30 ECTS credits submitted to the School of Computer Science at Reykjavík University in partial fulfillment of the requirements for the degree of Master of Science (M.Sc.) in Computer Science June 2020 Examining Committee: Sébastien Lafond, Supervisor Adjunct Professor, Åbo Akademi University, Finland Dragos Truscan, Examiner Adjunct Professor, Åbo Akademi University, Finland Marcel Kyas, Examiner Assistant Professor, Reykjavík University, i Copyright Ken Erikson June 2020 ii Frameworks For Centralized Authentication And Authorization Ken Erikson Thesis of 30 ECTS credits submitted to the School of Computer Science at Reykjavík University in partial fulfillment of the requirements for the degree of Master of Science (M.Sc.) in Computer Science June 2020 Student: Ken Erikson Examining Committee: Sébastien Lafond Dragos Truscan Marcel Kyas iii The undersigned hereby grants permission to the Reykjavík University Library to reproduce single copies of this Thesis entitled Frameworks For Centralized Authentication And Authorization and to lend or sell such copies for private, scholarly or scientific research purposes only. The author reserves all other publication and other rights in association with the copyright in the Thesis, and except as herein before provided, neither the Thesis nor any substantial portion thereof may be printed or otherwise reproduced in any material form whatsoever without the author’s prior written permission. date Ken Erikson Master of Science iv Ken Erikson ABSTRACT A commonly used method of authentication on the Internet is to provide a combina- tion of a username and a password. One way to make this method more secure is to have long passwords. Single sign-on solutions have led to users having to remem- ber fewer passwords and the passwords can, therefore, be longer than previously. Different standardized frameworks can be used when implementing these types of solutions, each with various advantages and disadvantages. This thesis examines different authentication and authorization frameworks avail- able to integrate a centralized single sign-on solution with an existing system. The studied frameworks are OAuth 2.0, OpenID Connect, SAML, LDAP, Kerberos and RADIUS. These frameworks are reviewed and compared with each other on a high level with an emphasis on security and features. A subset of them, namely OAuth 2.0, OpenID Connect and SAML, is chosen to be more extensively eval- uated through integration with Hibox Systems’s internal solution. The reliability of the system is tested through simulating heavy load conditions, while successful throughput and system resource usage are used as metrics to determine the effi- ciency of the system. The integration of both OpenID Connect, combined with OAuth 2.0, and SAML had a smooth user experience during normal authentication flows, but the combina- tion of OAuth 2.0 and OpenID Connect had an advantage over SAML during heavy load conditions. The user experience was kept on a reasonable level for a larger number of simultaneous users with the OpenID Connect and OAuth 2.0 integration and the frameworks are therefore deemed to be better suited for the given use case. Keywords: Authentication, Authorization, OAuth 2.0, OpenID Connect, SAML v Ken Erikson CONTENTS Abstract v Contents vi List of figures viii Glossary ix Abbreviations x 1 Introduction 1 1.1 Context . .2 1.2 Purpose of this thesis . .3 1.3 Methodology . .3 1.4 Thesis structure . .3 2 Background 5 2.1 Authentication . .5 2.2 Authorization . .6 2.3 Related work . .6 3 Frameworks 8 3.1 OAuth 2.0 . .9 3.2 OpenID Connect . 13 3.3 SAML . 15 3.4 LDAP . 17 3.5 Kerberos . 20 3.6 RADIUS . 22 4 Evaluation setups 26 4.1 Criteria . 28 4.2 Test setup . 29 4.2.1 Network setup . 29 4.2.2 Identity provider server . 30 vi Ken Erikson 4.2.3 Hibox server . 31 4.2.4 Load testing tool . 32 4.3 Test scenarios . 33 4.4 Performance metrics collection . 34 4.4.1 Request metrics . 34 4.4.2 Resource monitoring . 34 4.5 Evaluation of the experimental setups . 35 5 Implementation 37 5.1 Platform . 37 5.2 Integration overview . 38 5.3 Authentication flows . 40 5.3.1 OpenID Connect flow . 40 5.3.2 SAML flow . 42 5.4 Challenges . 45 6 Results analysis 47 6.1 Implementation overview . 47 6.2 Evaluation overview . 48 6.2.1 User throughput . 49 6.2.2 Response time . 50 6.2.3 Error rate . 53 6.2.4 Data rate . 53 6.2.5 RAM increase . 55 6.2.6 CPU utilization . 57 6.3 Summary . 59 7 Future work and conclusions 60 7.1 Future work . 60 7.2 Conclusions . 61 Bibliography 62 Swedish summary 67 vii Ken Erikson LIST OF FIGURES 3.1 OAuth 2.0 Authorization Code flow. 10 3.2 OAuth 2.0 network diagram. 12 3.3 SAML authentication flow. 16 3.4 LDAP flow. 19 3.5 The entities and shared keys in a Kerberos system. 21 3.6 The RADIUS request and possible responses. 24 4.1 Network diagram of the use case. 27 4.2 Network diagram of the test setup. 30 5.1 OpenID Connect authentication flow. 41 5.2 SAML authentication flow. 43 6.1 Throughput of users. 49 6.2 Average response times. 50 6.3 Average response times for up to 100 users. 51 6.4 Error rate of authentication requests. 52 6.5 Bytes transmitted per second for authentication requests. 54 6.6 RAM increase on the Gluu identity server relative to a baseline. 55 6.7 RAM increase on the Hibox server relative to a baseline. 56 6.8 CPU utilization of the Gluu identity server. 57 6.9 CPU utilization of the Hibox server. 58 viii Ken Erikson GLOSSARY Standard An agreed upon and approved, by general consent, model of how something ought to work on a high level. Protocol Detailed description of how a standard works and how it should be imple- mented. Framework Implementation of a well-defined protocol. Principal An entity that seeks to be authenticated by a system. Supplicant An entity at the edge of a point-to-point LAN that seeks to be authenticated. Single sign-on A system where one trusted entity can forwards proof of authentication ac- cepted by other independent systems. Request for Comments A formal document drafted by the Internet Engineering Task Force (IETF) that has been put up for public review and revision. Identity provider A system component that is able to provide proof of authentication of an end user. ix Ken Erikson ABBREVIATIONS SAML Security Assertion Markup Language LDAP Lightweight Directory Access Protocol RADIUS Remote Authentication Dial-In User Service XML Extensible Markup Language PKCE Proof Key for Code Exchange RFC Request for Comments ACL Access-control list SQL Structured Query Language IETF Internet Engineering Task Force SSO Single sign-on GUI Graphical user interface CSS Cascading Style Sheets x Ken Erikson 1 INTRODUCTION The Internet, as we know it today, has existed for close to four decades and has evolved much since its invention [1]. The original use case of the Internet and, later, the world wide web was mainly simple communication and efficient informa- tion sharing. The need for making the Internet more secure became more important as the popularity of it started rising and the general public started using the world wide web on a daily basis [2]. The Internet was no longer mostly used for search- ing information, but also for tasks where sensitive information was shared over a medium that had put a focus on being openly available to everyone. As the online community grew, so did the attack surface and many new security threats capitalized on this. At the same time as new security threats were recognized, it had also be- come clear that the widespread use of the Internet had led to the fact that a complete overhaul of the system had become very difficult, if not completely impossible, to achieve [2]. The bigger stakeholders and organizations have now come together to make the security of the Internet as good as possible with the given circumstances and the Internet’s many inherent limitations [2]. One of the most crucial security problems on the Internet is that two entities need to be able to verify the identity of each other. Website-specific certificates and trusted certificate authorities have become the standard way of confirming the authenticity of the website one is visiting [3]. How a website can verify the identity of a user is a completely different problem. Every user having his own certificate would not have the required usability and would lead to a single point of failure. The most used method currently is to have a username and a password to authenticate oneself to a service [4]. The problem then becomes that the user needs to keep track of one username and password combination per service, as well as go through 1 Ken Erikson a cumbersome registration process every time a new one is opened. One push to reduce the inconvenience is to use a trusted source as a central identity provider [5]. There are many ways an identity provider can function behind the scenes, but in its most basic form a user logs in to the identity provider and the identity provider then verifies the identity of the user to the service [5]. Security is crucial in any publicly available system, and this has led to the availability of a multitude of dif- ferent authentication frameworks and protocols that an identity provider can follow and implement. By conforming to a certain protocol, services can work together through an agreed-upon interface and the services are not tightly coupled together [6].