What Lies Ahead: Grids, Shibboleth, PKI Ken Klingenstein, Director, Internet2 Middleware Initiative Copyright Ken Klingenstein 2003. This work is the intellectual

What Lies Ahead:Grids, Shibboleth, PKI

Ken Klingenstein,Director, Internet2 Middleware Initiative

Copyright Ken Klingenstein 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish

requires written permission from the author.

Base CAMP - February 5-7, 2003 2

Overview

• Grids – next generation distributed computing, data and instrumentation environments

• Shibboleth – inter-institutional web services and enriched middleware architecture

• PKI – encryption and authentication tools


A Map of Middleware Land


Grid Basics

• Complex software environments for the sharing of cycles, storage, remote instrumentation, etc.

• The more general the software, the more that is left to the reader…


Facts about Grids

• There are many distributed computing and resources sharing environments besides Grids.

• Much big science and medicine will be based on Grids• Grids come in many flavors• Global Grid Forum attempts to coordinate flavors • Among the flavors, there is a predominant strain

– Developed out of ISI, Argone, etc by Kesselman, Foster, et al

– Current instantiation is Globus Toolkit 2.0 (part of NMI)

– Next generation is Open Grid Services Architecture (OGSA)


More facts about Grids

• Grids are stand-alones, tending not to recognize firewalls, enterprise services, usability requirements, privacy, politics of resource sharing, etc.

• Two distinct types of Grids are emerging– Intragrids – users on the outside access an

internal grid that supplies cycles, storage, etc transparently

– Intergrids – a shared mesh of resources among autonomous enterprises


Globus and OGSA

• John McGee – ISI


Shibboleth

•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):


Stage 1 - Addressing Three Scenario’s

•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)

•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.


Attribute-based authorization

•There is a spectrum of approaches available for attribute-based management of access to controlled resources, • At one end is the attribute-based approach, where attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach does not degrade privacy.• At the other end is the identity-based approach, where 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. Since this leads with identity, this approach requires the user to trust the target to protect privacy.


Rethinking Privacy

•Passive privacy - The current approach. •A user passes identity to the target, and then worries about the target’s privacy policy. To comply with privacy, targets have significant regulatory requirements. The user has no control, and no responsibility. And no one is happy...

•Active privacy - A new approach. •A user (through their security domain) can release the attributes to the target that are appropriate and necessary. If the attributes are personally identifiable. If the attributes are personally identifiable, the user decides whether to release them. The user has control, along with commensurate responsibility. All parties are happy, maybe…


Establishing a User Context


Getting Attributesand Determining Access


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

•v0.7 Shibboleth released Nov 25, 2002

•v0.8 March 1, 2003

•v1.0 April 2003

•v1.1 conversations ruminating; v1.2 may be the plateau


Shibboleth and SAML

•SAML is specifying a format and a means to exchange authentication and authorization assertions•Shibboleth builds a general purpose public infrastructure around SAML by

–developing user-navigation services, –standards to manage the exchange of attributes, –standard sets of attributes to be exchanged, and –infrastructure and user tools to preserve and manage privacy.–supporting groups using a common policy model; a scaleable solution

to common needs•SAML is creating a middleware equivalent of an IP address. Shibboleth adds services equivalent to DNS, routing, etc, to create a middleware equivalent of the Internet.


Code status

•v0.7 released November 2002 (note switch to numbering) (coding teams – MIT, Columbia, Ohio State, CMU)

•v0.7 much easier to install than alpha’s. C/C++ only on origin. Java still on target. Relatively safe to deploy and experiment

•Release issues – platform dependencies, fragile Apache components, binaries vs source, etc…

•v0.7 to v0.8

• new features – ARP’s redone, added robustness

• timeframes – march 1, 2003 general release

•V0.8 to 1.0 – bug fixes and re-packaging only; due out before spring I2 member meeting


Early Adopters

•WebCT•Webassign•National Digital Science Library•EBSCO•The Library pilot


What is the library pilot?

•A dozen+ campuses working with 6 information vendors•Using Shibboleth to control access to electronic resources•Good test case for privacy requirements, trust model needs


Project Goals

•Explore and Evaluate the utility of the Shibboleth model (attributes) for controlling access to licensed resources•Identify problems and issues with this approach

–How well do existing licenses map to attributes?–Library “walk-in” customers

•Identify and address Shib deploy issues for campuses AND for vendors•Explore new possibilities


Campus Participants

•Carnegie Mellon•Columbia•Dartmouth•Georgetown•London School of Economics•New York Unv.•Ohio State

Penn State

U. Colorado

U. Michigan

U. Washington

U. Wisconsin - Madison

UCOP (U. California System)

U.Texas Health Science Center

at Houston


Vendor Participants

•EBSCO• ~ Elsevier•OCLC•Sfx (Ex libris)•JSTOR•McGraw Hill eBooks•Proquest


Shibboleth Deployment Issues•Access Issues• Kiosks and walk-ins• logins for on-campus use•Licensing issues• reconciling license structures with directory structures• system and consortial issues• mitigating disintermediation•Functional issues• handling Shibbed and non-Shibbed resources• roll-out strategies• entitlements vs attributes• what attributes to pass• how to structure the attribute name space


Next steps

•Convergence with other efforts•Shibboleth the architecture vs Shibboleth the web service•Shibboleth the technology vs Club Shib the trust model•Federated Digital Rights Management•Federated P2P •Privacy Management Systems – see http://www.ischool.washington.edu/shibbui/index.html•Personal Information Managers – see http://www.brown.edu/cgi-bin/httool.epl


Personal Resource Manager


Privacy Management Systems


PMS-2


Long-term implications of Shib

• Interrealm basic exchanges of information for access control– The web service: Digital rights management– The architecture: Desktop video-conferencing– The trust model:

• Accelerating related technologies– Privacy– PKI


Trust models

• Authenticate locally, act globally raises the fundamental question “Why should a remote target trust your remote authentication and attributes?”

• “Solutions” are global trust, federated trust, virtual organization, no need for formal trust…


Key Trust Structures•Hierarchies

–may assert stronger or more formal trust–requires bridges and policy mappings to connect hierarchies–appear larger scale

•Federated administration–basic bilateral (origins and targets in web services)–complex bilateral (videoconferencing with external MCU’s, digital rights

management with external rights holders)–multilateral

•Virtual organizations–Shared resources among a sparse, distributed set of users–Grids, virtual communities, some P2P applications–Want to leverage other trust structures above


Federations

•A group of organizations (universities, corporations, content providers, etc.) who agree to exchange attributes using the SAML/Shibboleth/Liberty protocols. In doing so they agree to abide by common sets of rules.

•The required rules and functions could include:

–A registry to process applications and administer operations

–A set of best practices on associated technical issues, typically involving security and attribute management

–A set of agreements or best practices on policies and business rules governing the exchange and use of attributes.

–The set of attributes that are regularly exchanged (syntax and semantics).

–A mechanism (WAYF) to identify a user’s security domains

–Ways to federate and unfederate identities


Federations in the last year

•Communicator Hub ID is one of the pioneering Liberty•Alliance-based services on the market, supporting vertical-industry B2B•offerings such as SecuritiesHub. SecuritiesHub, which is sponsored by eight leading Wall Street investment firms, including Credit Suisse First Boston, Goldman Sachs, JPMorgan, Lehman Brothers, Merrill Lynch, Morgan Stanley, Salomon Smith Barney and UBS Warburg.•Liberty Alliance (http://www.projectliberty.org/)•Federal e-Authentication Initiative (http://www.cio.gov/eauthentication/)•Not much use of federated .NET•Shibboleth and InCommon (http://middleware.internet2.edu/shibboleth)


Federating organizations organization (FOO)

•To explore the issues in federations, and multiple federations, and subclubs, and…•Includes GM, Johnson and Johnson, Bechtel, Liberty, Microsoft, Fed e-AuthN•Discussions just started...•Friends of foo as an email list to stay informed of the discussions


Authorization

•Expressions of authorization

• x.509 attribute certs, SAML expressions, rights languages, policy languages, meta…

•Linking expressions to infrastructure middleware

• groups in directories

• registries

• attribute authorities

• securing the feeds

•Making decisions on authorization

• entitlements vs attributes – who decides

• within the apps

• decision points versus enforcement points


PKI

• Didn’t it die?• There is no substitute for many services that

PKI can provide• It is not a universal panacea • It will continue to evolve until we get it right


Uses for PKI

• Server side SSL certificates• End-entity identity certs• VPN certs for channel encryption• Signed email• Attribute certs• Signing enterprise SAML assertions


Types of PKI

• Intrarealm– Primarily stand-alone– Classic corporate VPN/web-authn/secure shell

• Interrealm– Hierarchical– Bridged– Federated enterprise


PKI deployments

• Intra-realm– A moderate percentage of large corps– A few uses at a few institutions:

• Texas/Houston – web authn, secure shell, signed email• Virginia - VPN• MIT – web authn

• Inter-realm– Only public-sector activity, primarily government

and higher ed


Shibboleth and PKI

•Complementary technologies•Technically:

–Shibboleth leverages existing campus authentication processes (and can use end-entity certificates for this process)

–Shibboleth uses PKI to implement a multi-domain trust model–Shibboleth’s primary use is for authorization and privacy–PKI’s primary use is establishing identity across domains–PKI can use Shibboleth to achieve privacy and authorization.

•Policy: –Shibboleth establishes a collaborative trust model (flexible, quick,

privacy-enabled, etc.)–PKI establishes a legal trust model (binding, hierarchical, formal,

etc.).


Deploying A Campus PKI

• Establishing CA services– Out-source– In-source

• Getting a profile and a policy/practice doc• Solving the annoying problems

– Mobility– Operating system gotchas

• PKI-enabling applications


PKI in the last year

•FPKI efforts and the FBCA•The HEBCA•The demise of CREN•Sean Smith and his interesting research…• faking security…macros and screen manipulation• faking privacy…unlocking the cert store and playing Go Fish


Current Interrealm Activities

• Federal Bridge Certificate Authority• Higher Ed Bridge Certificate Authority


Relating PKI to the federated approach

• Well, at one level, PKI identities should anchor federated activities.

• At a more operational level, federated activities need to either– Peer with PKI activities (at a bridge?)– Interact with other federated activities

Documents

What Lies Ahead: Grids, Shibboleth, PKI Ken Klingenstein, Director, Internet2 Middleware Initiative Copyright Ken Klingenstein 2003. This work is the intellectual