Shibboleth and InCommon: An Update and Next Steps

1
Shibboleth and InCommonAn Update and Next
Steps
2
Topics

• Background on Shibboleth
• Trust fabrics
• Federations and Federating Software
• InCommon
• Of particular interest
• Next Steps

3
Shibboleth AA Process
WAYF
Users Home Org
Resource Owner
Resource
4
Shibboleth Architecture
5
Shibboleth Architecture -- Managing Trust

• Federation

Shib engine
Attribute Server
Target Web Server
Browser
Target Site
Origin Site
6
Milestones

• Project formation - Feb 2000 Stone Soup
• Process - began late summer 2000 with bi-weekly
  calls to develop scenario, requirements and
  architecture.
• Linkages to SAML established Dec 2000
• Architecture and protocol completion - Aug 2001
• Design - Oct 2001
• Coding began - Nov 2001
• Alpha-1 release April 24, 2002
• OpenSAML release July 15, 2002
• v1.0 April 2003
• v1.1 July 2003
• V1.2 April 2004
• V2.0 likely end of the major evolution

7
Shibboleth Status

• Open source, privacy preserving federating
  software
• Being very widely deployed in US and
  international universities
• Target - works with Apache(1.3 and 2.0) and IIS
  targets Java origins for a variety of Unix
  platforms.
• V2.0 likely to include portal support, identity
  linking, non web services (plumbing to
  GSSAPI,P2P, IM, video) etc.
• Work underway on intuitive graphical interfaces
  for the powerful underlying Attribute Authority
  and resource protection
• 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.
• http//shibboleth.internet2.edu/

8
Adoption

• Over 40 universities using it for access to
  OCLC, JSTOR, Elsevier, WebAccess, Napster, etc.
• Common status is moving into production
• The hard part is not installing Shibboleth but
  running plumbing to it directories,
  attributes, authentication
• Deployments in Europe and the UK
• Development efforts broadening to the UK and
  Australia
• Likely to be the interrealm aspect to Sakai,
  Lionshare, video

9
Federated administration

• 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 (multilateral) those enterprise
  deployments with interrealm 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.

10
Federations

• Associations of enterprises that come together to
  exchange information about their users and
  resources in order to enable collaborations and
  transactions
• Enroll and authenticate and attribute locally,
  act federally.
• Uses federating software (e.g. Liberty Alliance,
  Shibboleth, WS-) common attributes (e.g.
  eduPerson), and a security and privacy set of
  understandings
• 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

11
Federated administration
VO
VO
O T
A CM
O T
CM A
Campus 1
Campus 2
T
T
T
Federation
12
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 and membership
  issues.
• Precursor federation, InQueue, has been in
  operation for about six months and will feed into
  InCommon
• http//www.incommonfederation.org

13
InQueue Origins2.12.04

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

• 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
• Georgetown
• Duke
• The Ohio State University
• UCLA
• Internet2
• Carnegie Mellon University

14
InCommon Management

• Operational services by I2
• Member services
• Backroom (CA, WAYF service, etc.)
• Governance
• Executive Committee - Carrie Regenstein - chair
  (Wisconsin), Jerry Campbell, (USC), Lev Gonick
  (CWRU), Clair Goldsmith (Texas System), Mark
  Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan
  Perry (Mellon), Mike Teetz, (OCLC), David
  Yakimischak (JSTOR).
• Project manager Renee Frost (Internet2)
• Membership open to .edu and affiliated business
  partners (Elsevier, OCLC, Napster, Diebold, etc)
• Contractual and policy issues being defined now
• Likely to take 501(c)3 status

15
Trust in InCommon - initial

• Members trust the federated operations to perform
  its activities well
• The operator (Internet2) posts its procedures,
  attempts to execute them faithfully, and makes no
  warranties
• Enterprises read the procedures and decide if
  they want to become members
• Origins and targets trust each other bilaterally
  in out-of-band or no-band arrangements
• Origins trust targets dispose of attributes
  properly
• Targets trust origins to provide attributes
  accurately
• Risks and liabilities managed by end enterprises,
  in separate ways

16
InCommon Trust - ongoing

• Use trust ?? Build trust cycle
• Clearly need consensus levels of I/A
• Multiple levels of I/A for different needs
• Two factor for high-risk
• Distinctive requirements (campus in Bejing or
  France, distance ed, mobility)
• Standardized data definitions unclear
• Audits unclear
• International issues

17
The potential for InCommon

• The federation as a networked trust facilitator
• Needs to scale in two fundamental ways
• Policy underpinnings need to move to normative
  levels among the members post and read is a
  starting place
• Inter-federation issues need to be engineered we
  are trying to align structurally with emerging
  federal recommendations
• Needs to link with PKI and with federal and
  international activities
• If it does scale and grow, it could become a most
  significant component of cyberinfrastructure

18
Beyond web services

• Federated security services
• Collaborative incident correlation and analysis
• Trust-mediated transparency and other
  security-aware capabilities
• Federated extensions to other architectures
• Lionshare project for P2P file sharing
• IM
• Federated Grids

19
Next Steps

• Shibboleth
• The GUIs SysPriv, Autograph, MySpace
• Linked identities
• New development model international
  participation
• InCommon
• Policy development
• Membership
• Distnguishing buyers clubs from federations

20
GUIs to manage Shibboleth
21
SysPriv ARP GUI

• A tool to help administrators (librarians,
  central IT sysadmins, etc) set attribute release
  policies enterprise-wide
• For access to licensed content
• For linking to outsourced service providers
• Has implications for end-user attribute release
  manager (Autograph)
• GUI design now actively underway, lead by
  Stanford
• Plumbing to follow shortly

22
End-user attribute release manager(Autograph)

• Intended to allow end-users to manage release
  policies themselves and, perhaps, understand the
  consequences of their decisions
• Needs to be designed for everyone even though
  only 3 will use it beyond the defaults.
• To scale, must ultimately include extrapolation
  on settings, exportable formats, etc.

23
Privacy Management Systems
24
Personal Resource Manager
25
Virtual Organizations

• Geographically distributed, enterprise
  distributed community that shares real resources
  as an organization.
• Examples include team science (NEESGrid, HEP,
  BIRN, NEON), digital content managers (library
  cataloguers, curators, etc), life-long learning
  consortia, etc.
• On a continuum from interrealm groups (no real
  resource management, few defined roles) to real
  organizations (primary identity/authentication
  providers)
• Want to leverage enterprise middleware and
  external trust fabrics

26
Virtual organizations

• Need a model to support a wide variety of use
  cases
• Native v.o. infrastructure capabilities,
  differences in enterprise readiness, etc.
• Variations in collaboration modalities
• Requirements of v.o.s for authz, range of
  disciplines, etc
• JISC in the UK has lead solicitation is on the
  streets (see (http//www.jisc.ac.uk/c01_04.html)
  builds on NSF NMI
• Tool set likely to include seamless listproc, web
  sharing, shared calendaring, real-time video,
  privilege management system, etc.

27
Leveraging V.O.s Today
VO
User
Federation
Enterprise
Target Resource
28
Leveraged V.O.s Tomorrow
VO
User
Collaborative Tools Authority System etc
Federation
Enterprise
Target Resource
29
Stanford Authz Model
30
Authr Deliverables

• The deliverables consist of
• A recipe, with accompanying case studies, of how
  to take a role-based organization and develop
  apprpriate groups, policies, attributes etc to
  operate an authority service
• Templates and tools for registries and group
  management
• a Web interface and program APIs to provide
  distributed management (to the departments, to
  external programs) of access rights and
  privileges, and
• delivery of authority information through the
  infrastructure as directory data and authority
  events.

31
Home
32
Grant Authority Wizard
33
Person