Transcript Introduction to Federations Renee Woodten Frost Internet2 Middleware & Security/University of Michigan June 29, 2004

Introduction to Federations
Renee Woodten Frost
Internet2 Middleware & Security/University of Michigan
June 29, 2004
• Copyright Renee Woodten Frost 2004. 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.
11/6/2015
2
Topics
• Federations: The Basics
– Business drivers and the basic model
– Technical Considerations
– Policy Considerations
• Leading Edge Experiences
– Shibboleth-based federations
– InQueue
– InCommon
•
•
•
•
11/6/2015
Management
Trust/Policies
Operations
Phase One Rollout
3
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
11/6/2015
4
Business drivers for R&E
• 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 (multilateral) 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.
11/6/2015
5
Requirements for Federations
• Federation operations
• Federating software
– Exchange assertions
– Link and unlink identities
• Federation data schema
• Federation privacy and security requirements
• Non web services can also leverage
federations
11/6/2015
6
Federating Software Comparison
•Liberty Alliance
– V 1.1 of their functional specs released; 2.0 under discussion
– Federation itself is out of scope
– Open source implementations not emphasized
– Current work is linked identities
•Shibboleth
– V1.2 released; 1.3 and 2.0 under development
– Most standards-based; pure open source in widening use
– Current work is attribute release focused; linking identities in 2.0.
– Can Shibboleth and Liberty converge? SAML 2.0 is key
•WS-*
– Complex framework, consisting of 9 areas, which can form a whole cloth solution to the
problem space, but which need to closely interact with each other to do so.
– Standards process and IPR issues uncertain
– Will need considerable convention and detail to resolve into a working instantiation
– Can Shibboleth/InCommon interoperate with WS-*? Under active discussion with
Microsoft
11/6/2015
7
The Point of Privacy
Kudos for Shibboleth!
Liberty Alliance Has Missed the Point
eWeek
November 24, 2003
By Jim Rapoza
http://www.eweek.com/article2/0,4149,1396027,00.asp
What I'd like to see the group do is add more mechanisms
to make it easy for third-party developers to create tools
that give users total control over how their data is
shared. A good model for this is the Internet2 group's
Shibboleth ID management specification, which was
designed mainly for academic institutions. In Shibboleth,
users have built-in controls that give them final say over
how their data is controlled.
11/6/2015
8
Policy 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
11/6/2015
9
Unified 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; 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
11/6/2015
10
Federal Guidelines of Relevance
• NIST Guideline on Risk Assessment
Methodologies
• NIST Guideline on Authentication
Technologies and their strengths
• Federal e-Authentication
11/6/2015
11
Federated Administration
Given the strong collaborations within the academic
community, there is an urgent need to create interrealm tools, so . .
• Build consistent campus middleware infrastructure
deployments, with outward facing objectclasses,
service points, etc. and then
• Federate (multilateral) 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
11/6/2015
12
alternative fabrics where appropriate.
Federated Administration
VO
VO
O
Apps CM
O
T
CM Apps
T
Campus 1
Campus 2
T
11/6/2015
T
T
13
Federation
Other
feds
Shibboleth-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 communities14
11/6/2015
The Research and Education
Federation Space
REF
Cluster
Other
potentia
l
US
R+E
feds
InQueue
(a starting
point)
Other
clusters
Other
national nets
SWITCH
InCommo
n
NSD
L
Indiana
The
Shib
Researc
h Club
State of Penn
Fin Aid Assoc
11/6/2015
Slippery slope
- Med Centers, etc
15
InQueue
• The “holding pond”
• Is a persistent federation with “passingthrough” 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 R&E setting or not…
• Fees and service profile to be established
shortly: cost-recovery basis
11/6/2015
16
InQueue Origins 2.12.04
•Rutgers University
•University of Wisconsin
•New York University
•Georgia State University
•University of Washington
•University of California
Shibboleth Pilot
•University of Buffalo
•Dartmouth College
•Michigan State University
•Georgetown
•Duke
•The Ohio State University
•UCLA
•Internet2
11/6/2015
•Carnegie Mellon University
•National Research Council of Canada
•Columbia University
•University of Virginia
•University of California, San Diego
•Brown University
•University of Minnesota
•Penn State University
•Cal Poly Pomona
•London School of Economics
•University of North Carolina at Chapel Hill
•University of Colorado at Boulder
•UT Arlington
•UTHSC-Houston
•University of Michigan
•University of Rochester
17 Southern California
•University of
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, WebAssign, etc
• Outsourced Service Providers – purchasing
systems, dormitory management companies,
etc.
11/6/2015
18
InCommon Federation
• A permanent federation for the R&E US sector
• To be operated by Internet2, open to regionally
accredited 2- and 4- year education institutions
and business partners
• Became operational April 5, with several early
entrants to help shape the policy issues.
• Precursor federation, InQueue, has been in
operation for almost a year and will feed into
InCommon
• http://www.incommonfederation.org
11/6/2015
19
Federation Requirements - InCommon
• Federation operations – Internet2 ProductionTeam
• Federating software – Shibboleth 1.1 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
11/6/2015
20
InCommon Management
• Operational services by Internet2
– Application - Member services
– Backroom (Certificate Authority, WAYF service, etc.)
• Governance
– Executive Committee: Carrie Regenstein. Chair (Wisconsin),
Jerry Campbell (USC), Lev Gonick (CWRU), Clair Goldsmith
(Texas System), Mark Luker (EDUCAUSE), Tracy Mitrano
(Cornell), Susan Perry (Mellon), Mike Teets (OCLC), David
Yakimischak (JSTOR)
– Two Executive Committee working groups
• Policy: Tracy Mitrano, Chair
• Communications, Membership, Pricing and Packaging:
Susan Perry, Chair
– Technical Advisory Group: Scott Cantor (OSU), Steven Carmody
(Brown), Bob Morgan (Washington), Renee Shuey (PSU)
– Project manager: Renee Frost (Internet2)
• Initially an LLC and likely to take 501(c)3
status
21
11/6/2015
Trust in InCommon - Initial
• 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
• Origins and targets trust each other bilaterally in
out-of-band or no-band arrangements
– Origins trust targets dispose of attributes properly
– Targets trust origins to provide attributes accurately
– Risks and liabilities managed by end enterprises, in
11/6/2015 separate ways
22
InCommon Trust - Ongoing
• Use trust  Build trust cycle
• Clearly need consensus levels of I/A
• Multiple levels of I/A for different needs
– Two factor for high-risk
– Distinctive requirements (campus in Bejing or
France, distance ed, mobility)
• Standardized data definitions unclear
• Audits unclear
• International issues
11/6/2015
23
Balancing the Operator’s Trust Load
• InCommon Certificate Authority (CA)
– Identity proofing the enterprise
– Issuing the enterprise signing keys (primary and
spare)
– Signing the metadata
– Could be outsourced
• InCommon Federation
– Aggregating the metadata
– Supporting campuses in posting their policies
– Less easy to outsource
11/6/2015
24
InCommon Operations 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_Re
ference_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.
11/6/2015
25
InCommon CA 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_com
promise_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_Fe
deration_System_Technical_Reference_ver_0.41
– Document describing the CA.
11/6/2015
26
InCommon Key Signing Process
•
11/6/2015
2. Hardware descriptions
a. Hardware will be laptop and spare laptop with no network
capabilities, thumb drive, CDRW drive, media for necessary software
3. Software descriptions
a. OS, OpenSSL, CSP, Java tools for meta data
4. Log into computer
5. Generation of the CA Private Root key and self-signing
6. Generation of the Metadata signing key
7. Generate CSR for Internet2 origin
8. Signing of new metadata sites and trusts files
9. Backup copies of all private keys and other operational backup data
are generated.
10. Verify CD's and MD5 checksum
11. Write down passphrase and put in envelopes and sign envelopes
12. Securely store CA hardware and contents of local safe in safe
13. Log that these actions occurred on the log in safe and then close
and lock the safe
14. Put thumb drive into secure db and copy data onto secure db
15. Take private key password archive and other contents to Private
Key Password safe deposit box and record in log that this was done.
16. Take operational data archive to Operation Data safe deposit box
and record in log that this was done.
27
InCommon Operations Process Steps
• InCommon Process Technical Reviewers
–
–
–
–
Scott Cantor, OSU
Jim Jokl, University of Virginia
RL Bob Morgan, University of Washington
Jeff Schiller, MIT
• Key Signing Party
– March 30, 2004 in Ann Arbor
– Videotaped
– Witnessed
11/6/2015
28
Phase One Rollout
• Organizations from InQueue pool
– Initially 11
– Recently added 5
– Requests still coming
• Requirements
– Feedback on process and documents
– Participation in working group activities
• Targeted completion – August, 2004
11/6/2015
29
InCommon Documents (to date)
•
•
•
•
•
Membership criteria
Pricing/packaging cost recovery model
Federation Operating Rules
Participant Agreement
Participant Operational Practice Statement
(POPS)
11/6/2015
30
The Potential for InCommon
• The federation as a networked trust facilitator
• Needs to scale in two fundamental ways
– Policy underpinnings need to move to normative
levels among the members; “post and read” is a
starting place…
– Inter-federation issues need to be engineered; we
are trying to align structurally with emerging
federal recommendations
• Needs to link with PKI and with federal and
international activities
• If it does scale and grow, it could become a most
significant component of cyberinfrastructure…
11/6/2015
31
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
11/6/2015
32
For More Information
• Websites
http://middleware.internet2.edu/foo/
http:/www.incommonfederation.org
http://shibboleth.internet2.edu
Renee Woodten Frost
11/6/2015
[email protected]
33