Shibboleth Update

1
Shibboleth Update

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

April 7, 2004
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.
• V1.2 available April, 2004
• 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

• Will coexist with Liberty Alliance and highly
  likely work within the WS- framework from
  Microsoft.
• OpenSAML.org is a derivative of this work
• Uses PKI underneath can support client PKI
• 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

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
InCommon federation

• Federation operations Internet2
• Federating software Shibboleth 1.1 and above
• Federation data schema - eduPerson200210 or later
  and eduOrg200210 or later
• Becomes operational April 5, with several early
  entrants to help shape the policy issues.
• Precursor federation, InQueue, has been in
  operation for about six months and will feed into
  InCommon
• http//incommon.internet2.edu

28
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

29
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

30
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

31
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

32
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

33
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

34
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

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
• Duke University

• Rutgers University
• University of Wisconsin
• New York University
• Georgia State University
• University of Washington
• University of California Shib 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
(No Transcript)