Background on Identity Federation Technologies for the Public Safety Community
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Comparative Analysis and Framework Evaluating Web Single Sign-On Systems
Comparative Analysis and Framework Evaluating Web Single Sign-On Systems FURKAN ALACA, School of Computing, Queen’s University, [email protected] PAUL C. VAN OORSCHOT, School of Computer Science, Carleton University, [email protected] We perform a comprehensive analysis and comparison of 14 web single sign-on (SSO) systems proposed and/or deployed over the last decade, including federated identity and credential/password management schemes. We identify common design properties and use them to develop a taxonomy for SSO schemes, highlighting the associated trade-offs in benefits (positive attributes) offered. We develop a framework to evaluate the schemes, in which weidentify14 security, usability, deployability, and privacy benefits. We also discuss how differences in priorities between users, service providers (SPs), and identity providers (IdPs) impact the design and deployment of SSO schemes. 1 INTRODUCTION Password-based authentication has numerous documented drawbacks. Despite the many password alternatives, no scheme has thus far offered improved security without trading off deployability or usability [8]. Single Sign-On (SSO) systems have the potential to strengthen web authentication while largely retaining the benefits of conventional password-based authentication. We analyze in depth the state-of-the art ofwebSSO through the lens of usability, deployability, security, and privacy, to construct a taxonomy and evaluation framework based on different SSO architecture design properties and their associated benefits and drawbacks. SSO is an umbrella term for schemes that allow users to rely on a single master credential to access a multitude of online accounts. We categorize SSO schemes across two broad categories: federated identity systems (FIS) and credential managers (CM). -
A Decentralized Framework for Verifiable Credentials on the Web by Kayode Yadilichi Ezike S.B
SolidVC - A Decentralized Framework for Verifiable Credentials on the Web by Kayode Yadilichi Ezike S.B. EECS | Massachusetts Institute of Technology | 2017 Submitted to the Department of Electrical Engineering and Computer Science in Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Electrical Engineering and Computer Science at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY February 2019 ○c Massachusetts Institute of Technology 2019. All rights reserved. Author................................................................ Department of Electrical Engineering and Computer Science February 20, 2019 Certified by. Lalana Kagal Principal Research Scientist Thesis Supervisor Accepted by . Katrina LaCurts Chair, Master of Engineering Thesis Committee 2 SolidVC - A Decentralized Framework for Verifiable Credentials on the Web by Kayode Yadilichi Ezike Submitted to the Department of Electrical Engineering and Computer Science on February 20, 2019, in Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Electrical Engineering and Computer Science Abstract Credentials are an integral part of our lives, as they express our capabilities and enable access to restricted services and benefits. In the early 2010s, the Verifiable Claims Working Group of the World Wide Web Consortium (W3C) proposed a specifica- tion for what is now the Verifiable Credentials Data Model. This living specification, which is still in development, outlines a cogent framework for the issuance, storage, presentation, and verification of credentials on the Web. Many of the leading Verifi- able Credentials projects leverage Distributed Ledger Technology (DLT), potentially compromising Web interoperability and sometimes exposing otherwise personal data. SolidVC is a decentralized Verifiable Credentials platform built with the open pro- tocols of the Web. -
Indeni Insight
Indeni 6 User Guide Part 1: Understanding the Basics 1.1 Requirements 1.2 Installation 1.3 Indeni Insight Part 2: Getting Started 2.1 Creating Users on Vendor Devices 2.2 Device Communication Part 3: Navigating the User Interface 3.1 Summary Tab 3.2 Current Tab 3.3 Archived Tab 3.4 Rules Tab Part 4: Analysis and Reporting 4.1 Custom Reports Part 5: Device Management 5.1 Credential Sets 5.2 Adding Devices 5.3 Device Backup Part 6: Settings 6.1: Centralized Authentication 6.2: Role Based Access Control 6.3: Configuring a Proxy Server to access Indeni Insight 6.4: SNMP Integration Part 7: Security Open Source Credits 2 | Page Part 1: Understanding the Basics This Introductory Guide is geared towards technical users with a strong working knowledge of networking and network security administration. Users should have the ability to set up network devices on their own, and also be familiar with how to use the various Command Line Interfaces (CLI). The guide is designed to take you from start to finish, in an order that will help you succeed. If you are a first time Indeni user, you will want to go through each step of the guide, and at the end, you should be able to add devices with a good understanding of how to use the system successfully. We highly encourage interested users, students, and IT professionals testing new technologies to download and use Indeni for free! If you do not have networking devices to test with, but are interested in trying out our system, you can use other tools such as GNS3, since Indeni works with both physical and virtual devices. -
Move Beyond Passwords Index
Move Beyond Passwords Index The quest to move beyond passwords 4 Evaluation of current authentication method 6 Getting started with passwordless authentication 8 Early results to going passwordless 9 Common approaches to going passwordless 11 Email magic links 11 Factor sequencing 12 Webauthn 14 Planning for a passwordless future 16 Move Beyond Passwords 2 Introduction Traditional authentication using a username and password has been the foundation of digital identity and security for over 50 years. But with the ever-growing number of user accounts, there are a number of new issues: the burden on end users to remember multiple passwords, support costs, and most importantly, the security risks posed by compromised credentials. These new challenges are now outweighing the usefulness of passwords. The case for eliminating passwords from the authentication experience is getting more compelling every day. Emerging passwordless security standards, elevated consumer and consumer-like experience expectations, and ballooning costs have moved eliminating passwords from a theoretical concept to a real possibility. In this whitepaper, we will explore the case for going passwordless for both customer and employee authentication, and map out steps that organizations can take on their journey to true passwordless authentication. Move Beyond Passwords 3 The quest to move beyond passwords Understanding the need for passwordless authentication starts with understanding the challenges presented by passwords. The core challenges with passwords can be broken down into the following areas: Poor Account Security Passwords have spawned a whole category of security/identity-driven attacks — compromised passwords due to credential breaches, phishing, password spraying attacks, or poor password hygiene can result in account takeover attacks (ATO). -
What Is an Identity Provider? Why Does My Company Need to Become One?
WHITE PAPER WHAT IS AN IDENTITY PROVIDER? WHY DOES MY COMPANY NEED TO BECOME ONE? Tame Mobile and Cloud Security Risks: Become an IdP Executive Overview Enterprises face security threats from all directions. According to the Identity Theft Resource Center, there were 189 known breaches from January 1 of this year through the beginning of June. Those breaches exposed approximately 13.7 million records. Meanwhile, trends intended to benefit the enterprise, such as cloud computing and mobility, often introduce unintended risks. The weak link in our online economy is trust. If you boil that down further, much of the lack of trust stems from the inability to verify online identities. It is increasingly difficult to know whether people (or companies) on the Internet are who they say they are. To address today’s security risks and to embrace new technology trends such as cloud, mobility and SaaS, enterprises must rethink how they handled their employees’ identities. Fortunately, the industry has been moving towards federated Single Sign On (SSO) solutions, and has been standardizing building blocks like SAML and OpenID. Enterprises should build on these standards in order to become Identity Providers (IdP). By becoming an IdP, companies can better control, enforce and extend security standards to all on-premise and cloud-based applications in their organizations, as well as to mobile devices. This paper will discuss the reasons enterprises should become IdPs, what becoming an IdP involves, and why you should automate as much of this process as possible. Introduction: New Security Risks Undermine Online Business In August 2012, a hacker crafted a wickedly specific social engineering attack to target Wired writer Mat Honan. -
Netiq Securelogin Installation Guide
SecureLogin 8.7 Installation Guide February, 2019 Legal Notice For information about NetIQ legal notices, disclaimers, warranties, export and other use restrictions, U.S. Government restricted rights, patent policy, and FIPS compliance, see https://www.netiq.com/company/legal/. © 2018 NetIQ Corporation. All Rights Reserved. For information about NetIQ trademarks, see https://www.netiq.com/company/legal/. All third-party trademarks are the property of their respective owners. 2 Contents About This Guide 7 1 Getting Started 9 Prerequisites . 9 Setting Up a Passphrase . 9 2 Introduction 11 Features of SecureLogin Installer. .11 Installation Overview . .11 Logging Event Messages. .13 Disabling Logging to Windows Event Log By Using Installation Wizard . .13 Disabling Logging to Windows Event Log After the Installation. .14 Logging of Syslog Audit Messages . .14 Installing and Configuring Syslog Auditing . .14 Enabling Logging to Syslog . .16 Managing Log Settings for SecureLogin Components . .17 Understanding the NSLLogManager Functionality . .17 Using NSLLogManager. .17 Installing SecureLogin with Advanced Authentication. .17 Installing SecureLogin Browser Extensions . .18 Installing Single Sign-on Assistant in Google Chrome. .18 Installing Single Sign-on Assistant in Microsoft Edge (Chromium-based) . .19 Installing Single Sign-on Assistant in Microsoft Edge (HTML-based). .19 Installing Single Sign-on Assistant in Mozilla Firefox. .20 Installing NetIQ SecureLogin Extension in Google Chrome . .20 Installing NetIQ SecureLogin Extension in Mozilla Firefox . .20 3 Installing and Configuring in Active Directory Environment 23 Before You Begin . .23 Prerequisites . .23 Requirements for Microsoft Windows Server . .24 Installation Overview. .25 Microsoft Active Directory . .25 Configuring . .26 Extending the Active Directory Schema and Assigning Rights . .26 Configuring a User’s Environment . -
Beyond X.509: Token-Based Authentication and Authorization for HEP
Beyond X.509: Token-based Authentication and Authorization for HEP Andrea Ceccanti, Marco Caberletti, Enrico Vianello, Francesco Giacomini INFN CNAF CHEP 2018 Sofia, July 12th 2018 The current WLCG AAI In operation since ~2003, and still working nicely: • X.509 trust fabric provided by IGTF (tells services which CAs are trusted) • X.509 certificates provided to users for authentication • Proxy certificates for Single Sign-On (SSO) and delegation • VOMS attribute certificates for attribute-based authorization (issued and Slide by Ákos Frohner signed by VO-scoped VOMS servers) Beyond X.509: Token-based Authentication & Authorization for HEP - CHEP 2018, Sofia 2 Current WLCG AAI: the weak points Usability • X.509 certificates are difficult to handle for users • VOMS does not work in browsers Inflexible authentication • Only one authentication mechanism supported: X.509 certificates • Hard to integrate identity federations Authorization tightly bound to authentication mechanism • VOMS attributes are inherently linked to an X.509 certificate subject Ad-hoc solution • We had to invent our own standard and develop ad-hoc libraries and central services to implement our own AAI Can we do better today? Beyond X.509: Token-based Authentication & Authorization for HEP - CHEP 2018, Sofia 3 A novel AAI for WLCG: main challenges Authentication Delegation • Flexible, able to accomodate • Provide the ability for services to various authentication mechanisms act on behalf of users - X.509, username & password, • Support for long-running EduGAIN, social logins -
Derived Personal Identity Verification (PIV) Credentials
NIST SPECIAL PUBLICATION 1800-12 Derived Personal Identity Verification (PIV) Credentials Includes Executive Summary (A); Approach, Architecture, and Security Characteristics (B); and How-To Guides (C) William Newhouse Michael Bartock Jeffrey Cichonski Hildegard Ferraiolo Murugiah Souppaya Christopher Brown Spike E. Dog Susan Prince Julian Sexton This publication is available free of charge from https://doi.org/10.6028/NIST.SP.1800-12 Previous drafts of this publication are available free of charge from https://www.nccoe.nist.gov/library/derived-piv-credentials-nist-sp-1800-12-practice-guide NIST SPECIAL PUBLICATION 1800-12 Derived Personal Identity Verification (PIV) Credentials Includes Executive Summary (A); Approach, Architecture, and Security Characteristics (B); and How-To Guides (C) William Newhouse National Cybersecurity Center of Excellence Information Technology Laboratory Michael Bartock Jeffrey Cichonski Hildegard Ferraiolo Murugiah Souppaya National Institute of Standards and Technology Information Technology Laboratory Christopher Brown Spike E. Dog Susan Prince Julian Sexton The MITRE Corporation McLean, Virginia August 2019 U.S. Department of Commerce Wilbur Ross, Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Undersecretary of Commerce for Standards and Technology NIST SPECIAL PUBLICATION 1800-12A Derived Personal Identity Verification (PIV) Credentials Volume A: Executive Summary William Newhouse National Cybersecurity Center of Excellence Information Technology Laboratory Michael -
Identity Provider for SAP Single Sign-On and SAP Identity Management Document Version: 1.0 – 2017-05-15
Implementation Guide PUBLIC Identity Provider for SAP Single Sign-On and SAP Identity Management Document Version: 1.0 – 2017-05-15 Identity Provider for SAP Single Sign-On and SAP Identity Management Content 1 Identity Provider for SAP Single Sign-On and SAP Identity Management....................4 1.1 What is SAML 2.0............................................................... 5 SSO with SAML 2.0........................................................... 6 SLO with SAML 2.0............................................................9 Identity Federation...........................................................10 Common Domain and Identity Provider Discovery.....................................14 Identity Provider Proxy........................................................16 1.2 Before Starting................................................................23 System Requirements........................................................ 23 Authorizations..............................................................24 Limitations of the Identity Provider................................................25 1.3 Adding an Identity Provider to Your Network...........................................26 Downloading and Installing the Federation Software................................... 26 Configuring the Identity Provider.................................................27 Enabling the SAML Identity Provider.............................................. 29 Configuring Back-Channel Communication..........................................31 Configuring -
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. -
From Identity-Based Authorization to Capabilities: Scitokens, Jwts, And
From Identity-Based Authorization to Capabilities: SciTokens, JWTs, and OAuth Jim Basney [email protected] HTCondor Workshop Autumn 2020 25 September 2020 Goals for an HTC Authorization System ● Enable access to HTC! ● Implement appropriate resource/data access policies ● Ease of use ● Manageability ● Distributed/Decentralized 2 Authentication & Authorization Standards ● X.509: Certificates ○ Grid Security Infrastructure (GSI) ○ Virtual Organization Membership Service (VOMS) ● SAML: Security Assertion Markup Language ○ Using XML ○ Single Sign-on for Higher Education: eduGAIN / InCommon / Shibboleth ● JWT: JSON Web Tokens ○ Using JavaScript Object Notation (JSON) ○ Pronounced "jot" ○ Digitally signed, self-describing security tokens ● OAuth: Authorization Framework ○ Optionally using JWTs ○ Tokens for limited access to resources ● OIDC: OpenID Connect ○ An identity layer on top of OAuth ○ Using JWTs 3 X.509 Certificate Attribute Authority Authority Policy Policy Trust End Entity Attribute Certificate Certificate Data Node Submit Execute Policy Node Node Policy Policy 4 SAML Identity Provider Policy Trust Authentication Attribute Assertion Assertion Data Node Submit Execute Policy Node Node Policy Policy 5 JWT / OIDC / OAuth OpenID Authorization Provider Server Policy Policy Trust Access ID Token Token Data Node Submit Execute Policy Node Node Policy Policy 6 Credentials for Authentication / Authorization X.509 SAML OIDC OAuth / JWT Credential Issuer Certificate Authority Identity Provider OpenID Provider Authorization Server Credential -
On the Security of Single Sign-On
On the Security of Single Sign-On Vladislav Mladenov (Place of birth: Pleven/Bulgaria) [email protected] 30th June 2017 Ruhr-University Bochum Horst G¨ortz Institute for IT-Security Chair for Network and Data Security Dissertation zur Erlangung des Grades eines Doktor-Ingenieurs der Fakult¨atf¨urElektrotechnik und Informationstechnik an der Ruhr-Universit¨atBochum First Supervisor: Prof. Dr. rer. nat. J¨org Schwenk Second Supervisor: Prof. Dr.-Ing. Felix Freiling www.nds.rub.de Abstract Single Sign-On (SSO) is a concept of delegated authentication, where an End- User authenticates only once at a central entity called Identity Provider (IdP) and afterwards logs in at multiple Service Providers (SPs) without reauthenti- cation. For this purpose, the IdP issues an authentication token, which is sent to the SP and must be verified. There exist different SSO protocols, which are implemented as open source libraries or integrated in commercial products. Google, Facebook, Microsoft and PayPal belong to the most popular SSO IdPs. This thesis provides a comprehensive security evaluation of the most popular and widely deployed SSO protocols: OpenID Connect, OpenID, and SAML. A starting point for this research is the development of a new concept called malicious IdP, where a maliciously acting IdP is used to attack SSO. Generic attack classes are developed and categorized according to the requirements, goals, and impact. These attack classes are adapted to different SSO proto- cols, which lead to the discovery of security critical vulnerabilities in Software- as-a-Service Cloud Providers, eCommerce products, web-based news portals, Content-Management systems, and open source implementations.