View
221
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended