Identity-Enabling Web Applications Scott Cantor Internet2/The Ohio State University.

Slides:



Advertisements
Similar presentations
Identity Network Ideals – Heterogeneity & Co-existence
Advertisements

Office 365 Identity June 2013 Microsoft Office365 4/2/2017
Integration Considerations Greg Thompson April 20 th, 2006 Copyright © 2006, Credentica Inc. All Rights Reserved.
Saml-v2_0-intro-dec051 Security Assertion Markup Language An Introduction to SAML 2.0 Tom Scavo NCSA.
Infocard and Eduroam Enrique de la Hoz, Diego R. L ó pez, Antonio Garc í a, Samuel Mu ñ oz.
By: Ansuya Chauhan.
T Network Application Frameworks and XML Service Federation Sasu Tarkoma.
Federated Identity Management for the context of storage Bart Kerver - TERENA Storage-meeting, Amsterdam,
Beispielbild Shibboleth, a potential security framework for EDIT Lutz Suhrbier AG Netzbasierte Informationssysteme (
1 Higgins 1: a species of Tasmanian long-tailed mouse 2: the name of an open source collaboration of IBM, Novell, Oracle, Parity…
December 19, 2006 Solving Web Single Sign-on with Standards and Open Source Solutions Trey Drake AssetWorld 2007 Albuquerque, New Mexico November 2007.
© 2009 The MITRE Corporation. All rights Reserved. April 28, 2009 MITRE Public Release Statement Case Number Norman F. Brickman, Roger.
 Key exchange o Kerberos o Digital certificates  Certificate authority structure o PGP, hierarchical model  Recovery from exposed keys o Revocation.
Authentication Systems and Single Sign-On (SSO) David Orrell, Eduserv Athens 1st EuroCAMP, 2-4 March 2005, Turin, Italy.
Data and Applications Security Developments and Directions Dr. Bhavani Thuraisingham The University of Texas at Dallas Single-Sign On and Federated Identity.
SIM205. (On-Premises) Storage Servers Networking O/S Middleware Virtualization Data Applications Runtime You manage Infrastructure (as a Service)
Health IT RESTful Application Programming Interface (API) Security Considerations Transport & Security Standards Workgroup March 18, 2015.
A Use Case for SAML Extensibility Ashish Patel, France Telecom Paul Madsen, NTT.
Shibboleth 2.0 : An Overview for Developers Scott Cantor The Ohio State University / Internet2 Scott Cantor The Ohio.
SAML-based Delegation in Shibboleth Scott Cantor Internet2/The Ohio State University.
Shibboleth-intro-dec051 Shibboleth A Technical Overview Tom Scavo NCSA.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
OUC204. Recently Announced… Identity Integration Options 2 3 Identity Management Overview 1.
SWITCHaai Team Introduction to Shibboleth.
Identity Management Report By Jean Carreon and Marlon Gonzales.
Saml-intro-dec051 Security Assertion Markup Language A Brief Introduction to SAML Tom Scavo NCSA.
Web Services Security Standards Overview for the Non-Specialist Hal Lockhart Office of the CTO BEA Systems.
Tech Terminology for non-technical people Tim Bornholtz 2006 Annual Conference.
Security Protocols and E-commerce University of Palestine Eng. Wisam Zaqoot April 2010 ITSS 4201 Internet Insurance and Information Hiding.
Chad La Joie Shibboleth’s Future.
Helsinki Institute of Physics (HIP) Liberty Alliance Overview of the Liberty Alliance Architecture Helsinki Institute of Physics (HIP), May 9 th.
Serving society Stimulating innovation Supporting legislation Danny Vandenbroucke & Ann Crabbé KU Leuven (SADL) AAA-architecture for.
SAML 2.0: Federation Models, Use-Cases and Standards Roadmap
Internet2 CAMP Shibboleth Scott Cantor (Hey, that’s my EPPN too.) Tom Dopirak Scott Cantor (Hey, that’s my.
Shibboleth at the U of M Christopher A. Bongaarts code-people June 2, 2011.
17 March 2008 © 2008 The University of Edinburgh, European Microsoft Innovation Center and University of Southampton IT Innovation Centre 1 NextGRID Security.
Connect. Communicate. Collaborate Place organisation and project logos in this area Usage of SAML in eduGAIN Stefan Winter, RESTENA Foundation TERENA Networking.
Shibboleth Akylbek Zhumabayev September Agenda Introduction Related Standards: SAML, WS-Trust, WS-Federation Overview: Shibboleth, GSI, GridShib.
Password Mistyping in Two-Factor Authenticated Key Exchange Vladimir KolesnikovCharles Rackoff Bell LabsU. Toronto ICALP 2008.
SSO Case Study Suchin Rengan Principal Technical Architect Salesforce.com.
Claims-Based Identity Solution Architect Briefing zoli.herczeg.ro Taken from David Chappel’s work at TechEd Berlin 2009.
THE DEVIL IS IN THE (IMPLEMENTATION) DETAILS: AN EMPIRICAL ANALYSIS OF OAUTH SSO SYSTEMS SAN-TSAI SUN & KONSTANTIN BEZNOSOV PRESENTED BY: NAZISH KHAN COMPSCI.
Access Management 2.0: UMA for the #UMAam20 for questions 20 March 2014 tinyurl.com/umawg for slides, recording, and more 1.
Shibboleth Akylbek Zhumabayev September Agenda Introduction Description WS Standards WS-Federation Picture Grid Security GridShib References 2.
Grid Authorization Landscape and Futures Von Welch NCSA
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential.
Andrew J. Hewatt, Gayatri Swamynathan and Michael T. Wen Department of Computer Science, UC-Santa Barbara A Case Study of the WS-Security Framework.
Claims-based security with Windows Identity Foundation.
Shibboleth 1.2 Technical Overview “So you thought 1.1 was complicated…” Scott Cantor The Ohio State University and Internet2 Scott Cantor.
Workshop on Security for Web Services. Amsterdam, April 2010 Applying SAML to Identity Data Exchange.
CLASSe PROJECT: IMPROVING SSO IN THE CLOUD Alejandro Pérez Rafael Marín Gabriel López
The FederID project The First Identity Management and Federation Free Software.
WSO2 Identity Server. Small company (called company A) had few services deployed on one app server.
Access Policy - Federation March 23, 2016
Dr. Michael B. Jones Identity Standards Architect at Microsoft
Federation made simple
Federation Systems, ADFS, & Shibboleth 2.0
SAML New Features and Standardization Status
HMA Identity Management Status
Data and Applications Security Developments and Directions
Identity management Aalto University, autumn 2013.
Introduction How to combine and use services in different security domains? How to take into account privacy aspects? How to enable single sign on (SSO)
OpenID Connect Working Group
The main cause for that are the famous phishing attacks, in which the attacker directs users to a fake web page identical to another one and steals the.
Presentation transcript:

Identity-Enabling Web Applications Scott Cantor Internet2/The Ohio State University

Introductions Previous life as an applications developer at OSU Web Single Sign-On developer / deployer / operator Internet2 MACE Middleware Architecture Committee for Education Shibboleth Project Technical Architect Author of Service Provider software and C++ OpenSAML libraries Standards Development SAML Technical Committee, SAML 2.0 Technical Editor Liberty Alliance Contributor

Outline Principals of Identity-Aware Design Web Authentication Overview Standards Marketplace Overview

Terminology Authentication Establishing “who” is accessing something, generally in a repeatable way. Credentials Collection Dialog with the user/client in order to perform authentication. Attributes Extensible set of data about an authenticated subject/principal/user. Broadly speaking, there tend to be authorization attributes and profile/demographic attributes. Web SSO Authentication to one virtual host based on authentication to another.

Identity-Aware Design Applications should fulfill their function, not try to be the center of the universe. Managing identity is not their function. Authentication is ALWAYS* out of bounds on the web. Abstraction, abstraction, abstraction: Partitioning design of application-specific user data vs. generic user data. Factoring out identity components doesn’t mean applications can’t include them.

Identifier-Aware Design Some properties discussed in eduPerson: persistence privacy uniqueness reassignment human palatability Understand and communicate your requirements instead of overloading data to address different use cases. Use flexible data models and patterns: Allow for easy renaming, aliases, etc. This is NOT the place to save time.

the notion of “local” users/passwords modularizing credentials collection vs. authentication assuming look and feel of authentication directly implementing security or data protocols or using protocol-specific APIs custom session management sloppy use of identifiers Gotchas

Be lazy, do less work. Design applications to function in a secure web environment: trust the web server. Use portable, language-neutral, CGI-oriented interfaces to access identity information in real- time. Alternatively use development “frameworks” that include good abstractions. Bundle a “default” identity source, without assuming it. Some Suggestions

Overview of Web Authentication HTTP Authentication Practically speaking, requires application servers to know user secrets. Out of step with reality. SSL/TLS Smart cards still show promise, but privacy-flawed. Hard to deploy and ultimately doesn’t scale. GSS / Kerberos Seamless for those with Kerberos clients and willingness to manage server principals. Some growth potential, but probably too rigid for non-enterprise scenarios. Web SSO Adaptations of distributed authentication protocols to browsers, redirects, forms, and cookies. Most flexible, can be federated (with an inverse relationship between trust and scale). Support strong authentication but ultimately can be weak. Information Cards Changes the game, though not adding much actual security yet. Usual chicken/egg deployment problem for the moment.

Web SSO: Axes for Comparison Open / Closed Source Standards-Based / Proprietary Formalized / Undocumented Federated / Non-Federated Attribute-Based / Identity-Based Module / API Passive Client / Active Client Holder of Key / Bearer N-Tier / 1-Tier

Some (Incomplete) Examples Pubcookie, Cosign, WebAuth Open, proprietary, non-federated, identity-based, modules, passive, some N-tier CAS Open, proprietary, non-federated, identity-based, APIs w/ some modules, passive, N-tier Shibboleth Open, standards-based and proprietary, federated, attribute-based, modules, passive Commercial Products (HP, Sun, IBM, Oracle, CA, BMC, etc.) Closed, standards-based and proprietary, federated, attribute-based, APIs w/ some modules, passive w/ some active Microsoft ADFSv1 Closed, proprietary, federated, attribute-based, modules and APIs, passive Microsoft Information Card Ecosystem (Identity Metasystem) Open and closed, proprietary, federated, attribute-based, modules and APIs, active and passive OpenID Open, proprietary, federated, identity-based w/ some attributes, API, passive

Some Personal Biases Open Standards-Based Federated Attribute-Based Module Passive (I want to get behind Active, but…) Bearer (see above) N-Tier

State of the Web SSO Ecosystem Non-federated protocols still widely used Attribute-based SSO growing in popularity, offers a lot of flexibility Proprietary systems gravitating toward standards (de facto or de jure) Multi-protocol systems increasingly common N-tier problem lacking widely acceptable standards OAuth emerging, but like OpenID seems to be rejecting prior art HTTP limitations complicate matters

Marketplace of Standards SAML WS-Federation Information Cards OpenID Kerberos

15 SAML Convergence ID-FF 1.1 SAML 1.0SAML 1.1 Shibboleth 1.x ID-FF 1.2 SAML

16 SAML 2.0: The Good Extensible technology-neutral security token framework Rich XML protocol for authentication, best-effort logout, simple provisioning Best of breed SSO protocol incorporating a lot of practice from proprietary systems Well-defined identifier types for privacy-oriented use cases Extensible metadata schema for exchange and provisioning of configuration and trust policy Modular specs enable formulation of new profiles that adapt SAML to new use cases or composition with other standards

17 SAML 2.0: The Bad and/or Ugly XML XML Signature (not required, but often needed) XML Encryption (ditto) Basic SSO profile has too many options Drawbacks of redirection-based SSO

WS-Federation Good Adds metadata to original draft spec, probably composes with WS-SecurityPolicy New work on “claims dialects” seems like an attempt at a calculus of user attributes Bad/Ugly Passive SSO is circa SAML 1.1, same general downsides re: redirection Active SSO amounts to WS-Trust, so why add this? Another tactical metadata schema? Logout is (or was) badly under-specified

Information Cards Microsoft’s profiles of WS-Trust, WS- SecurityPolicy: Client loads RP’s policy and user selects IdP that can satisfy policy Client authenticates to IdP and asks for a token Client delivers token to desktop application (e.g. browser) for delivery to RP Overall experience, including SSO, largely dependent on client

Information Cards Good Overall flow is really nice Allows RP to be hidden from IdP In theory, helps with phishing Self-assertion of data included in many card selectors via built-in IdP Key derivation and proof of possession included Bad Specs are complex, though RP side is less so Microsoft-controlled specs Client portability hit or miss for now Browser-based token delivery is bearer only for now Card/IdP selection still a work in progress

OpenID LiveJournal author’s simple, borderline-secure protocol for proving ownership of a URL (e.g. a blog) Became a bandwagon for every non-XML- flavored federated SSO effort Flow resembles typical SSO + dymamic metadata (XRDS) acquisition Main distinguishing feature is zero trust, the assumption that any OP can talk to any RP with no prior key exchange

OpenID Good Very simple HTTP-based protocol Metadata exchange based on a flexible XML standard (XRI and XRDS) Now includes attribute exchange Allows users to choose their own identifiers Bad Encouraging applications to weld themselves to one protocol Oversells the simplicity of running a good IdP Privacy often made the user’s problem Drawbacks of redirection-based SSO Arguably offers a shaky security foundation Allows users to choose their own identifiers