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

2. Copyright Renee Woodten Frost 2004
Copyright Renee Woodten Frost 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.
4/23/2019 2

3. Topics Federations: The Basics Leading Edge Experiences
Business drivers and the basic model
Technical Considerations
Policy Considerations
Leading Edge Experiences
Shibboleth-based federations
InQueue
InCommon
Management
Trust/Policies
Operations
Phase One Rollout
Shibboleth and InCommon
International federations and inter-federation issues
4/23/2019 3

4. 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
4/23/2019 4

5. 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.
4/23/2019 5

6. 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
4/23/2019 6

7. 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
4/23/2019 7

8. The Point of Privacy Kudos for Shibboleth!
Liberty Alliance Has Missed the Point eWeek November 24, By  Jim Rapoza 
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.
4/23/2019 8

9. 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
4/23/2019 9

10. 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
4/23/2019 10

11. Federal Guidelines of Relevance
NIST Guideline on Risk Assessment Methodologies
NIST Guideline on Authentication
Technologies and their strengths
Federal e-Authentication
4/23/2019 11

12. Federated Administration
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.
4/23/2019 12

13. Federated AdministrationVO VO O T
Apps CM O T
CM Apps
Other
feds
Campus 1
Campus 2 T T T
Federation
4/23/2019 13

14. 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 communities
4/23/2019 14

15. The Research and Education Federation Space
REF
Cluster
InQueue
(a starting point)
InCommon
SWITCH
The Shib
Research Club
Other national nets
Other clusters
Other
potential US
R+E feds
State of Penn
Fin Aid Assoc
NSDL
Indiana
Slippery slope
- Med Centers, etc
4/23/2019 15

16. InQueue The “holding pond”
Is a persistent federation with “passing-through” membership…
Operational today. Can apply for membership via 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
4/23/2019 16

17. InQueue Origins 2.12.04 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
University of Southern California
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
Carnegie Mellon University
4/23/2019 17

18. 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.
4/23/2019 18

19. 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
4/23/2019 19

20. Federation Requirements - InCommon
Federation operations – Internet2 ProductionTeam
Federating software – Shibboleth 1.1 and above
Federation data schema - eduPerson or later and eduOrg 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
4/23/2019 20

21. InCommon Management Operational services by Internet2 Governance
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
4/23/2019 21

22. 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 separate ways
4/23/2019 22

23. 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
4/23/2019 23

24. 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
4/23/2019 24

25. 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_Reference_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.
4/23/2019 25

26. 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_compromise_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_Federation_System_Technical_Reference_ver_0.41
Document describing the CA.
4/23/2019 26

27. InCommon Key Signing Process
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 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 Take operational data archive to Operation Data safe deposit box and record in log that this was done.
4/23/2019 27

28. 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
4/23/2019 28

29. Phase One Rollout Organizations from InQueue pool Requirements
Initially 11
Recently added 5
Requests still coming
Requirements
Feedback on process and documents
Participation in working group activities
Targeted completion – August, 2004
4/23/2019 29

30. InCommon Documents (to date)
Membership criteria
Pricing/packaging cost recovery model
Federation Operating Rules
Participant Agreement
Participant Operational Practice Statement (POPS)
4/23/2019 30

31. 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…
4/23/2019 31

32. 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
4/23/2019 32

33. For More Information Websites http://middleware.internet2.edu/foo/
Renee Woodten Frost
4/23/2019 33