Security and Privacy Renee Woodten Frost Program Manager, Middleware Initiatives, Internet2 I2...

Security and Privacy

Renee Woodten Frost

Program Manager, Middleware Initiatives, Internet2

I2 Middleware Liaison, University of Michigan

Telemedicine Symposium, Ann Arbor

August 24, 2001

Telemedicine Symposium August 24, 2001

Topics

Security: based in Middleware technology

Medical Middleware

Core middleware: the basic technologies

Issues, Good Practices, Current Activities

Identifiers

Authentication

Directories

Authorization

PKI

Shibboleth

Video


Middleware Initiatives Acknowledgements

Middleware Architecture Committee for Education (MACE) and the working groups

Early Harvest - NSF catalytic grant and meeting

Early Adopters – testbed campuses

Higher Education partners - campuses, GRIDs, EDUCAUSE, CREN, AACRAO, NACUA, etc.

Corporate partners - IBM, ATT, SUN, et al.

Government partners - including NSF and the fPKI TWG

International interactions


Remedial IT Architecture

The proliferation of customizable applications requires a centralization of “customizations”

The increase in power and complexity of the network requires access to user profiles

Electronic personal security services is now an impediment to the next-generation computing grids

Inter-institutional applications require inter-operational deployments of institutional directories and authentication


What is Middleware?

Specialized networked services that are shared by applications and users

A set of core software components that permit scaling of applications and networks

Tools that take the complexity out of application integration

A second layer of the IT infrastructure,sitting above the network

A land where technology meets policy

The intersection of what networks designers and applications developers each do not want to do


Specifically…

Digital libraries need scalable, interoperable authentication and authorization.

The Grid is a new paradigm for a computational resource; Globus provides middleware, including security, location and allocation of resources, and scheduling. This relies on campus-based services and inter-institutional standards.

Instructional Management Systems need authentication and directories.

Next-generation portals want common authentication and storage.

Academic collaboration requires restricted sharing of materials between institutions.

What Internet1 did with communication, Internet2 may do with collaboration.


Medical Middleware

Unique requirements - HIPAA, disparate relationships, extended community, etc.

Unique demands - 7x24, visibility

PKI seen as a key tool

MACEMed – representatives from academic medical centers - formed to explore the issues


The complex challenges of academic medical middleware

Intra-realm issues - multiple vendors, proprietary systems, evolving regulations

Enterprise issues - security, directories, authorization; balance of institutional and medical enterprises

Inter-realm issues - standards, gateways, common operational processes and policies, performance

Multiple communities of interest - institutional, medical center, affiliated hospitals, state and federal regulatory and certification organizations, insurance companies, medical researchers, etc.


The applications view of medical upperware

Server (in this scenario)

DoD Clinical System

Client (in this scenario)

VA Clinical System

Request lab data, This Soldier, this time frame

Who’s asking? What role? What is need to know?

ResourceAccess

Decision(RAD)

Who is this person? Who knows this person?

PersonIdentification

Service (PIDS)

Where is lab info on this person?

Health Information

Locator Service (HILS)

Convert to server’s terms

Terminology Query Service

(TQS)outbound

Clinical Observation

Access Service(COAS)

Requestobservation


The Grid

A model for a distributed computing environment, addressing diverse computational resources, distributed databases, network bandwidth, object brokering, security, etc.

Globus (www.globus.org) is the software that implements most of these components; Legion is another such software environment

Needs to integrate with campus infrastructure

Gridforum (www.gridforum.org) umbrella activity of agencies and academics

Look for grids to occur locally and nationally, in physics, earthquake engineering, etc.


A Map of Middleware


Core Middleware

Identity - unique markers of who you (person, machine, service, group) are

Authentication - how you prove or establish that you are that identity

Directories - where an identity’s basic characteristics are kept

Authorization - what an identity is permitted to do

PKI, etc - emerging tools for security services


Major Campus Identifiers

UUID

Student and/or emplid

Person registry ID

Account login ID

Enterprise-LAN ID

Student ID card

Net ID

Email address

Library/departmental ID

Publicly visible ID (and pseudo-SSN)

Pseudonymous ID


General Identifier Characteristics

Uniqueness (within a given context)Dumb vs intelligent (i.e. whether subfields have meaning)Readability (machine vs human vs device)Affordance (centrally versus locally provided)Resolver approach (how identifier is mapped to its associated object) Metadata (both associated with the assignment and resolution of an identifier)Persistence (permanence of relationship between identifier and specific object)Granularity (degree to which an identifier denotes a collection or component)Format (checkdigits)Versions (can the defining characteristics of an identifier change over time)Capacity (size limitations imposed on the domain or object range)Extensibility (the capability to intelligently extend one identifier to be the basis for another identifier).


Important Characteristics

Semantics and syntax - what it names and how does it name it

Domain - who issues and over what space is identifier unique

Revocation - can the subject ever be given a different value for the identifier

Reassignment - can the identifier ever be given to another subject

Opacity - is the real world subject easily deduced from the identifier - privacy and use issues


Identifier Mapping Process

Map campus identifiers against a canonical set of functional needs

For each identifier, establish its key characteristics, including revocation, reassignment, privileges, and opacity

A key first step towards the loftier middleware goals


Authentication Options

Password-based• Clear text• LDAP• Kerberos (Microsoft or K5 flavors)

Certificate-based

Others: challenge-response, biometrics

Inter-realm is now the interesting frontier


Authentication Issues

User side management - crack, change, compromise

Central-side password management - change management, OS security

First password assignment - secure delivery

Policies - restrictions or requirements on use


Authentication Good Practices

Precrack new passwords

Precrack using foreign dictionaries as well as US

Confirm new passwords are different than old

Require password change if possibly compromised

Use shared secrets or positive photo ID to reset forgotten passwords

US Mail a one-time password (time-bomb)

In-person with a photo ID (some require two)

For remote faculty or staff, an authorized departmental representative in person, coupled with a faxed photo ID

Initial identification/authentication will emerge as a critical component of PKI


User ID/Password Authentication Risky

Too, too many user ID/password pairs to remember

Too easy to share passwords

User’s perception as to password’s importance

Passwords used online can easily be captured

Separate user ID/password pairs used to determine authorization rights

Too many individuals other than a user can alter a user’s password


Digital IDs (Certificates)Authentication

Password known only to “owner”

Password never transmitted on the network

Digital ID verified by a third party

Digital ID globally recognized

Multiple mechanisms for detecting revoked digital ID

Can be a strong, two factor authentication process


Directories

To store certificates

To store Certificate Revocation Lists (CRL)

To store private keys, for the time being

To store attributes

Implement with border directories, or Access Control Lists (ACLs) within the enterprise directory, or proprietary directories


Directory Issues

Applications

Overall architecture• chaining and referrals, redundancy and load balancing,

replication, synchronization, directory discovery

The Schema and the DIT (Directory Tree)• attributes, organizational units (ou), naming, object

classes, groups

Attributes and indexing

Management• clients, delegation of access control, data feeds


A Campus Directory Architecture

metadirectory

enterprisedirectory

directorydatabase

departmentaldirectories

OS directories(MS, Novell, etc)

borderdirectory

registries sourcesystems


Directory Management Good Practices

No trolling permitted; more search than read

LDAP client access versus web access

Give deep thought to who can update

Give deep thought to when to update

LDIF likely to be replaced by XML as exchange format

Delegation of control - scalability

“See also”, referrals, replication, synchronization in practice

Replication should not be done tree-based but should be filtered by rules and attributes


Current Activities in Directories

LDAP Recipe

eduPerson

MACE-DIR working group

Directory of Directories for Higher Education

Metadirectories


LDAP Recipe

How to build and operate a directory in higher education

1 Tsp. DIT planning 1 Tbsp. schema design 3 oz. configuration 1000 lbs. of data

Good details, such as tradeoffs/recommendations on indexing, how and when to replicate, etc.

http://www.georgetown.edu/giia/internet2/ldap-recipe/


eduPerson

A directory object class intended to support inter-institutional applications

Fills gaps in traditional directory schema

For existing attributes, states good practices where known

Specifies several new attributes and controlled vocabulary to use as values

Provides suggestions on how to assign values, but leaves it to the institution to choose

Version 1.0 standard; v 1.5 under discussion


Issues about Upper Class Attributes

EduPerson inherits attributes from Person, inetOrgPerson

Some of those attributes need conventions about controlled vocabulary (e.g. telephones)

Some of those attributes need ambiguity resolved via a consistent interpretation (e.g. email address)

Some of the attributes need standards around indexing and search (e.g. compound surnames)

Many of those attributes need access control and privacy decisions (e.g. JPEG photo, email address, etc.)


New eduPerson Attributes

edupersonAffiliation

edupersonPrimaryAffiliation

edupersonOrgDN

edupersonOrgUnitDN

edupersonPrincipalName

edupersonNickname


eduPersonAffiliation

Multi-valued list of relationships an individual has with institution

Controlled vocabulary includes: faculty, staff, student, alum, member, affiliate, employee

Applications that use: Shibboleth, digital libraries, Directory of Directories for Higher Ed


eduPersonPrincipalName

userid@securitydomain

EPPN may look like an email address, but it is used by different systems

One must be able to authenticate against the EPPN

Used in inter-realm authentication such as Shibboleth

In some situations, it can be used for access control lists; if used, a site should make sure what the reassignment policy is


MeduPerson

Is there a need for a MeduPerson?

New initiative to define a Medical Person specification for use with AAMC’s faculty roster system application

Ultimate goal of leveraging registry and directory efforts


Key Issues for Mace-Dir

Revisions to eduPerson 1.0

Internationalization of eduPerson; extension to GridPerson, MeduPerson

Affiliated Directories

Groups within directories

Groups between institutions


A Directory of Directories (DoDHE)

An experiment to build a combined directory search service

To show the power of coordination

Will highlight the inconsistencies between institutions

Technical investigation of load and scaling issues, centralized and decentralized approaches

Human-interface issues - searching large name spaces with limits by substring, location, affiliation, etc...

Sun donated server and iPlanet license (6,000,000 DN’s)

Michael Gettes of Georgetown is project lead


Metadirectories

www.architech.no is now Metamerge

Higher Education Contact for USA• Keith Hazelton, University of Wisconsin – Madison

[email protected]

This product is available free of charge to Higher Ed in USA

Source code will be in escrow.


Public Key Infrastructure (PKI)

Software, protocols, and legal agreements necessary to effectively use certificates:

- Certificate Authority

- Registration Authorities

- PKI management tools

- Directories to store certs, public keys, maybe private

- Database and key-management software

- Applications – certificate-enabled

- Trust models (hierarchy and bridges)

- Policies


Current State of PKI

Why PKI?

The Four Stages of PKI

Other sectors• Federal Activities - fBCA, NIH Pilot, ACES, other• Healthcare - HIPAA• State governments - E-Sign, Draft CP• Corporate Deployments • European activities

The Industry

Higher Ed – PAG, TAG, PKI Labs


Why PKI?

Single infrastructure to provide all security services

Established technology standards, though little operational experience

Elegant technical underpinnings

Serves dozens of purposes - authentication, authorization, object encryption, digital signatures, communications channel encryption

Low cost in mass numbers


Why Not PKI?

High legal barriers

Lack of mobility support

Challenging user interfaces, especially with regard to privacy and scaling

Persistent technical incompatibilities

Overall complexity


D. Wasley’s PKI Puzzle


The Four Planes of PKI

On the road to general purpose inter-realm PKI

The planes represent different levels of simplification from the dream of a full inter-realm, intercommunity, multipurpose PKI

Simplifications in policies, technologies, applications, scope

Each plane provides experience and value


The Four Planes are

Full inter-realm PKI - (Boeing 777) - multipurpose, spanning broad and multiple communities, bridges to unite hierarchies, unfathomed directory issues

Simple inter-realm PKI - (Regional jets) - multipurpose within a community, operating under standard policies and structured hierarchical directory services

PKI-light - (Corporate jets) - containing all the key components of a PKI, but many in simplified form; may be for a limited set of applications; can be extended within selected communities

PKI-ultralight (Ultralights) - easiest to construct and useful conveyance; ignores parts of PKI and not for use external to the institution; learn how to fly, but not a plane...


Examples of Areas of Simplification

Spectrum of Assurance Levels

Signature Algorithms Permitted

Range of Applications Enabled

Revocation Requirements and Approaches

Subject Naming Requirements

Treatment of Mobility...


PKI-Light example

CP: Wasley, etal. Draft HE Certificate Policy reduced to basic/rudimentary

CRL: ?

Applications: (Signed email)

Mobility: Password enabled

Signing: md5RSA

Thumbprint: sha1

Naming: dc

Directory Services needed: InetOrgPerson


PKI-Ultralight

CP: none

CRL: limited lifetime

Applications: VPN, Internal web authentication

Mobility: not specified

Signing: not specified

Thumbprint: sha1

Naming: not specified

Directory Services needed: none


Federal Activities

fBCA

NIH Pilot

fPKI TWG

others

Internet2/NIH/NIST research conference...


Healthcare

HIPAA - Privacy specs issued

HIPAA - Security specs not yet done

Two year compliance phase-ins

Little progress in community trust agreements

Non-PKI HIPAA Compliance Options


Corporate deployments

Success stories within many individual corporations for VPN, authentication

No current community

ABA guidelines

Others...


State Governments

UCITA

NECCC Draft State Certificate Policy


Other countries

EuroPKI

Extensive work in the Netherlands

Inter-governmental discussions?


The Industry

What's the problem with PKI then? It all boils down to one thing: Complexity.


The Industry

Baltimore Technologies in peril

PKIforum slows down

OASIS-SAML work gains buzz

RSA buys Securant


The Industry

Browsers that don’t take community roots

Communications tools that want certificates we don’t want to give them

Path math that sometimes doesn’t compute

Technology that doesn’t interoperate...


Higher Education

HEBCA

HEPKI-TAG

HEPKI-PAG

PKI Labs

Shibboleth

Campus successes


Bridgework

Federal• Federal production Bridge

• Intended to blend several existing agency PKI (DoD, Energy) and new agency efforts (NIH, Energy, GAO)

• Needs a killer app

• Wants to peer with other bridges, e.g. HEBCA

Higher Ed• In principle, to be operated by EDUCAUSE

• May be one-off software at first, and out-sourced as feasible

• Has a draft policy modeled after FBCA

• Needs software

• Needs CA’s to bridge among - commercial, CREN, Globus, etc.


HEPKI

HEPKI - Technical Activities Group (TAG)• universities actively working technical issues• topics include Kerberos-PKI integration, public domain

CA, profiles• will sponsor regular conf calls, email archives

HEPKI - Policy Activities Group (PAG)• universities actively deploying PKI• topics include certificate policies, RFP sharing,

interactions with state governments• will sponsor regular conf calls, email archives


HEPKI-TAG

Chaired by Jim Jokl, Virginia

Certificate profiles• survey of existing uses• development of standard presentation• identity cert standard recommendation

Mobility options - SACRED scenarios

Public domain software alternatives

Protection of the institutional private key

Discussions of CA software


HEPKI-PAG

David Wasley, prime mover

Draft certificate policy for a campus

HEBCA certificate policy

FERPA

State Legislatures

Gartner Decision Driver software


Internet2 PKI labs

At Dartmouth and University of Wisconsin in computer science departments and IT organizations

Doing the deep research - two to five years out

Policy languages, path construction, attribute certificates, etc.

National Advisory Board of leading academic and corporate PKI experts provides direction

Catalyzed by startup funding from ATT

Research conference with NIST this fall


Of Security, Privacy, and Trust

Is it security or is it liability?

Liability has other remedies, including disclaimers, contractual sharing of responsibilities, indemnification, etc…

Is it privacy or is it discretion?

How much can privacy be protected? When do we want our privacy given up?

Is it trust or is it contractual?

Our notions of trust are soft, contradictory, volatile, intuitive, and critical to how we act in the world.


Inter-organizational trust model components

Certificate Policy- uses of particular certs, assurance levels for I/A, audit and archival requirements

Certificate Practices Statement- the nitty gritty operational issues

CA- CA Trust - Hierarchies vs Bridges• a philosophy and an implementation issue

• the concerns are transitivity and delegation

• hierarchies assert a common trust model

• bridges pairwise agree on trust models and policy mappings


Certificate policies (CP) address

Legal responsibilities and liabilities (indemnification issues)

Obligations of issuing, user, and relying parties

Operations of Certificate Management systems

Assurance levels - varies according to I/A processes and other operational factors

The goal is to limit the number of different policies; differences require bridges


Major Parts of a CP

The community to whom the policy is applicable (campuses and members of the campus)

Roles, responsibilities and liabilities for • CAs,

• RAs,

• end-entities,

• relying parties

Operational and technical requirements on CA

Identification and authentication requirements for each level of certificate

Certificate profile


Certificate practice statements (CPS)

Site specific details of operational compliance with a Cert Policy

A single practice statement can support several policies (CHIME)

A Policy Management Authority (PMA) determines if a CPS is adequate for a given CP.

The goal is to have a CPS that you can live with and be audited against.


Trust chains

Verifying sender-receiver assurance by finding a common trusted entity

Must traverse perhaps branching paths to establish trust paths

Must then use CRLs etc. to validate assurance

If policies are in certificate payloads, then validation can be quite complex

Constraints makes things even harder

Bridges makes things even harder


Trust chains

Path construction• to determine a path from the issuing CA to a trusted CA• heuristics to handle branching that occurs at bridges

Path validation• uses the path to determine if trust is appropriate• should address revocation, key usage, basic constraints,

policy mappings, etc.


Trust chains

When and where to construct and validate• off-line - on a server - at the discretion of the application• depth of chain

Some revocations better than others - major (disaffiliation, key compromise, etc.) and minor (name change, attribute change)

Sometimes the CRL can’t be found or hasn’t been updated


Mobility options

Smart cards

USB dongles

Passwords to download from a store or directory

Proprietary roaming schemes abound - Netscape, VeriSign, etc.

SACRED within IETF recently formed for standards

Difficulty in integration of certificates from multiple stores (hard drive, directory, hardware token, etc.)


Moving along

CA software

Medical requirements for certificates

Simple path construction and validation

A draft certificate policy for campuses, finally


Where to follow activities in other communities

PKIX (http://www.ietf.org/html.charters/pkix-charter.html)

Federal PKI work (http://csrc.nist.gov/pki/twg/)

State Governments (http://www.ec3.org/)

Medical community (Tunitas, CHIME, HIPAA, Healthkey)

Automobile community (ANX)

Overseas• Euro government - qualifying certs

• EuroPKI for Higher Ed (http://www.europki.org/ca/root/cps/en_index.html)


Where to watch for HE

http://middleware.internet2.edu/

http://www.educause.edu/hepki/

http:// www.cren.org

http://csrc.nist.gov/pki/twg/

http://www.tunitas.com/pages/PKI/pki.htm


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


Shibboleth

An initiative to analyze & develop mechanisms (architectures,frameworks, protocols & implementations) for inter-institutional web access control

“Authenticate locally, act globally”

Facilitated by MACE (a committee of leading higher-ed IT architects) & I2

Designed by key campus and IBMTivoli IT architects, with other corporate involvement

Coding an open source reference implementation based on Apache

Oriented towards privacy and complements corporate standards efforts


Isn’t This What PKI Does?

PKI does this and a whole lot more; as a consequence, PKI does very little right now

End-to-end PKI fits the Shibboleth model, but other forms of authentication do as well

Uses a lightweight certificate approach for inter-institutional communications - uses the parts of PKI that work today (server side certificates) and avoids the parts of PKI that don’t work today (eg client certificates).

Allows campuses to use other forms of authentication locally

May actually have benefits over the end-user-to-target-site direct interactions...


Relationship - Shibboleth to Portals

PDPAuthN

Dir

Shibboleth

Portal

ShibbolethShibboleth

Portal

AppsWebRes

WebLogin

Dir

WebResource

Shibboleth


Related Work

Previous DLF work

http://www.clir.org/diglib/presentations/cnis99/sld001.htm

OASIS Technical Committee (vendor activity, kicked off 1/2001)

http://www.oasis-open.org/committees/security/index.shtml

http://lists.oasis-open.org/archives/security-services/

UK - Athens and Sparta projects

http://www.jisc.ac.uk/pub00/sparta_disc.html

Spain - rediris project

http://www.rediris.es/app/papi/index.en.html


Assumptions

Use federated administration as the model

Leverage vendor and standards activity wherever possible

Disturb as little of the existing campus infrastructure as possible

Work with common, minimal authorization systems (e.g. htaccess)

Encourage good campus behaviors

Learn through doing

Create a marketplace and reference implementations

Avoid being another dead guppy

Build in at the core protections for personal privacy


Development Process

Scenarios leading to requirements

Establish model architectures for common services and scenario-specific services

Develop service and protocol requirements

Identify service options, begin protocol development

Produce open implementations of missing service components; provide external services as needed


Stage 1 - Addressing Three 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)

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.


Model

Local Authentication

Local Entity Willing to Create and Sign Entitlement• set of assertions about the user (attribute/value pairs)• user has control over disclosure• attributes may be personally identifiable (e.g Name) or translucent (e.g.

“active member of community”, “Associated with Course XYZ”)

Target Responsible for Authorization• Rules engine• Matches contents of entitlements against rule set associated with

target object

Cross-Domain Trust• Previously created between origin and target• Perhaps there is a contract (information providers...)


Target Web

Server

Origin Site Target Site

Browser

AttributeServer Shib

htaccessplugin

Club Shib Server (holds

certs and contracts)

Shibboleth ArchitectureConcepts #1 (managing trust)


OASIS/SAML Effort

SAML is a standards effort functioning under the multi-corporate OASIS XML business group.

SAML is slowly grappling with many of the issues in inter-realm exchanges of information about authentication and authorization, but with a B2B perspective.

SAML appears capable of standardizing some pieces:• an XML format for "assertions" of both names/identities

and entitlements/privileges/attributes• a request/response protocol for obtaining assertions• transport bindings for this protocol to HTTP, S/MIME,

RMI, etc.

SAML and Shibboleth are interacting in development and should interoperate

http://www.oasis-open.org/committees/security/


Personal Privacy

Personal Information is released to site X based on:

• Contract provisions

• Current request from the target

• User control!

Getting the defaults right on privacy will be very important and very hard. (Or, 15 pop-up questions before getting to a web page may not be well-received…)


Campus and Resource Requirements

To Participate in Shibboleth, a site must have:

• Campus-wide authentication service

• Campus-wide identifier space (EPPN)

• Implementation of eduPerson objectclass

• Ability to generate attributes (eg “active member of the community”)

• Apache web server

• The ability to reach agreements with other campuses and information providers


Issues

Personal Privacy (reasonable expectation, laws)

Relation to local web login (Single Sign On)

Portals

Use of Shibboleth framework by services beyond the web

Grid resources and users


Project Status/Next Steps

Requirements and Scenarios document finished

Internet2 intends to have an Apache web module developed

Internet2 intends to develop supporting materials (documentation, installation, etc.) and web tools (for htaccess construction, filter and access control, remote resource attribute discovery)

Technical design completed - architecture and specifications

Coding to begin soon

Pilot site start-up - August 2001


VidMid - video working group

Recently formed international working group

Looking at a variety of tools - vic/vat, H.323, MPEG-2, HDTV

Point-to-point and MCU options

H.323 desktop video within reach at physical layer

Lacks identifiers and authentication; ePPN and Shibboleth-type flow could address within the framework of SIP.

Http://middleware.internet2.edu/video


Activities

MACE - RL “Bob” Morgan (Washington)

Early Harvest / Early Adopters - Renee Frost (Michigan)

LDAP Recipe - Michael Gettes (Georgetown)

eduPerson - Keith Hazelton (Wisconsin)

Directory of Directories - Michael Gettes (Georgetown)

metadirectories - Keith Hazelton (Wisconsin)

Shibboleth - Steven Carmody (Brown)

PKI Labs - Dartmouth and Wisconsin

HEPKI-TAG and -PAG - Jim Jokl (Virginia) and Ken Klingenstein (Colorado)

HEBCA - Mark Luker (EDUCAUSE)

Vidmid - International leadership

Opportunities - the Grid, K-12


More information

Early Harvest / Early Adopters - http://middleware.internet2.edu/earlyadopters/

MACE - middleware.internet2.edu

LDAP Recipe - http://www.georgetown.edu/giia/internet2/ldap-recipe/

eduPerson - www.educause.edu/eduperson

Directory of Directories - middleware.internet2.edu/dodhe

Shibboleth - middleware.internet2.edu/shibboleth

HEPKI-TAG - www.educause.edu/hepki

HEPKI-PAG - www.educause.edu/hepki

Medical Middleware - web site to follow

Opportunities - video, the Grid, K-12

Security and Privacy Renee Woodten Frost Program Manager, Middleware Initiatives, Internet2 I2...

Documents

Transcript of Security and Privacy Renee Woodten Frost Program Manager, Middleware Initiatives, Internet2 I2...