Openid Connect Based Authentication for Host Remote Access

Total Page:16

File Type:pdf, Size:1020Kb

Openid Connect Based Authentication for Host Remote Access Masaryk University Faculty of Informatics OpenID Connect Based Authentication for Host Remote Access Master’s Thesis Bc. Ondřej Velíšek Brno, Fall 2018 Masaryk University Faculty of Informatics OpenID Connect Based Authentication for Host Remote Access Master’s Thesis Bc. Ondřej Velíšek Brno, Fall 2018 This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Bc. Ondřej Velíšek Advisor: RNDr. Michal Procházka, Ph.D. i Acknowledgements I would first like to thank my thesis advisor RNDr. Michal Procházka, Ph.D. for his leadership, provided motivation and steering me in the right direction whenever he thought I needed it. Thank you. I would also like to thank the colleagues and backers who sup- ported me. Namely, Anna Schneiderová, Ing. Jaroslav Rozman, Ph.D., Klára Ajašová, Kryštof Michal and Milan Kramárik. I am gratefully indebted to them for their valuable comments on this thesis. Finally, I must express my very profound gratitude to my par- ents for providing me with unfailing support and continuous encour- agement throughout my years of study and through the process of researching and writing this thesis. iii Abstract This thesis proposes three authentication architecture designs using OpenID Connect identity provider in a distributed environment. It fo- cuses on the secure authorization delegation use-case which is demon- strated on the SSH protocol. Each of the architecture designs is evalu- ated regarding security, interoperability, easy adoption and usability and compared with existing authentication methods. Prototypes of each architecture were implemented and tested to verify theoretic statements and feasibility of the proposed designs. iv Keywords OpenID Connect, OAuth 2.0, authentication, authorization, delegation, remote access, ssh, secure shell v Contents Introduction 1 Research Objectives . .1 Text Structure . .2 1 OAuth 2.0 Framework 3 1.1 OAuth 2.0 ...........................3 1.1.1 Authorization Code Flow . .4 1.1.2 Device Code Flow . .6 1.1.3 Best Current Practice for Native Apps . .7 1.1.4 Client Identification . .9 1.1.5 Dynamic Client Registration . .9 1.2 OpenID Connect 1.0 ..................... 10 2 Secure Shell 11 2.1 Pluggable Authentication Interfaces ............. 11 2.1.1 Keyboard Interactive . 11 2.1.2 Generic Security Services API . 12 2.2 SSH Agent .......................... 14 2.2.1 Agent Forwarding . 15 3 Definition of Model Environment 17 3.1 Administrative Units ..................... 17 3.2 Hardware Components .................... 17 3.3 Software Components ..................... 18 3.4 Components Responsibility .................. 19 4 Existing Authentication Methods 21 4.1 Resource owner password flow ................ 21 4.2 Copy-paste method ...................... 21 4.3 OIDC Agent ......................... 22 4.4 Kerberos ............................ 22 4.5 Cyclone PAM ......................... 24 4.6 Guardian Agent ........................ 25 4.7 Conclusion .......................... 26 5 Authorization Code Agent Extension 27 vii 5.1 Motivation .......................... 27 5.2 Environment Setup ...................... 28 5.3 Authorization Process ..................... 29 5.4 Prototype Implementation .................. 30 5.5 Easy Adoption and Interoperability Consideration ...... 30 5.6 Security Consideration .................... 31 5.6.1 Access Gained by Intermediate Client . 31 5.6.2 Centralized Credentials in Agent . 32 5.7 Usability Consideration .................... 32 5.7.1 Initial Setup . 32 5.7.2 Authorization Process . 33 5.8 Conclusion .......................... 33 6 Authentication Architecture Proposals 35 6.1 OAuth2 GSS-API mechanism ................ 35 6.1.1 Environment Setup . 35 6.1.2 Authentication Process . 36 6.1.3 Separated Resource Server Modification . 38 6.1.4 Prototype Implementation . 40 6.1.5 Easy Adoption and Interoperability Consideration 40 6.2 OIDC GSS-API mechanism ................. 41 6.2.1 Environment Setup . 41 6.2.2 Authentication Process . 42 6.2.3 Prototype Implementation . 44 6.2.4 Easy Adoption and Interoperability Consideration 44 6.3 Device Code PAM ....................... 44 6.3.1 Environment Setup . 45 6.3.2 Authentication Process . 46 6.3.3 Prototype Implementation . 47 6.3.4 Easy Adoption and Interoperability Consideration 48 7 Quality Attribute Comparison 49 7.1 Security Consideration .................... 49 7.1.1 Access Gained by Intermediate Client . 49 7.1.2 Access Gained by Remote Server . 51 7.1.3 Conclusion . 53 7.2 Usability Consideration .................... 53 7.2.1 Initial Setup . 54 viii 7.2.2 Authentication Process . 55 7.2.3 Conclusion . 58 8 Conclusion 59 8.1 Research Contributions .................... 59 8.2 Future Work .......................... 60 Bibliography 61 A Content of Attached Archive 67 B Authentication Process Illustration 69 B.1 OAuth2 GSS-API Mechanism ................ 69 B.2 OIDC GSS-API Mechanism ................. 72 B.3 Device Code PAM ....................... 75 ix List of Figures 1.1 Sequence diagram of OAuth2 abstract flow 4 1.2 Sequence diagram of OAuth2 authorization code flow 5 1.3 Sequence diagram of OAuth2 device code flow 6 1.4 Sequence diagram of authorization code flow for native apps 8 2.1 Sequence diagram of PAM authentication method in SSH context 12 2.2 Sequence diagram of simplified GSS-API authentication method in SSH context 13 2.3 Sequence diagram of SSH agent protocol 14 2.4 Component diagram of SSH agent forwarding 15 3.1 Deployment diagram of model architecture 18 3.2 Diagram illustrating relation between OAuth2 roles and software components of model architecture 19 4.1 Sequence diagram of simplified Kerberos authentication process in SSH environment 23 4.2 Sequence diagram of Cyclone PAM authentication process 24 4.3 Sequence diagram of simplified SSH authentication process with Guardian agent 25 5.1 Deployment diagram of OAuth2 agent in model environment 28 5.2 Sequence diagram of OAuth2 agent authorization process 29 6.1 Deployment diagram of OAuth2 GSS-API mechanism in model environment 36 6.2 Sequence diagram of authentication process with OAuth2 GSS-API mechanism 37 6.3 Sequence diagram of authentication process with OAuth2 GSS-API mechanism with separated resource server modification 39 6.4 Deployment diagram of OpenID Connect GSS-API mechanism in model environment 42 xi 6.5 Sequence diagram of authentication process with OpenID Connect GSS-API mechanism 43 6.6 Deployment diagram of Device code PAM in model environment 45 6.7 Sequence diagram of authorization process with Device code PAM 46 B.1 Initial state in authentication process with OAuth2 GSS-API mechanism 69 B.2 IdP selection in authentication process with OAuth2 GSS-API mechanism 70 B.3 Authentication to Google in authentication process with OAuth2 GSS-API mechanism 70 B.4 Consent screen in authentication process with OAuth2 GSS-API mechanism 71 B.5 Successful access to remote machine in authentication process with OAuth2 GSS-API mechanism 71 B.6 Initial state in authentication process with OIDC GSS-API mechanism 72 B.7 IdP selection in authentication process with OIDC GSS-API mechanism 73 B.8 Authentication to Google in authentication process with OIDC GSS-API mechanism 73 B.9 Authorization consent in authentication process with OIDC GSS-API mechanism 74 B.10 Successful access to remote machine in authentication process with OIDC GSS-API mechanism 74 B.11 Initial state in authentication process with Device code PAM 75 B.12 Verification prompt in authentication process with Device code PAM 76 B.13 IdP selection in authentication process with Device code PAM 76 B.14 Authentication to Google state in authentication process with Device code PAM 77 B.15 Authorization consent in authentication process with Device code PAM 77 xii B.16 Successful client authorization in authentication process with Device code PAM 78 B.17 Successful access to remote machine in authentication process with Device code PAM 78 xiii Introduction The Internet has become a standard way how users consume services nowadays. There are many service providers, and users often consume multiple services across various of them. Since many of them were developed independently, they use their own identity management systems. It became a usability and security issue because users had to manage credentials for each provider. Therefore centralized identity providers with a single sign-on1 mechanism were used to mitigate this issue [1]. One of the provided services is a cloud computing [2, 3] which enables a user to instantiate virtual machines and access other services from them. It becomes a challenge to provide a single sign-on mech- anism in such a distributed environment [4]. For example, he/she wants to access storage supplied by one provider from the virtual machine provided by the second one. In this case, the intermediate machine and therefore the cloud infrastructure receives credentials authorizing it to access the final service. Depending on the credential it might be a security issue [5]. I refer to this use-case further as an authorization delegation use-case. Some of the existing authentication methods used in a cloud envi- ronment have already satisfied this use-case. As an example, consider
Recommended publications
  • Raw Slides (Pdf)
    2550 Intro to cybersecurity L5: Distributed Authentication abhi shelat/Ran Cohen Agenda • The problem of distributed authentication • The Needham-Schroeder protocol • Kerberos protocol • Oauth So far: authenticating to a server Mallory Alice Bob Gen pw pw Authenticating to an organization Mallory Alice Gen pw pw Authenticating to an organization Mallory Alice Gen pw pw Distributed authentication • Organizations have many entities (users/services) • Secure communication over insecure channels • Password-based authentication • Passwords are never transmitted (except for the setup phase) • Enable mutual authentication Basic tool: symmetric encryption Alice Bob 푚 푚 Eve Basic tool: symmetric encryption • Gen: generates secret key 푘 • Enc: given 푘 and 푚 output a ciphertext 푐 Denote 퐸푛푐푘 푚 , 퐸푘 푚 , 푚 푘 • Dec: given 푘 and 푐 output a message 푚 • Security (informal): Whatever Eve can learn on 푚 given 푐 can be learned without 푐 • Examples: – DES (Data Encryption Standard) – AES (Advanced Encryption Standard) 푚 Authentication from Encryption • Alice and Bob share a key • They communicate over an insecure channel • Alice wants to prove her identity to Bob • Eve’s goal: impersonate Alice Alice Bob 푘퐴퐵 푘퐴퐵 Eve Attempt #1 Alice Bob I am Alice 푘퐴퐵 푘퐴퐵 I am Alice Eve Attempt #2: use the key Alice Bob I am Alice 푘퐴퐵 푘퐴퐵 푘퐴퐵 I am Alice 푘퐴퐵 Replay attack Eve Attempt #3: use nonce Alice I am Alice Bob 푁푎 푘퐴퐵 Pay Eve 500$ 푁푎 − 1 푘퐴퐵 푘퐴퐵 푘퐴퐵 푘퐴퐵 Nonce: a random number for a one-time use Eve Attempt #3: use nonce Alice I am Alice Bob 푁푎 푘퐴퐵 Pay Eve 500$ 푁푎 −
    [Show full text]
  • Glossary.Pdf
    Glossary Note: Terms in italics are described in their own glossary entries. 3DES. See Data Encryption Standard. A A RR. Type identifier for a DNS Address resource record. Active Directory (AD). The directory service for Windows 2000. A hierarchical, object-oriented database that stores distributed data for Windows 2000 domains, trees, and forests. Active Directory-integrated zones. DNS zones for which zone data are stored in Active Directory. All copies of an Active Directory-integrated zone are peers and can accept changes to the zone. Zone data are replicated through Active Directory. Zone transfers are required only when importing data from a primary zone or exporting data to a secondary zone. AD. Abbreviation for Active Directory. address class. See IP address class. address resolution protocol (ARP). A protocol used by IP to discover the hardware address of the device to which a datagram is being sent. Address resource record. A DNS resource record that maps a FQDN to an IP address. Referred to as Host resource records when administering Windows 2000 DNS. Referred to as Host Address resource records in this book. AH. See authentication header. ARP. See address resolution protocol. asymmetric cryptography. A cryptography method that uses one key for encryption and another key for decryption. Also called public key cryptography. attribute. A characteristic of an object in an object- oriented database such as Active Directory; often called a property in Windows 2000. authentication. The ability of one entity to reliably determine the identity of another entity. authentication header (AH). A security protocol used by IPSec that provides authentication and message integrity.
    [Show full text]
  • The Essential Oauth Primer: Understanding Oauth for Securing Cloud Apis
    THE ESSENTIAL OAUTH PRIMER: UNDERSTANDING OAUTH FOR SECURING CLOUD APIS WHITE PAPER TABLE OF CONTENTS 03 EXECUTIVE OVERVIEW 03 MOTIVATING USE CASE: TRIPIT 05 TERMINOLOGY 06 INTRODUCTION 07 THE OAUTH 2.0 MODEL 07 OAUTH 2.0 OVERVIEW USING A TOKEN TOKEN TYPE 09 RELATIONSHIP TO OTHER STANDARDS 11 USE CASES TRIPIT REVISITED TOKEN EXCHANGE MOBILE WORKFORCE 13 RECENT DEVELOPMENT 14 SUMMARY 2 WHITE PAPER ESSENTIAL OAUTH PRIMER EXECUTIVE OVERVIEW A key technical underpinning of the cloud and the Internet of Things are Application Programming Interfaces (APIs). APIs provide consistent methods for outside entities such as web services, clients and desktop applications to interface with services in the cloud. More and more, cloud data will move through APIs, but the security and scalability of APIs are currently threatened by a problem call the password anti-pattern. This is the need for API clients to collect and replay the password for a user at an API in order to access information on behalf of that user via that API. OAuth 2.0 defeats the password anti-pattern, creating a consistent, flexible identity and policy architecture for web applications, web services, devices and desktop clients attempting to communicate with cloud APIs. MOTIVATING USE CASE: TRIPIT Like many applications today, TripIt (http://tripit.com) is a cloud-based service. It’s a travel planning application that allows its users to track things like flights, car rentals, and hotel stays. Users email their travel itineraries to TripIt, which then builds a coordinated view of the users’ upcoming trips (as well as those of their TripIt friends—the inevitable social aspect).
    [Show full text]
  • OK: Oauth 2.0 Interface for the Kerberos V5 Authentication Protocol
    OK: OAuth 2.0 interface for the Kerberos V5 Authentication Protocol James Max Kanter Bennett Cyphers Bruno Faviero John Peebles [email protected] [email protected] [email protected] [email protected] 1. Problem Kerberos is a powerful, convenient framework for user authentication and authorization. Within MIT, Kerberos is used with many online institute services to verify users as part of Project Athena. However, it can be difficult for developers unfamiliar with Kerberos development to take advantage of its resources for use in third-party apps. OAuth 2.0 is an open source protocol used across the web for secure delegated access to resources on a server. Designed to be developer-friendly, OAuth is the de facto standard for authenticating users across sites, and is used by services including Google, Facebook, and Twitter. Our goal with OK Server is to provide an easy way for developers to access third-party services using Kerberos via OAuth. The benefits of this are twofold: developers can rely on an external service for user identification and verification, and users only have to trust a single centralized server with their credentials. Additionally, developers can request access to a subset of Kerberos services on behalf of a user. 2. Implementation overview Our system is composed of two main components: a server (the Kerberos client) to retrieve and process tickets from the MIT KDC, and an OAuth interface (the OAuth server) to interact with a client app (the app) wishing to make use of Kerberos authentication. When using our system, a client application uses the OAuth protocol to get Kerberos service tickets for a particular user.
    [Show full text]
  • Vmware Workspace ONE Access 20.01 Managing User Authentication Methods in Vmware Workspace ONE Access
    Managing User Authentication Methods in VMware Workspace ONE Access JAN 2020 VMware Workspace ONE Access 20.01 Managing User Authentication Methods in VMware Workspace ONE Access You can find the most up-to-date technical documentation on the VMware website at: https://docs.vmware.com/ VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com © Copyright 2020 VMware, Inc. All rights reserved. Copyright and trademark information. VMware, Inc. 2 Contents 1 Configuring Authentication in VMware Workspace ONE Access 5 2 User Auth Service Authentication Methods in Workspace ONE Access 8 Configuring Password (Cloud) Authentication in Workspace ONE Access 9 Configure Password (Cloud) Authentication with Your Enterprise Directory 10 Configuring RSA SecurID (Cloud) For Workspace ONE Access 13 Prepare the RSA SecurID Server 13 Configure RSA SecurID Authentication in Workspace ONE Access 14 Configuring RADIUS for Workspace ONE Access 16 Prepare the RADIUS Server 16 Configure RADIUS Authentication in Workspace ONE Access 16 Enable User Auth Service Debug Logs In Workspace ONE Access Connector 19 3 Configuring Kerberos Authentication In Workspace ONE Access 21 Configure and Enable Kerberos Authentication in Workspace ONE Access 21 Configuring your Browser for Kerberos 23 Configure Internet Explorer to Access the Web Interface 23 Configure Firefox to Access the Web Interface 24 Configure the Chrome Browser to Access the Web Interface 25 Kerberos Initialization Error in Workspace ONE Access 26 4 Associate Workspace ONE Access Authentication Methods
    [Show full text]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • Centralised Authentication
    Centralised Authentication Fabian Alenius Guerreiro Jo~ao Uwe Bauknecht March 3, 2009 Contents 1 Introduction 2 2 LDAP 3 2.1 History of LDAP . 3 2.2 Directory servers . 3 2.3 Distinguished Names . 3 2.4 Directory Information Trees . 3 2.5 LDAP Authentication . 4 2.6 SASL binding . 4 3 Authentication Methods [5] 5 3.1 Kerberos . 5 3.1.1 Protocol draft 1.0 . 5 3.1.2 Analysis of Protocol draft 1.0 . 6 3.1.3 Protocol draft 2.0 . 6 3.1.4 Analysis of Protocol draft 2.0 . 7 3.1.5 Kerberos Version 4 . 7 3.1.6 Kerberos Conclusion . 8 3.2 X.509 certificates . 8 4 RADIUS 9 4.1 Introduction . 9 4.2 Functionality . 9 4.2.1 Authentication and Authorization . 9 4.2.2 Accounting . 10 4.2.3 Realms and Proxies . 10 4.3 Usage . 10 References 11 1 1 Introduction When a user wants to login to a computer system he has to go through the process of authentication. If the same user wants to authenticate against two computer systems he needs to authenticate twice. This becomes unpractical very fast as the number of systems grow, especially if the user has to remember separate usernames and passwords for each system. Another problem with this is that the management of the user accounts becomes complicated as we need several user accounts for each user. So, if we for example want to remove one user completely, we need to update all our systems. The solution to this problem is to use a centralized authentication server.
    [Show full text]
  • Cloudvision As-A-Service (Cvaas) Quick Start Guide
    CloudVision as-a-Service (CVaaS) Quick Start Guide Arista Networks www.arista.com September 2021 Headquarters Support Sales 5453 Great America Parkway +1 408 547-5502 +1 408 547-5501 Santa Clara, CA 95054 +1 866 476-0000 +1 866 497-0000 USA [email protected] [email protected] +1 408 547-5500 www.arista.com © Copyright 2021 Arista Networks, Inc. All rights reserved. The information contained herein is subject to change without notice. The trademarks, logos and service marks ("Marks") displayed in this documentation are the property of Arista Networks in the United States and other countries. Use of the Marks are subject to Arista Network’s Term of Use Policy, available at www.arista.com/en/terms-of-use. Use of marks belonging to other parties is for informational purposes only. ii Contents Contents 1 CloudVision as-a-Service....................................................................1 1.1 Onboarding at a Glance.........................................................................................................1 1.2 User Onboarding Prerequisites.............................................................................................. 3 1.2.1 Invitation URL........................................................................................................... 3 1.2.2 Authentication Details............................................................................................... 3 1.3 User Onboarding Workflow.................................................................................................... 4 1.3.1
    [Show full text]
  • Leveraging the Kerberos Credential Caching Mechanism for Faster Re-Authentications in Wireless Access Networks
    UBICOMM 2010 : The Fourth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies EAP-Kerberos: Leveraging the Kerberos Credential Caching Mechanism for Faster Re-authentications in Wireless Access Networks Saber Zrelli Yoichi Shinoda Nobuo Okabe Center for Information Science Corporate R&D Headquarters Japan Advanced Institute of Science and Technology Yokogawa Electric Corporation Ishikawa, Japan Tokyo, Japan [email protected] saber.zrelli,[email protected] Abstract—Although the wireless technology nowadays provides support cross-domain authentication that enables an access satisfying bandwidth and higher speeds, it still lacks improve- network to authenticate a roaming client that belongs to a ments with regard to handoff performance. Existing solutions remote domain. The cross-domain authentication requires for reducing handoff delays are specific to a particular network technology or require expensive upgrades of the whole infras- message exchange between the AAA server of the visited tructure. In this paper, we investigate performance benefits of network and the AAA server of the roaming station’s home leveraging the Kerberos ticket cashing mechanism for achieving network. Because these inter-domain exchanges occur over the faster re-authentications in IEEE 802.11 wireless access networks. Internet, they are subject to degradations such as packet loss For this purpose, we designed a new EAP authentication method, and network delays which increases the overall authentication EAP-Kerberos, and evaluated re-authentication performance in different scenarios. time. When a roaming station changes of access point, the same authentication procedure takes place again, disrupting Keywords-Wireless; Authentication; Handoff; Performance the user traffic at each handoff. I.
    [Show full text]
  • Single Sign-On the Way It Should Be
    Single sign-on the way it should be 6 ways Citrix Workspace delivers seamless access to all apps while improving security and the user experience Contents Single sign-on (SSO) solutions .......................................................................3 Secure access to everything ...........................................................................5 Granular controls for SaaS apps and the web ...........................................6 Control over your user identity ......................................................................7 Security beyond user names and passwords ............................................8 Seamless integration with your existing environment ..........................9 Resolving issues faster with end-to-end visibility ............................... 10 ↑ Back← Pg. to 2 contents | Pg. 4 → Citrix.com 2 Single sign-on (SSO) solutions were designed to make life easier for employees and IT. They’re meant to reduce the cost of management and provide better security, all while delivering an improved user experience. However, many solutions fall short, covering only one type or a subset of application types. This forces you to implement several access solutions from different vendors to cover your entire application landscape — negating the productivity and user experience benefits you hoped for. The complexity this type of implementation creates also runs counter to the Zero Trust initiatives that many organizations are undertaking Citrix Workspace helps you unify all apps and data across your distributed IT architecture to provide single sign-on to all the applications and data people need to be productive. Working with your existing infrastructure, Citrix Access Control consolidates multiple remote access solutions, like traditional VPNs or SSO solutions, simplifying management for IT and providing unified access for employees. ↑ Back to contents ← Pg. 2 | Pg. 4 → 3 Citrix.com | e-book | Choosing a Single Sign-On Solution ↓ 6 benefits of the Citrix Workspace SSO solution ↑ ← Pg.
    [Show full text]
  • Securing Digital Identities in the Cloud by Selecting an Apposite Federated Identity Management from SAML, Oauth and Openid Connect
    Securing Digital Identities in the Cloud by Selecting an Apposite Federated Identity Management from SAML, OAuth and OpenID Connect Nitin Naik and Paul Jenkins Defence School of Communications and Information Systems Ministry of Defence, United Kingdom Email: [email protected] and [email protected] Abstract—Access to computer systems and the information this sensitive data over insecure channels poses a significant held on them, be it commercially or personally sensitive, is security and privacy risk. This risk can be mitigated by using naturally, strictly controlled by both legal and technical security the Federated Identity Management (FIdM) standard adopted measures. One such method is digital identity, which is used to authenticate and authorize users to provide access to IT in the cloud environment. Federated identity links and employs infrastructure to perform official, financial or sensitive operations users’ digital identities across several identity management within organisations. However, transmitting and sharing this systems [1], [2]. FIdM defines a unified set of policies and sensitive information with other organisations over insecure procedures allowing identity management information to be channels always poses a significant security and privacy risk. An transportable from one security domain to another [3], [4]. example of an effective solution to this problem is the Federated Identity Management (FIdM) standard adopted in the cloud Thus, a user accessing data/resources on one secure system environment. The FIdM standard is used to authenticate and could then access data/resources from another secure system authorize users across multiple organisations to obtain access without both systems needing individual identities for the to their networks and resources without transmitting sensitive single user.
    [Show full text]
  • Introduc^On to Oauth
    Introduc)on to OAuth 2.0 Jus)n Richer ©2016 Bespoke Engineering LLC Bespoke Engineering 1 APIs are meant to be used • Much of my data and the func)onality of my life is available through APIs today • I want to have applicaons access my APIs • I don’t want the applicaons to have to impersonate me ©2016 Bespoke Engineering LLC • I don’t want to share my keys with everyone 2 A valet key for APIs • A valet key gives someone else limited access to a car • What if we could do that for web APIs? ©2016 Bespoke Engineering LLC 3 OAUTH 2.0 ©2016 Bespoke Engineering LLC 4 From the spec (RFC6749) The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its ©2016 Bespoke Engineering LLC own behalf. 5 The good bits The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its ©2016 Bespoke Engineering LLC own behalf. 6 In other words OAuth 2.0 is a delegation protocol that lets people allow applications to access things (like APIs) on their behalf. ©2016 Bespoke Engineering LLC 7 Who is involved? Resource Authorization Owner Server ©2016 Bespoke Engineering LLC
    [Show full text]