Improving Extending the Shibboleth Identity Provider User Experience Keith Hazelton University of Wisconsin-Madison William G. Thompson, Jr. Unicon, Inc. Dmitriy Kopylenko Unicon, Inc. © Copyright Unicon, Inc., Some rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. To view a copy of this license, visit Internet2 Member Meeting October 5 th 2011

2 Agenda 1.Introduction 2.Approach 3.Solution 4.Next Steps

3 Introduction

4 Shib at UW-Madison ● Overview of current UW shib deployment

5 Problem Statement ● How to extend the Shib IdP with local behavior for the following needs: – Inform users of options when they don't have authZ for a particular service. – User controlled attribute release – Terms of Use, Acceptable Use, Security, Privacy, or any ol' policy a user must click through.

6 Google Apps for HE ● Description of failure mode and what we'd like instead.

7 Broken SP? ● Why “fixing the SP” is not enough...

8 Terms of Use... ● Terms of Use ● Acceptable Use Policy ● Privacy Policy ● Security Policy ● Any special messaging/notification/click thru requirement based on user attributes

9 Attribute Release ● uApprove redux

10 Goals ● Extensible, customizable login experience that covers: – Course grained AuthZ and UX that helps users – ToU/AUP read/write login flows – User controlled attribute release ● Alignment with SAML2, Shibboleth, InCommon communities

11 Approach ● Engage with Shib community early and often – Alignment with future direction – Architecturally sound ● Build for UW, share with the Shib community

12 Roadmap ● Phase I (completed July 2011) – Development environment (build/deploy/debug) – Architecture analysis – Community feedback ● Phase II (completed October 2011) – Proof-of-concept Spring Web Flow / IdP integration – Community feedback ● Phase III (target Jan 2012) – Incorporate community feedback – Package and document for production release at UW – Share with the community

13 Demonstration

14 Solution IdP2 and SWF perfect together!

15 Design Goals ● Minimally invasive to the IdP ● Simple but not simplistic ● Easily extended to other login flow use cases ● Easily customized for local needs ● Decoupled from IdP as much as possible

16 IdP Integration ● Login flow is extended via SWF outside of and separate from the IdP ● Small and simple filter...inspiration from uApprove ● Filter determines overall flow state and hands offs to SWF when appropriate ● Filter provides access to user attributes and service metatdata in SWF ● Can be selectively applied to profile endpoints via web.xml

20 Spring Web Flow ● An extension to Spring MVC that allows you to define Controllers using a domain-specific-language. This language is designed to model user interactions that require several requests into the server to complete, or may be invoked from different contexts. ● Used to meet these design goals: – Simple but not simplistic – Easily extended to other login flow use cases – Easily customized for local needs

23 Solution Dependancies ● Tomcat Cross Context – Forward request server-side to swf post login flow – Shared state to control flow signaling between swf and idp ● emptySessionPath – shares session cookie between servlet contexts. One JSessionId, two session objects. Enables swf to reuse idp session cookie. ● PostLoginFlowFilter and web.xml config ● SWF to suit your needs

24 Next Steps ● Give it a whirl... – – ● Feedback, help, comments, suggestions,... ● Review, Refactor ● Finalize UW post login flow requirements and implement ● Deploy into production at UW ● Share with the community

25 Questions & Answers Keith Hazelton University of Wisconsin-Madison William G. Thompson, Jr. Unicon, Inc.