1. Michael R Gettes, Duke University On behalf of the shib project team
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)
CAMP Directory Workshop Feb 3-6, 2004

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)
CAMP Directory Workshop Feb 3-6, 2004

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?
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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.
CAMP Directory Workshop Feb 3-6, 2004

7. Stage 1 - Addressing Four Scenario’s
Member of campus community accessing licensed resource
Anonymity required
Member of a course accessing remotely controlled resource
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.
CAMP Directory Workshop Feb 3-6, 2004

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?
CAMP Directory Workshop Feb 3-6, 2004

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.)
CAMP Directory Workshop Feb 3-6, 2004

10. How Does it Work? Hmmmm…. It’s magic. :-)
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

13. Shibboleth AA Process Users Home Org Resource Owner 4
OK, I redirect your
request now to
the Handle Service
of your home org. 3 2
Please tell me
where are you from? 1
SHIRE
I don’t know you.
Not even which home
org you are from.
I redirect your request
to the WAYF
WAYF HS 5 6
I don’t know you.
Please authenticate
Using WEBLOGIN
Users Home Org
Resource Owner 7
User DB
Credentials
OK, I know you now.
I redirect your request
to the target, together
with a handle
Attributes 10
Manager
Resource
OK, based on the
attributes, I grant
access to the
resource
SHAR
Handle 8
I don’t know the
attributes of this user.
Let’s ask the Attribute
Authority
Handle 9 AA
Let’s pass over the
attributes the user
has allowed me to
release
Resource
CAMP Directory Workshop Feb 3-6, 2004

14. From Shibboleth Arch doc
Origin
Target
CAMP Directory Workshop Feb 3-6, 2004

15. From Shibboleth Arch doc
Origin
Target
CAMP Directory Workshop Feb 3-6, 2004

16. From Shibboleth Arch doc
Origin
Target 1
SHIRE
Local
Navigation
Page 3b 3 4
Handle
Service
Attribute Authority
CAMP Directory Workshop Feb 3-6, 2004

17. From Shibboleth Arch doc
Origin
Target
University
Resource Provider
HTTP Server 1
SHIRE
Local
Navigation
Page 3b
Authentication System 3 4
Enterprise
Directory
Handle
Service 6 5 3c
Attribute Authority
CAMP Directory Workshop Feb 3-6, 2004

18. Demo! http://shibboleth.blackboard.com/
CAMP Directory Workshop Feb 3-6, 2004

19. Shibboleth Architecture (still photo, no moving parts)
CAMP Directory Workshop Feb 3-6, 2004

20. Shibboleth Architecture -- Managing Trust
engine
Attribute
Server
Target Web Server
Browser
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

22. Typical Attributes in the Higher Ed Community
Affiliation
“active member of community”
EPPN
Identity
Entitlement
An agreed upon opaque URI
urn:mace:vendor:contract1234
OrgUnit
Department
Economics Department
EnrolledCourse
Opaque course identifier
urn:mace:osu.edu:Physics201
CAMP Directory Workshop Feb 3-6, 2004

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.
CAMP Directory Workshop Feb 3-6, 2004

24. Target – Managing Attribute Acceptance
Rules that define who can assert what…..
MIT can assert
Chicago can assert
Brown CANNOT assert
Important for entitlement values
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

26. What are federations? Initially “Authenticate locally, act globally”
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…
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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”
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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 vendor’s 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
CAMP Directory Workshop Feb 3-6, 2004

34. Who is Using Shibboleth?
CAMP Directory Workshop Feb 3-6, 2004

35. InQueue Origins 11.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
CAMP Directory Workshop Feb 3-6, 2004

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 (sigh, soon to be Shibbed…)
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

38. Other Technology Partners
LMS Systems
Blackboard
WebCT
WebAssign
Syquest/ Higher Markets
Student Charge Card vendors
Napster
CAMP Directory Workshop Feb 3-6, 2004

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)
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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?
CAMP Directory Workshop Feb 3-6, 2004

42. THE END? Acknowledgements:
Design Team: David Wasley UCOP; RL ‘Bob’ Morgan U of Washington; Keith Hazelton U of Wisconsin-Madison;Marlena 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)
CAMP Directory Workshop Feb 3-6, 2004

43. Global? Trust Diagram (TWD)
CAMP Directory Workshop Feb 3-6, 2004

44. Sample InterFederation
CAMP Directory Workshop Feb 3-6, 2004

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.
CAMP Directory Workshop Feb 3-6, 2004

46. Got SHIB?
CAMP Directory Workshop Feb 3-6, 2004

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)
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

50. Shib as WebISO
WebISO solutions have lots moving parts that are handled by Shib
So what’s the simplest AuthN shim for the HS?
CAMP Directory Workshop Feb 3-6, 2004

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!
CAMP Directory Workshop Feb 3-6, 2004

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)
CAMP Directory Workshop Feb 3-6, 2004

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?
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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
Ryan’s code supports failover to un/pw with LDAP (uses mod_perl)
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

57. The IdM Picture completed
To extent you Shibbify your target resources, this fills the gap of AuthZInfo delivery to web apps
You’ve authenticated by choice of methods (which can be passed along to targets)
You’ve given targets controlled access to user attributes
With all the knobs for privacy & anonymity you might want
CAMP Directory Workshop Feb 3-6, 2004

58. Shibboleth inter-realm: Federations
Shibboleth has support for federations (0, 1 or many)
Doesn’t prescribe how they work
Or even require one
e.g. Penn State <-> WebAssign is simple bilateral agreement
So what are federations, really?
CAMP Directory Workshop Feb 3-6, 2004

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 Moody’s)
As islands and networks inevitably collide, not clear how they’ll converge
CAMP Directory Workshop Feb 3-6, 2004

60. Renee Woodten Frost 6 February 2004
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.
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

63. Requirements for federations
Federation operations
Federating software
Exchange assertions
Link and unlink identities
Federation data schema
Federation privacy and security requirements
CAMP Directory Workshop Feb 3-6, 2004

64. Federated administrationVO VO O T
Apps CM O T
CM Apps
Other
feds
Campus 1
Campus 2 T T T
Federation
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

66. The Research and Education Federation Space
REF
Cluster
InQueue
(a starting point)
InCommon
SWITCH
The Shib
Research Club
Other national nets
Other clusters
Other
potential US
R+E feds
State of Penn
Fin Aid Assoc
NSDL
Indiana
Slippery slope
- Med Centers, etc
CAMP Directory Workshop Feb 3-6, 2004

67. InQueue The “holding pond”
Is a persistent federation with “passing-through” membership…
Operational today. Can apply for membership via InQueue Federation guidelines
Requires eduPerson attributes
Operated by Internet2; open to almost anyone using Shibboleth in an R&E setting or not…
Fees and service profile to be established shortly: cost-recovery basis
CAMP Directory Workshop Feb 3-6, 2004

68. InQueue origins as 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
CAMP Directory Workshop Feb 3-6, 2004

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.
CAMP Directory Workshop Feb 3-6, 2004

70. InCommon basics Permanent federation for the R&E 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
CAMP Directory Workshop Feb 3-6, 2004

71. InCommon federation Federation operations – Internet2 ProductionTeam
Federating software – Shibboleth 1.0 and above
Federation data schema - eduPerson or later and eduOrg 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
CAMP Directory Workshop Feb 3-6, 2004

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
CAMP Directory Workshop Feb 3-6, 2004

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?
CAMP Directory Workshop Feb 3-6, 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
CAMP Directory Workshop Feb 3-6, 2004