Shibboleth Update

1
Shibboleth Update

• Michael R Gettes, Duke University
• On behalf of the shib project team

2
What is Shibboleth? (Biblical)

• A word which was made the criterion by which to
  distinguish the Ephraimites from the Gileadites.
  The Ephraimites, not being able to pronounce
  sh, called the word sibboleth. See --Judges
  xii.
• Hence, the criterion, test, or watchword of a
  party a party cry or pet phrase.
• Webster's Revised Unabridged Dictionary (1913)

3
What is Shibboleth? (modern era)

• An initiative to develop an architecture and
  policy framework supporting the sharing between
  domains -- of secured web resources and services
• A project delivering an open source
  implementation of the architecture and framework
• Deliverables
• Software for Origins (campuses)
• Software for targets (vendors)
• Operational Federations (scalable trust)

4
So What is Shibboleth?

• A Web Single-Signon System (SSO)?
• An Access Control Mechanism for Attributes?
• A Standard Interface and Vocabulary for
  Attributes?
• A Standard for Adding Authn and Authz to
  Applications?

5
Shibboleth Goals

• Use federated administration as the lever have
  the enterprise broker most services
  (authentication, authorization, resource
  discovery, etc.) in inter-realm interactions
• Provide security while not degrading privacy.
• Attribute-based Access Control
• Foster interrealm trust fabrics federations and
  virtual organizations
• Leverage campus expertise and build rough
  consensus
• Influence the marketplace develop where
  necessary
• Support for heterogenity and open standards

6
Attribute-based Authorization

• Identity-based approach
• The identity of a prospective user is passed to
  the controlled resource and is used to determine
  (perhaps with requests for additional attributes
  about the user) whether to permit access.
• This approach requires the user to trust the
  target to protect privacy.
• Attribute-based approach
• Attributes are exchanged about a prospective user
  until the controlled resource has sufficient
  information to make a decision.
• This approach does not degrade privacy.

7
Stage 1 - Addressing Four Scenarios

• Member of campus community accessing licensed
  resource
• Anonymity required
• Member of a course accessing remotely controlled
  resource
• Anonymity required
• Member of a workgroup accessing controlled
  resources
• Controlled by unique identifiers (e.g. name)
• Intra-university information access
• Controlled by a variety of identifiers
• Taken individually, each of these situations can
  be solved in a variety of straightforward ways.
• Taken together, they present the challenge of
  meeting the user's reasonable expectations for
  protection of their personal privacy.

8
Shibboleth Status

• V1.1 available August 2003
• Relatively straightforward to install, provided
  there is good web services understanding and
  middleware infrastructure (authentication,
  directories, webISO, etc.).
• Target - works with Apache and IIS targets Java
  origins.
• V2.0 likely to include portal support.
• Work underway on some of the essential management
  tools such as attribute release managers, target
  resource management, etc.
• Can take between 3 hours and 3 years to install
• How much infrastructure (core middleware) do you
  already have?

9
Shibboleth Status

• Likely to coexist well with Liberty Alliance and
  may work within the WS framework from Microsoft.
• Growing development interest in several
  countries, providing resource manager tools,
  digital rights management, listprocs, etc.
• Used by several federations today NSDL,
  InQueue, SWITCH and several more soon (JISC,
  Australia, etc.)

10
How Does it Work?

• Hmmmm. Its magic. -)

11
High Level Architecture

• Federations provide common Policy and Trust
• Destination and origin site collaborate to
  provide a privacy-preserving context for
  Shibboleth users
• Origin site authenticates user, asserts
  Attributes
• Destination site requests attributes about user
  directly from origin site
• Destination site makes an Access Control Decision
• Users (and origin organizations) can control what
  attributes are released

12
Technical Components

• Origin Site Required Enterprise Infrastructure
• Authentication
• Attribute Repository
• Origin Site Shib Components
• Handle Server
• Attribute Authority
• Target Site - Required Enterprise Infrastructure
• Web Server (Apache or IIS)
• Target Site Shib Components
• SHIRE
• SHAR
• WAYF
• Resource Manager

13
Shibboleth AA Process
WAYF
Users Home Org
Resource Owner
Resource
14
From Shibboleth Arch doc
Origin
Target
15
From Shibboleth Arch doc
Origin
Target
16
From Shibboleth Arch doc
Origin
Target
17
From Shibboleth Arch doc
Origin
Target
3c
18
Demo!

• http//shibboleth.blackboard.com/

19
Shibboleth Architecture (still photo, no moving
parts)
20
Shibboleth Architecture -- Managing Trust

TRUST
Shib engine
Attribute Server
Target Web Server
Browser
21
Attribute Authority --Management of Attribute
Release Policies

• The AA provides ARP management tools/interfaces.
• Different ARPs for different targets
• Each ARP Specifies which attributes and which
  values to release
• Institutional ARPs (default)
• administrative default policies and default
  attributes
• Site can force include and exclude
• User ARPs managed via MyAA web interface
• Release set determined by combining Default and
  User ARP for the specified resource

22
Typical Attributes in the Higher Ed Community
Affiliation active member of community member_at_washington.edu
EPPN Identity gettes_at_duke.edu
Entitlement An agreed upon opaque URI urnmacevendorcontract1234
OrgUnit Department Economics Department
EnrolledCourse Opaque course identifier urnmaceosu.eduPhysics201

23
Trust, and Identifying Speakers

• Federations distribute files defining the trust
  fabric
• Individual sites can create bilateral trust
• When a target receives a request to create a
  session, the Authn Assertion must be signed by
  the origin (PKI validation), and the origin must
  be a member of a common Federation.
• When an Origin receives a request for
  attributes, it must be transported across SSL.
• The name of the Requestor (from the certificate)
  and the name of the user (mapped from the
  Handle) are used to locate the appropriate ARP.

24
Target Managing Attribute Acceptance

• Rules that define who can assert what..
• MIT can assert student_at_mit.edu
• Chicago can assert staff_at_argonne.gov
• Brown CANNOT assert student_at_mit.edu
• Important for entitlement values

25
Managing Authorization

• InCommon will NOT require members to do business
  with each other
• Target manages Access Control Policy specifying
• what attributes must be supplied
• and from which origins
• in order to gain access to specific resources
• Rules are attribute based

26
What are federations?

• Associations of enterprises that come together to
  exchange information about their users and
  resources in order to enable collaborations and
  transactions
• Built on the premise of
• Initially Authenticate locally, act globally
• Now, Enroll and authenticate and attribute
  locally, act federally.
• Federation provides only modest operational
  support and consistency in how members
  communicate with each other
• Enterprises (and users) retain control over what
  attributes are released to a resource the
  resources retain control (though they may
  delegate) over the authorization decision.
• Over time, this will all change

27
Why Shibboleth

• Higher Ed is a collaborative enterprise
• Faculty have strong ties to peers at other
  institutions
• With wed-based IMS systems, faculty share
  resources with their peers
• Research is a collaborative enterprise
• Robert Zimmer reported that during the next three
  to five years, Brown will establish several
  multidisciplinary centers or institutes that will
  bring faculty expertise and resources together in
  optimal ways, possibly through collaboration with
  other institutions.
• Research in the future will be all about
  collaboration and distributed research groups
  that are facilitated through technology. -
  Andries van Dam, VP Research, Brown University

28
Why Shibboleth? Security

• Better security tools will make collaboration
  more painless and more secure
• Current "solutions" are primitive we can do
  better today and without local overhaul
• Shibboleth Simplifies Management and Use of
  Distributed Systems

29
Why Shibboleth?Improved Access Control

• Use of attributes allows fine-grained access
  control
• Simplifies management of access to extended
  functionality
• Librarians, based on their role, are given a
  higher-than-usual level of access to an online
  database to which a college might subscribe.
• Librarians and publishers can enforce complicated
  license agreements that may restrict access to
  special collections to small groups of faculty
  researchers

30
Why Shibboleth?Federated Administration

• Leverages existing middleware infrastructure at
  origin (authN, dir)
• Users registered only at their home or origin
  institution
• Target does NOT need to create new userids
• Flexibly partitions responsibility, policy,
  technology, and trust
• Authorization information sent, instead of
  authentication information
• when possible, use groups instead of people on
  ACLs
• identity information still available for auditing
  and for applications that require it

31
Why Shibboleth?Privacy

• Higher Ed has privacy obligations
• In US, FERPA requires permission for release of
  most personal identification information
  encourages least privilege in information access
• General interest and concern for privacy is
  growing
• Shibboleth has active (vs. passive) privacy
  provisions built in

32
Benefits to Campuses

• Much easier Inter-Domain Integration
• With other campuses
• With off-campus vendor systems
• Integration with other campus systems,
  intradomain
• LMS
• Med School
• Ability to manage access control at a
  fine-grained level
• Allows personalization, without releasing
  identity
• Implement Shibboleth once
• And then just manage attributes that are released
  to new targets

33
Benefits to Targets/Vendors

• Unified authentication mechanism from the vendor
  perspective
• Much more scalable
• Much less integration work required to bring a
  new customer online.
• Ability to implement fine-grained access control
  (e.g. access by role), allowing customer sites to
  effectively control access by attributes and thus
  control usage costs, by not granting access
  unnecessarily
• Once the initial Shibboleth integration work has
  been completed on the vendors systems
• The incremental cost of adding new customers is
  relatively minimal
• In contrast to the current situation -- requiring
  custom work for each new customer
• Ability to offer personalization
• If your customers have Shibboleth implemented,
  easy implementation for them

34
Who is Using Shibboleth?
35
InQueue Origins11.25.03

• National Research Council of Canada
• Columbia University
• University of Virginia
• University of California, San Diego
• Brown University
• Penn State University
• Cal Poly Pomona
• London School of Economics
• University of North Carolina at Chapel Hill
• CU-Boulder
• UT Arlington
• UTHSC-Houston
• University of Michigan

• Rutgers University
• University of Wisconsin
• New York University
• Georgia State University
• University of Washington
• University of California Shibboleth Pilot
• University at Buffalo
• Dartmouth College
• Michigan State University
• Shibboleth Development Origin
• The Ohio State University
• UCLA
• Internet2
• Carnegie Mellon University

36
Shib academic SIG

• Lots of interesting design issues for use of
  Shib, e.g
• Passing attributes during deep-linked text
• Handling meta-search engines
• Managing persistent identifiers where needed
• Dealing with proxies in a semi-Shibbed world
• The issues so far have all been solvable the
  challenge is in picking the right solution.
• Subscribe and participate via the I2 listserv at
  http//www.internet2.edu/about/lists.html (sigh,
  soon to be Shibbed)

37
Currently participating publishers, aggregators,
technology partners

• Round 1
• OCLC
• JSTOR
• EBSCO
• Elsevier
• Ex-Libris (sfx)
• Round 2 (being approached now)
• CSA (Cambridge Scientific Abstracts)
• ISI
• Ovid
• Proquest
• Gale Group
• Lexis-Nexis

38
Other Technology Partners

• LMS Systems
• Blackboard
• WebCT
• WebAssign
• Syquest/ Higher Markets
• Student Charge Card vendors
• Napster

39
Other Pilot Projects

• American Association of Medical Colleges
• NSDL (National Science Digital Library)
• SWITCH - The Swiss National Academic Community
• UK/JISC - Controlled Access to Licensed Resources
• Becta (British Educational Communications and
  Technology Agency)
• Univ Texas, Medical Center and instruction
• Washington Research Library Consortium (WRLC)

40
Shibboleth -- Next Steps

• Full implementation of Trust Fabric
• Supporting Multi-federation origins and targets
• Support for Dynamic Content (Library-style
  Implementation in addition to web server plugins)
• Sysadmin GUIs for managing origin and target
  policy
• Grid, Virtual Organizations
• ? Saml V2.0, Liberty, WS-Fed
• NSF grant to Shibboleth-enable open source
  collaboration tools
• LionShare - Federated P2P

41
So What is Shibboleth?

• A Web Single-Signon System (SSO)?
• An Access Control Mechanism for Attributes?
• A Standard Interface and Vocabulary for
  Attributes?
• A Standard for Adding Authn and Authz to
  Applications?

42
THE END?

• Acknowledgements
• Design Team David Wasley UCOP RL Bob Morgan U
  of Washington Keith Hazelton U of
  Wisconsin-MadisonMarlena Erdos IBM/Tivoli
  Steven Carmody Brown Scott Cantor Ohio State
• Important Contributions from Ken Klingenstein
  (I2) Michael Gettes (Duke) Scott Fullerton
  (Madison)
• Coding Derek Atkins (MIT) Parviz Dousti (CMU)
  Scott Cantor (OSU) Walter Hoehn (Columbia)

43
Global? Trust Diagram (TWD)
44
Sample InterFederation
45
Shib/PKI Inter-Federations

• This model demonstrates the similarities of the
  PKI communities and Shib Federations. This does
  not mean that Shib PKI, just that we can
  leverage the trust infra of a global PKI to maybe
  solve some larger inter-federation issues of
  other techno / policy spaces in a common fashion.

46
Got SHIB?
47
Shibboleth intra- as well as inter-realm

• Keith Hazelton
• University of Wisconsin
• I2 Middleware Arch. Comm. for Education

48
Shib intra/inter-realm

• Common Shib adoption driver will likely be
  libraries who want to connect to electronic
  resource providers
• Leveraging Shib as local infrastructure
  intra-realm Shibboleth (with AuthN shim) as
  completion of the IdM loop giving apps the info
  they need to make access control decisions
  (AuthZInfo Access)

49
Shib as WebISO

• Note Shib as shipped assumes an existing WebISO
• But in a Shib environment for web apps
• the only web thing that needs an authentication
  step is the Handle Server (HS) (!!!)
• all target web apps leverage that single
  authentication step

50
Shib as WebISO

• WebISO solutions have lots moving parts that are
  handled by Shib
• So whats the simplest AuthN shim for the HS?

51
Shib as WebISO

• HS runs as an Apache app
• How do we protect Apache apps?
• URL/directory based authN schemes
• Use Apache config file fiddling to specify how
• Shib 1.1 as shipped has way to do this with
  Public Key Infrastructure (PKI) user certs
• Apache Asks for client SSL authentication via
  apache-ssl or mod_ssl
• Right environment variables get populated, presto!

52
Shib as WebISO PKI integ.

• U California System developed PKI support code
  (David Walker)
• Adopted adapted by UT-HSC Houston (Barry
  Ribbeck Mark Jones)
• ..and by Dartmouth (Bob Brentrup, Omen Wild
  Mark Franklin)

53
Shib PKI Migration

• Calif, Texas Dartmouth pushing PKI, so happy to
  force its use for selected apps
• Most of us not there yet
• What if HS could try for PKI as above, but fail
  over to LDAP-supported un/pw AuthN over SSL?

54
Shib PKI Migration

• More generally Protect the HS app the Apache way
  with PKI, failover to your favorite AuthN
  service here
• So, coordinating with above named culprits, Ryan
  Muldoon at wisc.edu developed an Apache
  module-based approach

55
Shib HS AuthN Shim

• Apache security directives in config allow you to
  specify a list of AuthN methods in order of
  preference, So
• Try PKI via above approach
• Second on the list is a module that does your
  favorite AuthN trick populates env. vars. Like
  REMOTE_USER
• Ryans code supports failover to un/pw with LDAP
  (uses mod_perl)

56
Shib HS AuthN Shim

• Kerberos shops could write a module for Kerberos
  AuthN, etc.
• Allows transparent
• migration to, or
• experimentation with or
• selective rollout
• of PKI behind Shib HS for a general web app
  AuthN solution

57
The IdM Picture completed

• To extent you Shibbify your target resources,
  this fills the gap of AuthZInfo delivery to web
  apps
• Youve authenticated by choice of methods (which
  can be passed along to targets)
• Youve given targets controlled access to user
  attributes
• With all the knobs for privacy anonymity you
  might want

58
Shibboleth inter-realm Federations

• Shibboleth has support for federations (0, 1 or
  many)
• Doesnt prescribe how they work
• Or even require one
• e.g. Penn State lt-gt WebAssign is simple
  bilateral agreement
• So what are federations, really?

59
A Burton Group slide from Catalyst 2003 in San
Francisco

• Towards a polycentric, federated environment

• Many islands will emerge
• Identity networks will link the islands
• Centralized services
• Member owned services (as in the ATM world)
• Use of common rating systems (like Moodys)
• As islands and networks inevitably collide, not
  clear how theyll converge

60
Federations

• Renee Woodten Frost
• 6 February 2004

61
Federated all the way down

• Given the strong collaborations within the
  academic community, there is an urgent need to
  create inter-realm tools, so
• Build consistent campus middleware infrastructure
  deployments, with outward facing objectclasses,
  service points, etc. and then
• Federate (multi-lateral) those enterprise
  deployments with inter-realm attribute
  transports, trust services, etc. and then
• Leverage that federation to enable a variety of
  applications from network authentication to
  instant messaging, from video to web services,
  from p2p to virtual organizations, etc. while we
• Be cautious about the limits of federations and
  look for alternative fabrics where appropriate.

62
Federations

• Associations of enterprises that come together to
  exchange information about their users and
  resources in order to enable collaborations and
  transactions
• Built on the premise of
• Initially, Authenticate locally, act globally
• Now, Enroll and authenticate and attribute
  locally, act federally.
• Uses federating software (e.g. Liberty Alliance,
  Shibboleth, WS-) and common attributes (e.g.
  eduPerson)
• Enterprises (and users) retain control over what
  attributes are released to a resource the
  resources retain control (though they may
  delegate) over the authorization decision.
• Several federations now in construction or
  deployment

63
Requirements for federations

• Federation operations
• Federating software
• Exchange assertions
• Link and unlink identities
• Federation data schema
• Federation privacy and security requirements

64
Federated administration
VO
VO
O T
O T
Apps CM
CM Apps
Other feds
Campus 1
Campus 2
T
T
T
Federation
65
Shibboleth-based federations

• InQueue
• InCommon
• Club Shib
• Swiss Education and Research Network (SWITCH)
• National Science, etc. Digital Library (NSDL)
• ------------------------------------
• State networks
• Medical networks
• Financial aid networks
• Life-long learning communities

66
The Research and EducationFederation Space
Indiana
Slippery slope - Med Centers, etc
67
InQueue

• The holding pond
• Is a persistent federation with passing-through
  membership
• Operational today. Can apply for membership via
  http//shibboleth.internet2.edu/ InQueue
  Federation guidelines
• Requires eduPerson attributes
• Operated by Internet2 open to almost anyone
  using Shibboleth in an RE setting or not
• Fees and service profile to be established
  shortly cost-recovery basis

68
InQueue originsas of 11-25-03

• Rutgers University
• University of Wisconsin
• New York University
• Georgia State University
• University of Washington
• University of California
• University at Buffalo
• Dartmouth College
• Michigan State University
• Shibboleth Development Origin
• The Ohio State University
• UCLA
• Internet2
• Carnegie Mellon University

• National Research Council of Canada
• Columbia University
• University of Virginia
• University of California, San Diego
• Brown University
• Penn State University
• Cal Poly Pomona
• London School of Economics
• University of North Carolina at Chapel Hill
• CU-Boulder
• UT Arlington
• UT Health Science Center-Houston
• University of Michigan

69
Major targets

• Campuses that are also origins, wanting to share
  campus-based content
• Content providers EBSCO, OCLC, JSTOR, Elsevier,
  Napster, etc
• Learning Management Systems WebCT, Blackboard,
  OKI, etc
• Outsourced Service Providers purchasing
  systems, dormitory management companies, etc.

70
InCommon basics

• Permanent federation for the RE US sector
• To be operated by Internet2, open to
  .edu-qualified sites and business partners
• Attributes passed eduPerson
• Privacy requirements to be developed
• Security requirements to be developed

71
InCommon federation

• Federation operations Internet2 ProductionTeam
• Federating software Shibboleth 1.0 and above
• Federation data schema - eduPerson200210 or later
  and eduOrg200210 or later
• Federation privacy and security requirements in
  discussion could be
• Privacy requirements
• Initially, destroy received attributes
  immediately upon use
• Security requirements
• Initially, enterprises post local I/A and basic
  business rules for assignment of
  eduPersonAffiliation values
• Likely to progress towards standardized levels of
  authentication
• Logout issues

72
InCommon planning steps

• Planning activities by ad hoc group of CIOs from
  participating organizations
• Decided initial form is that of an Internet2
  project
• Set criteria for membership
• Drafted InCommon Prospectus
• Developed an initial management structure
• Executive Committee of members, generally CIOs or
  content provider reps
• Staggered 3-year terms, nominated by participants
  in InCommon with input from NPPAC
• Facilitated by Internet2
• Internal process being engineered with oversight
  by technical experts

73
InCommon current status

• InCommon Executive Committee established and
  meeting bi-weekly via conference calls
• Advising on internal processes
• Drafting campus policy statements, framework for
  sharing
• Tuning Prospectus
• Discussing pricing
• Internet2 building infrastructure
• InCommon CA
• Redundant WAYF
• Web Sites and Communications
• Open doors - ? Spring 2004?

74
InCommon, some time from now

• Established with several hundred participants
• Multi-layered strength-of-trust threads among
  participants
• Working with state and/or regional federations
• Peering with national federations in other
  countries
• Gateways with commercial federations