the application and the ecosystem. [email protected] acknowledgments home and scott cantor

17
The Application and the Ecosystem

Upload: brett-patrick

Post on 20-Jan-2016

220 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

The Application and the Ecosystem

Page 2: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Acknowledgments

• https://spaces.internet2.edu/display/fedapp/Home and Scott Cantor

Page 3: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Federating Applications

• What are the issues apps are finding in adapting to a federated world?

• What issues will they need to learn about in an attribute ecosystem• Sooner• Later

Page 4: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Federated Applications – The Core Issue

• We are still treating federation as an afterthought when this design would improve all web applications.

• The core problem is application developers still think their application must reimplement common business logic better resolved elsewhere – its not just passwords we should externalize.

Page 5: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Topics Areas Being Worked on Today

Page 6: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Applications and Federated Life - Today

• IdP discovery

• User Identification

• Session Management

• The Boarding Process

• Interfederation

Page 7: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

IdP Discovery – The Problem Space

• Federation creates the IdP discovery problem – where do you send them to authenticate? • In federations, we cannot expose user credentials to

authentication systems controlled by unrelated organizations.

• As a result, the authentication source has to be selected before credentials are supplied, either explicitly through user choice, or by deriving something from a user identifier.

• Need better coordination amongst providers before this becomes too complex for users.

Page 8: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

IdP Discovery Models

Models • SP/Embedded – e.g .Elsevier• Centralized/Shared

• SP-centric - e.g. NIH Federated Login gateway vs. federation/IdP centrice.g. WAYF, InCommon

•Common UI "trigger" for consistency

Page 9: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

IdP Discovery Work Arounds

• Workarounds • Initiating at the IdP – e.g. PSU gets to NIH

through the PSU research web site.• Hand out Per-IdP URLs (e.g. Google)

• Shared hints• Limiting discovery to expected IdPs• Geolocation

Page 10: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

GeoLocation Hints - EDUCAUSE

Page 11: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Oasis Work on Discovery

Page 12: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Web Authentication – Problem Space

• Web authentication involves proving the identity of a client and server to each Invokes lots of issues when externalized• Discovery• Authentication attributes & practices• Error Handling• Logout• Timers

Page 13: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Non-Web Authentication – Problem Space

• Authentication for non-web • TLS• OTP over TLS• SASL / GSS-API

• Project Moonshot• Tie to web authentication – iTunes example.

Page 14: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Project MoonShot –project-moonshot.org

Page 15: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Identity Assurance – Problem Statement

• Does 800-63 assurance levels adequately reflect good risk abatement techniques in a federated world, especially outside gov.• If not, is there anything better to use?

• Transitive trust arrangements

• LOA over time

• Self-service password resets

Page 16: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

The Next Round of Application Issues

• Logout• Provisioning and Deprovisioning• Metadata exchange - uApprove• Account Linking – transitive trust• Identity Assurance from the app view• Error handling • Federated Security Incident Handling

Page 17: The Application and the Ecosystem. kjk@internet2.edu Acknowledgments  Home and Scott Cantor

[email protected]

Acknowledgments

• https://spaces.internet2.edu/display/fedapp/Home and Scott Cantor