1. Federations: success brings new challenges Ken Klingenstein Director, Internet2 Middleware and Security

2. Topics Federations – the basics Current status of federations The new challenges Peering and confederation Coordinating with the big players End-users Leveraging federations for Trust, attributes, roles, security Virtual organization (VO) support

3. Federation basics Purpose An overview of core middleware Federation policies Federating technologies Federated applications

4. Federation purpose To provide a general-purpose trust fabric for collaboration among the members Identity providers (IdP) issue assertions and provide attributes about users to service providers (SP), who make authentication and authorization decisions. In use in the R&E community, government agencies, market sectors Can have multiple levels of trust, many applications in use, peering among federations, etc.

5. A Map of Middleware Land

6. Components of Core Middleware

7. Federations Concept

8. The Art of Federating

9. Federations Persistent enterprise-centric general-purpose trust facilitators Sector-based, nationally-oriented Federated operator handles enterprise I/A, management of centralized metadata operations Members of federation use common software to exchange assertions bi-laterally using a federated set of attributes; members of federation determine what to trust and for what purposes on an application level basis Steering group sets policy and operational direction Note the “discovery” of widespread internal federations and the bloom of local and ad-hoc federations

10. Federation Fundamentals Members sign a contract to join. Members must still create Business Relationships with each other Bilateral relationships can impose additional policy The Federation does NOT Collect or assert anything, except the necessary metadata about member signing keys, etc. Authenticate end users Provide services, though it may be associated with groups or buying clubs

11. SAML on the wire Security Access Markup Language – an OASIS standard SAML 1.1 widely embedded in commercial products SAML 2.0 ratified by OASIS last year Combines much of the intellectual contributions of the Liberty Alliance with materials from the Shibboleth community – a fusion product Scott Cantor of Ohio State was the technical editor Adds some interesting new capabilities, eg. privacy- preservation, actively linked identities Possibly a plateau product

12. Application integration Access to online content, from scholarly to popular Access to digital repositories and federated search Submissions of materials, from grant proposals to tests and exams Non web applications – p2p file sharing, Grids, etc. – are beginning to leverage federated identity

13. Federation policies Typically a contract for a member to join a federation Federation operational practices statement can help members decide whether to join Contract addresses mutual responsibilities and ways to address conflicts among members or between a member and the federated operator Operational standards for members Identity management practices Technical participation in the federation

14. Research and Education Federations Growing national federations UK, France, Germany, Switzerland, Australia, Netherlands, Norway, Spain, Denmark, etc. Stages range from fully established to in development; scope ranges from higher ed to further education Many are Shib-based; all speak SAML on the outside… Several million users and growing First goals are content access; additional goals include bandwidth allocation, network monitoring, security, etc.

15. Notable R&E Federations SWITCH – Swiss AAI Comprehensive; well-implemented Virtual organization home SURFnet Extensive; good ties to national government Addresses end-user authentication as well UK Rapid growth and development UKERNA to operate under JISC contract

16. US Federations InCommon (InQueue) State-based Texas, UCOP, Maryland, etc. For library use, for roaming access, for payroll and benefits, etc. US Gov Federal eAuthentication Initiative

17. InCommon US R&E Federation www.incommonfederation.org Members join a 501(c)3 Addresses legal, LOA, shared attributes, business proposition, etc issues Approximately 30 members and growing A low percentage of national Shib use…

18. InCommon Management/Governance Steering Committee of campus/vendor CIO’s and policy people – sets policies for membership, business model, etc. Technical advisory committee - Sets common member standards for attributes (eduPerson 2.0), identity management good practices, etc.

19. InCommon Membership Case Western Reserve University Cornell University Dartmouth Elsevier ScienceDirect Georgetown University Houston Academy of Medicine - Texas Medical Center Library Internet2 Napster, LLC OCLC Ohio University OhioLink - The Ohio Library & Information NetworkCase Western Reserve University Cornell University Dartmouth Elsevier ScienceDirect Georgetown University Houston Academy of Medicine - Texas Medical Center Library Internet2 Napster, LLC OCLC Ohio University OhioLink - The Ohio Library & Information Network Penn State SUNY Buffalo The Ohio State University The University of Chicago University of Alabama at Birmingham University of California, Irvine University of California, Los Angeles University of California, Office of the President University of California, San Diego University of Rochester University of Southern California University of Virginia University of Washington WebAssignPenn State SUNY Buffalo The Ohio State University The University of Chicago University of Alabama at Birmingham University of California, Irvine University of California, Los Angeles University of California, Office of the President University of California, San Diego University of Rochester University of Southern California University of Virginia University of Washington WebAssign

20. Challenges in the US Addressing the risks in federated identity Too many lawyers Too few business drivers No bulk content licensing Few “national” applications No government access yet Number of “big dog” institutions For many institutions, the focus is in state versus national for applications Bi-lateral relationships exist more than national relationships Single-purpose federations can leverage existing contracts. Relatively few institutions really have their identity management technologies fully in place Very few have their identity management policies in place.

21. Key questions in federations It doesn’t seem to be about the technology or model anymore SAML 2.0 in most IdM vendor’s blueprints (except MS); some will ship with Shib profiles embedded It is about whether the core IdM systems are open or proprietary with open API’s. What is the integration with other trust fabrics (e.g. eduRoam.us, PKI hierarchy, state and local federations) Can federations happen in the US, or will we be bi-lateral hell?

22. The new Challenges Peering and confederation Coordinating with the big players End-users InfoCard Leveraging federations for Trust, attributes, roles, security Virtual organization (VO) support

23. Inter-federation key issues Peering, peering, peering At what size of the globe? Confederation Tightly coupled autonomous federations How do vertical sectors relate? How to relate to a government federation? On what policy issues to peer and how? Legal framework Treaties? Indemnification? Adjudication How to technically implement Wide variety of scale issues WAYF functionality Virtual organization support

24. In the US… InCommon –US Gov Fed alignment Promote interop for widespread higher-ed access to USG applications grants process, research support, student loans... Static peering Of InCommon Bronze and EAuth InCommon Bronze is a subset of InCommon, with a defined set of Identity procedures and federation operations Definition of peering – attribute mappings, LOA, legal alignment, etc. Draft SAML 2.0 eAuthentication Profile Draft USPerson

25. InCommon vs. InCommon Bronze Process of forming InCommon Bronze just starting, with a five-month window Bronze members likely a small subset of InCommon members; common management infrastructure Differences may include: Password management and identity proofing for some users; most users may still be lower level Liability and indemnification Explicit operational responsibilities for members and federated operator (signing key revocation, etc) Internal audits once a year of IdM practices

26. Some gaps in risk assessment Enterprise behavior to protect signing key, etc. (to not dilute trust), notify of revocation, etc Federated operator to properly I/A members, protect metadata signing keys, etc. Cross-federation risk management

27. International Peering Ducking the issue for now with ad hoc coordination (e.g. shib-enable-vendor) Refeds@terena.nl for some interesting discussionsRefeds@terena.nl eduGAIN as a possible technology component for dynamic peering Key use cases (Grids and other VO’s) yet to surface) UN interest

28. Coordinating with big players Content providers heavily federation oriented Almost all major academic content providers now support Shibboleth and federated identity Important issues include Presenting selection of federations and IdP’s to users Simple approach to common attributes and release policies Business model implications MS using federations to distribute student software

29. End-users MAMS project from Australia has developed institutional privacy managers (ShARPE) and personal privacy manager (ala Autograph) Possible integration of federated identity and attributes in the personal identity features called InfoCard in MS Vista next year Can users manage identity and privacy?

30. Virtual organizations and federations One major driver for federations is their ability to support effective and scalable AAI for virtual organizations. Numerous GridShib projects exist, perhaps too many… Can a set of peering federations be in place to support federated Grid implementations and what are the transition strategies? Support the metadata exchange and consistency

31. GridShib A set of approaches seeking to leverage the strengths of federated identity and privilege management with science Grids Projects in 6-8 different countries, addressing different stress points in grids today. Some are kludge layered on kludge; some are steps in a long-term set of strategies

32. Overall strategy Provide a coherent experience to the user, integrating their primary employer IdM with their research science needs for authentication and privilege management Build an operational trust/attribute layer of federations of enterprises to support clusters of virtual organizations. Based on Shibboleth and Signet/Grouper and Globus, etc.

33. Leveraging federations Using the federation to Standardize institutional attributes and roles Pass other shared metadata (licenses, security information, etc) Negotiate bulk contracts or act as a buyer’s club Define privacy preservation approaches How much can a federation commit on behalf of its members? How does international peering agreements bind federation members?

34. Leveraging Uses of Federations Security incident exchange and diagnosis Federated network access and eduroam Trust mediated transparency DKIM for spam control, etc DNSSec discovery