1. Internet2 Middleware & Security/University of Michigan
Federations
Renee Woodten Frost
Internet2 Middleware & Security/University of Michigan
November 17, 2004

2. Topics Federations: The Basics Shibboleth-based Federations InCommon
Management
Operations
Trust/Policies
Next Steps
12/6/2018 2

3. Federations
Associations of enterprises that come together to exchange information about their users and resources to enable collaborations and transactions
Enroll and authenticate and attribute locally, act federally.
Uses federating software (e.g. Shibboleth), common attributes (e.g. eduPerson), and a set of security and privacy understandings
Enterprises/users retain control over attributes released to resource; Resources retain control (may delegate) over authorization decisions
12/6/2018 3

4. Business Drivers for Federations
Corporate
Need to link consumer identities among disparate service providers
Link corporate employees through a company portal to outsourced employee services transparently
Allow supply chain partners to access each others internal web sites with role based controls
Research and education
Access to and sharing of digital content
The visiting scientist and eduRoam
Inter-institutional courseware
Grids and collaborative tools
12/6/2018 4

5. 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 object classes, 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.
12/6/2018 5

6. Federated AdministrationVO VO O T
Apps CM O T
CM Apps
Other
feds
Campus 1
Campus 2 T T T
Federation
12/6/2018 6

7. State of Federations Today
Buzz
Existent approaches
Corporate: internal and short-term external
R&E: persistent external collaborations (and some internal)
Government: applications and qualified Credential Providers
Possible convergence of models
Persistent public federations
Ad hoc business federations
Peering within and among using bridged approaches
12/6/2018 7

8. Requirements for Federations
Federation operations
Federating software
Exchange assertions
Link and unlink identities
Federation data schema
Federation privacy and security requirements
12/6/2018 8

9. Federations and PKI
The rough differences are payload format (SAML vs X.509) and typical length of validity of assertion (real-time vs long-term)
Federations use enterprise-oriented PKI heavily and make end-user PKI both more attractive and more tractable.
The analytic framework (evaluation methodologies for risk in applications and strength of credentials) developed for PKI is useful for federations.
The same entity can offer both federation and PKI services
PKI-oriented infrastructure (e.g. Federal Bridge CA) can be leveraged in support of federations
12/6/2018 9

10. 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
12/6/2018 10

11. Federal Guidelines of Relevance
NIST Guideline on Risk Assessment Methodologies
NIST Guideline on Authentication Technologies and their strengths
Federal e-Authentication
12/6/2018 11

12. US Shibboleth Federations
InQueue
InCommon
Uses
Management
Policies
Shared schema
Club Shib
National Science Digital Library (NSDL)
State, system, and campus federations
Texas, Ohio State, etc…
12/6/2018 12

13. 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
12/6/2018 13

14. InQueue The “holding pond”
Is a persistent federation with “passing-through” membership…
Operational today. Can apply for membership via
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
12/6/2018 14

15. 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
12/6/2018 15

16. InCommon Federation Federation operations – Internet2
Federating software – Shibboleth 1.1 and above
Federation data schema - eduPerson or later and eduOrg or later
Became fully operational mid-September, with several early entrants already in to help shape the policy issues.
Precursor federation, InQueue, in operation for almost a year and will feed into InCommon; approximately 150 members
12/6/2018 16

17. InCommon Principles
Support the R&E community in inter-institutional collaborations
InCommon itself operates at a high level of security and trustworthiness
InCommon requires its participants to post their relevant operational procedures on identity management, privacy, etc
InCommon will be constructive and help its participants move to higher levels of assurance as applications warrant
InCommon will work closely with other national and international federations
12/6/2018 17

18. InCommon Uses
Institutional users acquiring content from popular providers (Napster) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.)
Institutions working with outsourced service providers, e.g. grading services, scheduling systems, LMS (WebAssign, Blackboard, etc.)
Inter-institutional collaborations, including shared courses and students, research computing sharing, etc.
12/6/2018 18

19. InCommon Management
Legal - initially LLC, likely to take 501(c)3 status
Governance
Steering Committee: Carrie Regenstein, chair (Wisconsin), Jerry Campbell (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Ken Klingenstein (I2), Mark Luker (EDUCAUSE), Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teets (OCLC), David Yakimischak (JSTOR)
Two Steering Committee advisory groups
Policy: Tracy Mitrano, Chair
Communications, Membership, Pricing, Packaging:
Susan Perry, Chair
Technical Advisory Group: Scott Cantor (OSU), Steven Carmody (Brown), Bob Morgan (UWash), Renee Shuey (PSU)
Project manager: Renee Woodten Frost (Internet2)
12/6/2018 19

20. InCommon Operations Operational services by Internet2
Storefront (process maps, application process)
Backroom (CA, WAYF service, etc.)
Federation Operating Practices and Procedures (FOPP)
InCommon Process Technical Advisory
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 and witnessed
12/6/2018 20

21. InCommon Participants
Two types of participants:
Higher ed institutions: 2- and 4-year accredited
Resource providers: partners sponsored by higher ed institutions, e.g. content providers, outsourced service providers (WebAssign, Roomschedulers, etc)
Participants can function in roles of credential/identity providers and resource/service providers
Higher ed institutions are primarily credential providers, with the potential for multiple service providers on campus
Resource providers are primarily offering a limited number of services, but can serve as credential providers for some of their employees as well
12/6/2018 21

22. InCommon Pricing Goals Prices Cost recovery
Manage federation “stress points”
Prices
Application Fee: $700 (largely enterprise I/A, db)
Annual Fee
Higher Ed participant: $1000 per identity management system
Sponsored participant: $1000
All participants: 20 ResourceProviderIds included; additional ResourceProviderIds available at $50 each per year, available in bundles of 20
12/6/2018 22

23. Trust in InCommon - Initial
Use trust  Build trust cycle
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 + liabilities managed by end enterprises, in separate ways
12/6/2018 23

24. Balancing the Operator’s Trust Load
InCommon Certificate Authority (CA)
Identity proofing the enterprise
Issuing the enterprise signing keys (primary + spare)
Signing the metadata
Could be outsourced
InCommon Federation
Aggregating the metadata
Supporting campuses in posting their policies
Less easy to outsource
12/6/2018 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.
12/6/2018 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.
12/6/2018 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.
12/6/2018 27

28. Participant Agreement Highlights
Agree to post policies
Security
Basic identity management
Privacy
Inform InCommon on a timely basis of key compromise
Be prudent about and responsible for ResourceProviderIds issued
Be responsible for adhering to their POP statement
12/6/2018 28

29. Participant Operational Practice (POP) Statement
Basic Campus identity management practices in a short, structured presentation
Identity proofing, credential delivery and repeated authentication
Provisioning of enterprise-wide attributes, including entitlements and privileges
Basic privacy management policies
Standard privacy plus
Received attribute management and disposal
12/6/2018 29

30. Trust Pivot Points in Federations
In response to real business drivers and feasible technologies, increase the strengths of:
Campus/enterprise identification, authentication practices
Federation operations, auditing thereof
Campus middleware infrastructure in support of Shib (including directories, attribute authorities and other Shib components) and auditing thereof
Relying party middleware infrastructure in support of Shib
Moving in general from self-certification to external certification
12/6/2018 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…
12/6/2018 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
12/6/2018 32

33. Next Steps Applications
Some leverage federations
Some ignore inter-institutional uses
Content providers increasingly aware; outsource providers learning
Open-source development community is challenge
Commercial and value-added versions of Shibboleth
Federal E-Authentication
Move towards standard levels of assurance
Possible applications: Ed loans, Fastlane
Federation interactions/peering: inter-fed, union of feds
12/6/2018 33