WebISO Survey of Technologies & Requirements

Nathan DorsUniversity of WashingtonCAMP, June 4-6, 2003

Copyright 2003 Nathan Dors. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

CAMP - June 4-6, 2003 2

Talk Overview

• Use scenarios• Requirements• Architectures• Target-side models• Available packages• WebISO “service” deployment issues• WebISO case study & numbers

CAMP - June 4-6, 2003 3

Use Scenarios

• An employee uses the campus portal to access her benefits information and to post her vacation dates on her online calendar, both in the same web browsing session.

• During a break, a student at the union bldg uses a public terminal to check his web-based email and review his course schedule.

CAMP - June 4-6, 2003 4

Use Scenarios++

• A library patron uses a public kiosk computer to browse resources provided by the university. Entitlements may be based on physical presence as well as affiliation.

• A doctor who is on faculty sets up a web-based quiz for a course and then reviews online patient information. The latter requires more rigorous means of authentication.

CAMP - June 4-6, 2003 5

Use Scenarios extreme

• A law student attempts to browse a licensed database of legal extracts on an external vendor’s website. The vendor and university are both piloting Shibboleth for inter-realm authorization.

CAMP - June 4-6, 2003 6

We Deduce That…

• The primary use environment is the Web• Interesting uses require authentication• But a few uses may not• Multi-tasking is common in users• Many uses beyond central IT control• We need a security framework for web-based

authentication!

CAMP - June 4-6, 2003 7

Defining WebISO

WebISOs are systems designed to allow users, with standard Web browsers, to authenticate

to web-based services across many Web servers, using a standard (typically username/password-based) central

authentication service.

CAMP - June 4-6, 2003 8

WebISO Goals

• Provide organization-wide authn infra• Expand middleware deployment• Establish common level of security• Centralize authentication services• Normalize authentication practices

– For applications– For end users

CAMP - June 4-6, 2003 9

WebISO Requirements

• Secure• Usable• Scalable• Dependable• Deployable• Comprendable

• Extensible• Supportable• Flexible• Affordable

CAMP - June 4-6, 2003 10

WebISO Requirements++

• Work with standard Web browsers• Leverage central authentication services• Reduce exposure of user passwords• Support single sign-on user experience• Integrate with common app frameworks• Deliver authentication info to applications

CAMP - June 4-6, 2003 11

WebISO Requirements extreme

• Provide multi-tiered authentication• Solve inter-institutional sign-on

CAMP - June 4-6, 2003 12

Integration Requirements

• Static web sites• Legacy applications• Open Source applications• No-source applications• Non-web-based applications

CAMP - June 4-6, 2003 13

Architecture: Components

• Authentication service• Weblogin service

– Web front-end to authn service– Makes authn assertions

• Web application agent (WAA)– WebISO integration layer– Receives and digests assertions

• Web application• Web browser

CAMP - June 4-6, 2003 14

Architecture: MessagingHow is the assertion made exactly?

• Methods– SAML POST browser profile– Artifacts put in the URLs– Sent in cookies– Back-channel service-to-service calls

• Formats– Many unique formats– Convergence toward SAML format?

CAMP - June 4-6, 2003 15

Sequence I: Direct Assertion

CAMP - June 4-6, 2003 16

Sequence II: Back Channel

CAMP - June 4-6, 2003 17

Architecture: Challenges

• Multi-tier scenarios (Source: Andrew Newman, Yale University)

– Impersonation: mid-tier pretends to be the user– Delegation: unauthenticated mid-tier presents

credentials on behalf of user– Proxy: fully authenticated mid-tier asserts

credentials (the user’s and its own)– Or, if need be, “whatever works”

• Session management• Global logout

CAMP - June 4-6, 2003 18

Target-side (WAA) Models

• Container-based approach– Apache module– Java servlet filter– ISAPI filter

• Code library (API) approach

CAMP - June 4-6, 2003 19

WAA Container-based Approach

• Pros– Supports many languages at once– No WebISO code in apps– REMOTE_USER is standardish– Encourages consistent practices

• Cons– Clunky and inflexible to some developers

CAMP - June 4-6, 2003 20

WAA Code Library Approach

• Pros– More flexible for developers– Better control of application flow– Web server independent

• Cons– Maintenance concerns– Less normalizating– Static content needs a shim

CAMP - June 4-6, 2003 21

But What Do Applications Get From A WebISO system?

• Authentication information– A principal: userid or user@realm– Authentication type?– Last Authenticated info?– SSO lifetime info?

• Additional attributes?– Sometimes, yes– In the wild, WebISOs do many things

CAMP - June 4-6, 2003 22

WebISO Software

• Pubcookie (Open Source project)• CAS (Yale)• Cosign (Michigan)• Shibboleth (Internet2)• Many others…

– A-Select– Bluestem– Sun ONE Identity Server

CAMP - June 4-6, 2003 23

Supporting Your Local WebISO

• What do you need beyond the software?• What are the technology management

issues?• What makes your WebISO system into a

campus WebISO “service”?

CAMP - June 4-6, 2003 24

WebISO “Service” Components

• WebISO system infrastructure• Service level agreement & description

– Internal, for your own good– Public, to set expectations

• Sysadmin/developer support– Installation guides– Policy & use guidelines, best practices– Where’s the authorization?

• End-user support/education• Web design & usability testing

CAMP - June 4-6, 2003 25

WebISO “Service” Management

• Use Policy Examples– Who can use the service?– When is it okay to override SSO?– Application design standards (e.g. logout buttons, language

usage, other best practices)– Recommended session timeouts

• Privacy & Security– University Policy on Privacy– Logging of authn/identity info (HIPAA, FERPA implications)– Auditability

CAMP - June 4-6, 2003 26

WebISO “Service” Management Cont.

• Growth Issues– Campus growth, outreach, and new affiliations

expand underlying authentication services– Guest accounts and other exceptions too

• Growth Implications for WebISO services– Must plan for additional server capacity– Must communicate that AuthN is not AuthZ!!– Pressure for more AuthZ services

CAMP - June 4-6, 2003 27

Case Study: UWash

• Central authn: Kerberos V, SecurID• WebISO system: Pubcookie (pre-3.0 currently)• Core team “roles”

– Sponsor– Overseer (Internet Architect)– Project Manager– Evangelist– Developers (2)– Hard to add up FTEs

• Others– sysadmins, support staff, usability engineers, writers

CAMP - June 4-6, 2003 28

UWash: Weblogin stats

• ~77,000 authentications per day• 1.9 apps per authentication (SSO usage)• 210 participating application servers• 41 participating departments• 350+ enabled applications

CAMP - June 4-6, 2003 29

UWash: Interesting Apps Integrated

• portal• webmail• employee self-service• student services (registration, etc)• Catalyst learning-management system• 802.11 wireless access• faculty/staff/student/dept/course web servers• hiring/payroll processing• JPMorgan for procurement/travelcards• ealumni.com for student/alum mentoring

CAMP - June 4-6, 2003 30

The End

For more information and to participate in the discussion

http://middleware.internet2.edu/webiso/