Protecting Privacy; Gaining AccessProtecting Privacy; Gaining Access

Renee Woodten FrostCheryl Munn-FremonRenee Woodten FrostCheryl Munn-Fremon

2

• Copyright Renee Woodten Frost and Cheryl Munn-Fremon, 2005. This work is the intellectual property of the authors. 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 authors. To disseminate otherwise or to republish requires written permission from the authors.

3

Internet2 Mission and GoalsInternet2 Mission and Goals

Internet2 Mission• Develop and deploy advanced network

applications and technologies, accelerating the creation of tomorrow’s Internet.

Internet2 Goals• Enable new generation of applications• Re-create leading edge R&E network

capability• Transfer technology and experience to the

global production Internet

4

Internet2 TodayInternet2 Today

Motivate Enable

End-to-end

End-to-end

Perform

anceP

erformanceNetworksNetworks

MiddlewareMiddleware

ApplicationsApplications

ServicesServices

Securit

Securit

yy

5

Topics for TodayTopics for Today

• Why Important• Federations • InCommon• For more information

6

Addressing Four ScenariosAddressing 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 situation can be solved in a variety of straightforward ways. • Taken together, they present the challenge of meeting users’ reasonable expectations for protection of personal privacy.

7

What We’re All Trying to AccomplishWhat We’re All Trying to Accomplish

• Simplify end user access to multitude of online services

• Facilitate operation of those services by IT organizations

• Increase security

• Preserve individual privacy

• Enable online service for our constituents earlier in their affiliation with us, wherever they are, and ongoing

• Participate in new, inter-organizational, collaborative architectures and environments

8

How We Can Facilitate ItHow We Can Facilitate It

Identity and Access Management: provides an enterprise-wide, policy-driven middleware infrastructure that enables:• Scalability • Consistency• Integrity• Integration• Collaboration

9

Identity Management (IdM) Identity Management (IdM)

• Set of standards, policies, procedures, and technologies that provide electronic credentials to individuals and maintain authoritative information about the holders of those credentials . . and assist in determining and granting access . .

• aka “Identity and Access Management”

10

IdM Infrastructure DefinitionsIdM Infrastructure Definitions

Identityset of attributes about, and identifiers referring to, a subject (person, service…)

Authenticationprocess used to associate a subject with an identifier

Authorizationprocess of determining if policy permits an intended action to proceed

Credentialsattributes about a subject used to identify (authentication) or make access decisions (authorization) about what it can do in a particular context

11

Higher Ed Need for Federated Administration Higher Ed Need for Federated Administration

Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so . .• Build consistent campus and enterprise middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then• Federate those enterprise deployments, using the outward facing campus infrastructure, 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, and then, going forward• Create tools and templates that support the management and collaboration of virtual organizations by building on the federated campus infrastructures.

12

Federated Identity ManagementFederated Identity Management

Relying on the Identity Management infrastructure of one or more institutions or units . .

to authenticate and pass authorization-related information to service providers or resource-hosting institutions or enterprises . .

via institution-provider agreements . .

facilitated by common membership in a federation (like InCommon)

13

What are Federations?What are 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

14

What is Shibboleth?(federating software)What is Shibboleth?(federating software)

• An initiative to develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services

• A framework built on a “Federated” model

• A project delivering an open source implementation of the architecture and framework

• Deliverables:• Software for identity providers = campuses (origins)• Software for resource providers (targets)• Operational Federations (scalable trust)

15

What is Shibboleth? (Biblical)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)

16

Shibboleth GoalsShibboleth 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• Using Attribute-based Access Control

• Foster inter-realm trust fabrics: federations and virtual organizations

• Leverage campus expertise and build rough consensus• Influence the marketplace; develop where necessary• Support heterogeneity and open standards

17

Attribute-based AuthorizationAttribute-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 resource provider 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.

18

Typical Attributes in the Higher Ed CommunityTypical Attributes in the Higher Ed Community

Affiliation “active member of community”

member@washington.edu

EPPN

(eduPersonPrincipalName)

Identity gettes@duke.edu

Entitlement An agreed upon opaque URI

urn:mace:vendor:contract1234

OrgUnit Department Economics Department

EnrolledCourse Opaque course identifier

urn:mace:osu.edu:Physics201

19

Shibboleth Architecture Shibboleth Architecture

20

Current Status: Shibboleth v. 1.2.1Current Status: Shibboleth v. 1.2.1

• Open-source, standards-based, privacy-preserving federating software

• Accelerating deployment globally: InCommon, NSDL, SWITCH, Finland, Netherlands, United Kingdom (three), Australia, InQueue, League of Federations

• Commercial information providers in production: Elsevier Science Direct, OCLC, etc.

• Working on underlying Attribute Authority GUI and resource protection

• Growing international development interest providing resource manager tools, email list software, etc.

21

Why Shibboleth?Improved Access ControlWhy Shibboleth?Improved Access Control

• Use of attributes allows fine-grained access control• Med School Faculty get access to additional resources• Specific group of students have access to restricted

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

22

Why Shibboleth?Federated AdministrationWhy Shibboleth?Federated Administration

• Flexibly partitions responsibility, policy, technology, and trust

• Leverages existing middleware infrastructure at origin - authentication, directory• Users registered only at their “home” or “origin”

institution• Resource Provider does NOT need to create new

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

23

Why Shibboleth?PrivacyWhy 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

• HIPAA requires privacy in medical records handling

• General interest and concern for privacy is growing

• Shibboleth has active (vs. passive) privacy provisions “built in”

24

Policy Basics for FederationsPolicy Basics for Federations

• Enterprises that participate need to establish a trusted relationship with the operator of the federation; in small or bilateral federations, often one of the participants operates the federation

• Participants need to establish trust with each other on a per use or per application basis, balancing risk with the level of trust

• Participants need to agree on the syntax and semantics of the information to be shared

• Privacy issues must be addressed at several layers• All this needs to be done on scalable basis, as number of

participants grow and number of federations grow

25

Unified Field Theory of TrustUnified Field Theory of Trust

• Bridged, global hierarchies of identification-oriented, often government-based trust: laws, identity tokens, etc.• Passports, drivers licenses • Future is typically PKI oriented

• Federated enterprise-based trust: leverages one’s security domain; often role-based• Enterprise does authentication and attributes• Federations of enterprises exchange assertions (identity & attributes)

• Peer-to-peer trust: ad hoc, small locus personal trust• A large part of our non-networked lives• New technology approaches to bring this into the electronic world.• Distinguishing P2P apps architecture from P2P trust

• Virtual organizations cross-stitch across one of the above

26

Shibboleth-based FederationsShibboleth-based Federations

• InQueue• InCommon• Club Shib• Swiss Education and Research Network

(SWITCH)• National Science Digital Library (NSDL)------------------------------------• State networks• Medical networks• Financial aid networks• Life-long learning communities

27

The Research and EducationFederation SpaceThe Research and EducationFederation Space

REFCluster

InQueue(a starting point)

InCommon

SWITCH

The ShibResearh Club

Other national nets

Other clusters

Other potential USR+E feds

State of Penn Fin Aid Assoc

NDSL

Slippery slope- Med Centers, etc

Indiana

28

InQueue 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; approximately 150 participants

• 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

29

Federation Federation

• A permanent federation for the R&E US sector• Federation operations – Internet2• Federating software – Shibboleth 1.2 and above • Federation data schema - eduPerson200210 or later

and eduOrg200210 or later • Federated approach to security & privacy with posted

policies• Became fully operational September 2004, with several

early entrants shaping the policy & process issues.• http://www.incommonfederation.org

30

Principles Principles

• Support the R&E community in inter-institutional collaborations

• InCommon itself operates at a strong level of security and trustworthiness

• InCommon requires its participants to post their relevant operational procedures on identity management, privacy, etc

• InCommon will work closely with other national and international federations

31

Trust Trust

• 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

• Identity Providers and Resource Providers trust each other bilaterally in out-of-band or no-band arrangements• Risks and liabilities managed by end enterprises,

in separate ways

32

So where did we begin?So where did we begin?

• InQueue• Virtual Production Team

• Middleware project manager• Finance• Membership• Communications and Branding• Technical Support Group• Legal/Organizational • VPT Director

• Began Deployment Plan• Established a preliminary budget and business model

33

Morphing into a Deployment TeamMorphing into a Deployment Team

• Middleware Project Leader• VPT Director• Technical Services team• Documentation specialist• Developer representative• Legal coordinator• And after we were far down the road• Deployment Project Manager

34

Operational Staffing todayOperational Staffing today

• Operations Manager

• Documentation/Communication specialist

• Registrar/Administrative Assistant

• A/R support

• Technical Services Team

• Middleware Project Manager

35

LLC Management LLC Management

• Governance • Steering Committee: Carrie Regenstein, Chair (Wisconsin)• Two Steering Committee working groups

• Policy • Communication, Membership, Pricing/Packaging

• Technical Advisory Group

• Operations – Internet2• InCommon Certificate Authority

• Issuing the enterprise certificate signing keys

• Metadata and Certificate submission• Hosting the WAYF (where are you from)• Supporting Campuses in posting their policies• Store front (process maps, application process, billing, registry

authority

36

Where the real work beganWhere the real work began

• Developing the documents

• Getting all the stakeholders to agree to the policies and practices

• Defining the rules and processes for who could join

• Determining the rigor of the identification process

• Developing pricing/packaging plan

37

Documents (to date) Documents (to date)

• LLC• Membership criteria• Pricing/packaging cost recovery model • Federation Operating Practices and Procedures

(FOPP) and Technical Operations Docs• Participant Agreement (PA)• Participant Operational Practices (POP)

38

Operations DocsOperations Docs

• InCommon_Federation_Disaster_Recovery_Procedures_ver_0.1 • An outline of the procedures to be used if there is a disaster

with the InCommon Federation. • Internet2_InCommon_Federation_Infrastructure_Technical_Refer

ence_ver_0.2 • Document describing the federation infrastructure.

• Internet2_InCommon_secure_physical_storage_ver_0.2 • List of the physical objects and logs that will be securely

stored. • Internet2_InCommon_Technical_Operations_steps_ver_0.35

• This document lists the steps taken from the point of submitting CSR, Metadata, and CRL to issuing a signed cert, generation of signed metadata, and publishing the CRL.

• Internet2_InCommon_Technical_Operation_Hours_ver_0.12 • Documentation of the proposed hours of operations.

39

CA Operations DocsCA Operations Docs

• CA_Disaster_Recovery_Procedure_ver_0.14 • An outline of the procedures to be used if there is a disaster with the

CA. • cspguide

• Manual of the CA software planning to use. • InCommon_CA_Audit_Log_ver_0.31

• Proposed details for logging related to the CA. • Internet2_InCommon_CA_Disaster_Recovery_from_root_key_comprom

ise_ver_0.2 • An outline of the procedures to be used if there is a root key

compromise with the CA. • Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61

• Draft of the PKI-Lite CPS. • Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21

• Draft of the PKI-Lite CP. • Internet2_InCommon_Certificate_Authority_for_the_InCommon_Federat

ion_System_Technical_Reference_ver_0.41 • Document describing the CA.

40

Participants Participants

• Two types of participants:• Higher ed institutions - .edu-ish requirements• Resource providers – commercial partners sponsored by

higher ed institutions, e.g. content providers, outsourced service providers, etc

• Participants can function in roles of identity providers and/or resource providers• Higher ed institutions are primarily identity (credential)

providers, with the potential for multiple service providers on campus

• Resource (service) providers are primarily offering a limited number of services, but can serve as credential providers for their employees as well

41

Pricing Pricing

• Goals• Cost recovery• Manage federation “stress points”

• Prices• Application Fee: $700 (largely enterprise I/A,

db)• Yearly Fee

• Sponsored participant: $1000• Higher Ed participant: $1000 per identity

management system• All participants: 20 ResourceProviderIds included;

additional ResourceProviderIds available at $50 each per year, available in bundles of 20

42

So you want to joinSo you want to join

• Review federation documents• Evaluate risks• Complete the web application form and

identify:• Executive Liaison• InCommon Administrative Contact• Billing Contact

• Pay $700 application fee by credit card

http://www.incommonfederation.org/

43

Participant Risk AssessmentParticipant Risk Assessment

• Areas of possible risk• Misrepresentation by a participant

organization• Incorrect or corrupted metadata• Incorrect public key for Participant• Mis-configuration or malfunction of the

InCommon WAYF• Failure to notify Participants of changes in

FOPP or POPs

44

Identity Verification Process by Internet2Identity Verification Process by Internet2

• Review the application and request any additional information

• Verify organization is a U.S, 2- or 4-year institution of higher education

• Verify individual’s identification• Phone number in public directory• Direct contact with executive liaison

• Send out Participation Agreement for signature

• Prepare Invoice

45

Participant Next StepsParticipant Next Steps

• Sign Participation Agreement and return paper copies to InCommon

• Pay $1000 annual fee• Administrative contact will receive

unique ID and password.• Receive certificate (s) from InCommon• Post your Participant Operational

Practices (POP) and provide URL to InCommon

46

Participation AgreementParticipation Agreement

• Participant Responsibilities• Employ an implementation of Shibboleth or

equivalent• Use Identity Attributes as described on

website• Install any software that may be required by

the Federation• Provide InCommon with accurate metadata• Terms of any agreement between participants

shall be agreed to by and among such participants

47

Participation Agreement cont’d.Participation Agreement cont’d.

• Participant Responsibilities cont’d.• Provide technical and administrative contact

information• Bear its own costs and expenses• Participate in a manner that does not violate

Federal, state or local laws or that interferes with others

• Make available reliable and trustworthy information about its identity management system

48

Participant Operational PracticesParticipant Operational Practices

• Provide authoritative and accurate attribute assertions

• Attributes are protected and privacy respected

• Provide basic information about identity management system

• A series of questions for Participants• Participant information• Electronic Identity Database information• Attribute Assertions• Privacy Policy

49

Trustworthy Attribute Assertions RequirementsTrustworthy Attribute Assertions Requirements

• ID management system is under the purview of the executive or business management

• System for issuing end-user credentials has in place appropriate risk management measures• Authentication standards• Security practices• Audit trails• Etc.

50

, Some Time From Now , 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 Federal Government• “Peering” with national federations in other

countries• “Gateways” with commercial federations

51

For More InformationFor More Information

• Websites

http://middleware.internet2.edu

http://shibboleth.internet2.edu

http:/www.incommonfederation.org

Renee Woodten Frost rwfrost@internet2.edu

Cheryl Munn-Fremon

cmfremon@internet2.edu

52