Shibboleth Update - PowerPoint PPT Presentation

Loading...

PPT – Shibboleth Update PowerPoint presentation | free to view - id: 5a52d-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Shibboleth Update

Description:

Hence, the criterion, test, or watchword of a party; a party cry or pet phrase. ... Common Shib adoption driver will likely be libraries who want to connect to ... – PowerPoint PPT presentation

Number of Views:55
Avg rating:3.0/5.0
Slides: 59
Provided by: michael722
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com