1. Federated Security and the Federal Government Ken Klingenstein Director, Internet2 Middleware and Security

2. Topics  What and why federated AAI Federate what?  The basic ingredients Shibboleth and SAML GridShib and WS-Fed Federations, international deployments and InCommon, a US R&E federation… Federated identity and the network control plane: security, allocation, etc. Federated identity and virtual organizations  Work with the US government The Federal e-Authentication Initiative Phase 1/2 – Certifying Shib, Shaping Policy Issues, etc Phase 3/4 – SAML 2.0 Profile, USperson deliverables, interfederation peering  What is easy / What is hard  What does it mean to Magic

3. Authentication and Authorization Infrastructure  Authentication – provides positive proof, at several possible strengths, of identity  Authorization – assign permissions to use resources, from web sites to supercomputer access, digital content to parking spaces  Infrastructure means: A reliable, robust, ubiquitous, service Initially to the R&E community but with applicability to other vertical sectors National in character, but of service to multi-national virtual organizations Built on either central, hierarchical or federated, enterprise models

4. Key Issues for AAI  In authentication, the key issues are strength of authentication (identity proofing, delivery of credential, repeated use of credential) and privacy/secrecy  In authorization, the key issues are permissions to use resources, delegation, audit and privacy  In infrastructure, the issues are making it real, ubiquity, robustness, ability to support a wide range of needs and uses, and funding

5. Federated model  Enterprises and organizations provide local LOA, namespace, credentials, etc.  Uses a variety of end-entity local authentication – PKI, username/password, Kerberos, two-factor, etc.  Enterprises within a vertical sector federate to coordinate LOA’s, namespaces, metadata, etc.  Internal federations within large complex corporations have been “discovered”.  Privacy/security defined in the context of an enterprise or identity service provider

6. A federation of what?  A key issue for MAGIC  The NMI-I2 work is a federation of enterprises Within a market sector (R&E, Federal agencies, etc.) With a national context (security regulations, privacy laws, pride, etc.)  Others talk of other entities federating Virtual organizations or Grid PMA’s Applications running at multiple sites –A federation of courses, data sets, etc… A federation of individuals

7. Why does it matter  Regulation Strength of identity proofing and LOA Audit and compliance capabilities  Ease of use  Where the users live and travel  Use cases that are enterprise centric  Scale  Industry trends

8. Federating Software  Shibboleth – an open source privacy preserving standards-based system  Liberty Alliance – large commercial standards group in federated identity management  Liberty and Shib have essentially converged around SAML 2.0, with Liberty Alliance moving into services and Shib being refactored and expanded  WS-* - MS (with IBM) “standards” that is slowly emerging, with some interoperability with SAML and Shib

9. Shibboleth  An architecture, consisting of both a payload definition (using SAML) of attributes and a set of privacy-preserving methods of exchanging such payloads.  A project that has managed the development of the architecture and code  A code package, running on a variety of systems, that implements the architecture.  (Note that other code sets are under development)

10. Shibboleth v1.3  Planned Availability -- July, 2005 Currently in beta  Major New Functionality Full SAML v1.1 support -- BrowserArtifact Profile and AttributePush Support for SAML-2 metadata schema Improved Multi-Federation Support Support for the Federal Gov’t’s E-authn Profile Native Java SP Implementation Improved build process

11. WS* Interop -- Status  Agreements to build WS-Fed interoperability into Shib Contracts signed; work to begin AFTER Shib v1.3 WS-Federation + Passive Requestor Profile + Passive Requestor Interoperability Profile  Discussions broached, by Microsoft, in building Shib interoperabilty into WS-Fed; no further discussions  Devils in the details Can WS-Fed-based SPs work in InCommon without having to muck up federation metadata with WS-Fed-specifics? All the stuff besides WS-Fed in the WS-* stack

12. What is GridShib?  NSF Middleware Initiative (NMI) Grant: “Policy Controlled Attribute Framework”  Allow the use of Shibboleth-transported attributes for authorization in NMI Grids built on the Globus Toolkit v4  2 year project started December 1, 2004  Participants Von Welch, UIUC/NCSA (PI) Kate Keahey, UChicago/Argonne (PI) Frank Siebenlist, Argonne Tom Barton, UChicago

13. Why?  Attribute-based authorization has shown itself to be useful in large grids with far-flung participants in several types of roles Identity-based approach scales poorly  Shibboleth is well supported and becoming widely deployed  SAML is used by larger identity federation world, not just Shibboleth. Integrating SAML support into Grids opens the door to leveraging this large technology space

14. GridShib Integration Principles  No modification to typical grid client applications Modifications only to Grid Services and security clients (e.g. grid- proxy-init)  Leverage shibboleth’s attribute marshaling capability and release policies  Leverage strategic investment that campuses make in Identity Management operations

15. GridShib Progress  Developers hired February 2005  Substantial resolution of GridShib’s Shibboleth usage profile  Shibboleth IdP plugin nearing completion Maps externally-issued X.509 identity certificates to local identifiers  SAML attribute marshaling in GT4 runtime nearing completion  Common attribute format internal to GT4 runtime to support access policies spanning SAML and X.509 PMI attribute sources Uses XACML Request Context  Initial GridShib release for closed alpha deployment Readiness by end of June Overlays GT 4.0 and Shib 1.3

16. Potential Early Adopters  Focused efforts to understand and evaluate potential use of GridShib in: caBIG, Cancer Bioinformatics Grid UK eScience Grid LOOKING, Laboratory for the Ocean Observatory Knowledge Integration Grid University of Southern California University of Alabama at Birmingham SURAgrid

17. Distributed Authorities Grid Service Session authentication credential Attribute Authority Home Org Virtual Org Affiliated Org Authorities Grid user Signet, Grouper

18. Project objectives  Priority 1: Pull mode operation Globus services contact Shibboleth to obtain attributes about identified user Support both GT4.x Web Services and pre-WS code  Priority 2: Push mode operation User obtains Shib attributes and push to service Allows role selection  Priority 3: Online CAs Pseudonymous operation Integration with local authentication services

19. Timeline  December 1, 2004: formal start  February 1, 2005: Developers on board and coding  Mid-Summer 2005: closed alpha release pull model with user identified  Fall 2005: public releases Production pull model with user identified Beta push model with user identified Implementation of simple policy description language Targeting GT 4.1.x and Shibboleth 1.3  2006: Integration with online CAs

20. LDAP Getting Attributes into a Site’s Attribute Authority uid: jdoe eduPersonAffiliation: … isMemberOf: … eduPersonEntitlement: … SIS HR On-site Authorities Loaders Person Registry Group Registry Grouper UI Privilege Registry Off-site Authorities Signet UI Attribute Authority Core Business Systems Shib/ GridShib using Shibboleth

21. Federations  Persistent enterprise-centric trust facilitators  Sector-based, nationally-oriented  Federated operator handles enterprise I/A, management of centralized metadata operations  Members of federation exchange SAML 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 of members sets policy and operational direction for federation

22. Federations redux  created to support community interesting ones are multi-IdP, multi-SP embodies agreements on many levels –membership, technology, assurance, key mgt, legal, attributes, privacy, appropriate use, etc  facilitates member federated interactions many potential sub-communities and their apps operational support –key/config distribution, IdP discovery, etc doesn't preclude non-fed arrangements

23. Federations happening  i.e., SAML-based (or similar) federations in Europe, natural extension of HE NREN services –Switzerland, Finland, Netherlands, UK, Spain, France, etc in US –InCommon Federation in higher ed –also state-level planning, vertical apps such as student loan management –US government E-Authentication Program –also much non-fed or pre-fed deployment among fed members

24. InCommon federation  Federation operations – Internet2  Federating software – Shibboleth 1.2 and above  Federation data schema - eduPerson200210 or later and eduOrg200210 or later  Federated approach to security and privacy, with policies posted by members in common formats  Became fully operational 9/04; currently around 15 members  Precursor federation, InQueue, has been in operation for about two years and will feed into InCommon; approximately 250 members  http://www.incommonfederation.org

25. InCommon Members 7/1/05 Cornell University Dartmouth Georgetown University Ohio University Penn State University of California, Irvine University of California, San Diego The University of Chicago University of Rochester University of Southern California University of Washington University of California, Office of the President The Ohio State University University of California, Los Angeles Internet2 SUNY Buffalo Elsevier ScienceDirect OCLC WebAssign OhioLink - The Ohio Library & Information Network Cornell University Dartmouth Georgetown University Ohio University Penn State University of California, Irvine University of California, San Diego The University of Chicago University of Rochester University of Southern California University of Washington University of California, Office of the President The Ohio State University University of California, Los Angeles Internet2 SUNY Buffalo Elsevier ScienceDirect OCLC WebAssign OhioLink - The Ohio Library & Information Network

26. InCommon Uses  Institutional users acquiring content from popular providers (Napster, etc.) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.)  Institutions working with outsourced service providers, e.g. grading services, scheduling systems, software sales  Inter-institutional collaborations, including shared courses and students, research computing sharing, etc.  (Shared network security monitoring, federal research trust peering, interactions between students and federal applications, wireless network access, peering with international activities, etc.)

27. InCommon pricing  Goals Cost recovery Manage federation “stress points”  Prices Application Fee: $700 (largely enterprise I/A, db) Yearly 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

28. InCommon Management  Operational services by I2 Member services Backroom (CA, WAYF service, etc.)  Governance Steering Committee – drawn from CIO level leadership in the community - sets policies, priorities, etc. Project manager – Internet2  Contractual and policy issues were not easy and will evolve  Initially a LLC; likely to take 501(c)3 status in the long term

29. Trust in InCommon - initial  Members trust the federated operators to perform its activities well The operator (Internet2) posts its procedures Enterprises read the procedures and decide if they want to become members Contracts address operational and legal issues  Origins and targets establish trust bilaterally in out-of-band or no- band arrangements (using shared posting of practices) Origins must trust targets dispose of attributes properly Targets must trust origins to provide attributes accurately Risks and liabilities managed by end enterprises, in separate ways –Collaborative apps are generally approved within the federation –Higher risk apps address issues through contractual and legal means

30. Members Trusting Each Other: Participant Operational Practice Statement  Basic Campus identity management practices in a short, structured presentation Identity proofing, credential delivery and repeated authn Provisioning of enterprise-wide attributes, including entitlements and privileges  Basic privacy management policies Standard privacy plus Received attribute management and disposal  No audit, unclear visibility of policies

31. InCommon Progress  Relatively straightforward Syntax and semantics of exchanged attributes (Eduperson) Set up and operation of federation Selling the concept and value  More challenging Having applications make intelligent use of federated identity Handling indemnification Finding scalable paths for LOA components

32. Interfederation  an immediate consequence of federation brand-new federations don't have well-defined boundaries or service scopes it's the Internet, we're all connected many interesting SPs are global, e.g. Elsevier  Interfederation workshop, Oct 2004 Upper Slaughter, UK (a nicer walled garden?) many countries, including CERN many agreements on direction, future work

33. ... but it's a nice garden

34. Interfederation models  parallel universes members simply participate in many if needed consistent with fundamental pairwise nature of app-level relationships scaling, diversity not addressed  peering transitive assurance, legal, policy, maybe ops too tight a coupling?  league of federations? some historical examples...

35. Federal eAuthentication  Key driver for e-government, operating under the auspices of GSA  Leveraging key NIST guidelines  Setting the standard for a variety of federated identity requirements Identity proofing SAML bindings Credential assessment Risk assessment  Technical components driven through the InterOp Lab  http://www.cio.gov/eAuthentication/ http://www.cio.gov/eAuthentication/

36. eAuthentication Key Concepts  Approved technologies  The Federal “e-Authentication Federation”  Credential assessment framework  Trusted Credential Service providers  Agency Applications (outward facing, agency to agency and agency to citizen…)

37. InCommon E-Auth alignment  promote interop for widespread higher-ed access to USG applications grants process, research support, student loans...  process project started Oct 2004, thru Sept 2005 compare federation models propose alignment steps validate with federation members, via concrete application trials implement via next e-auth, InCommon phases

38. Validation steps  universities undergo trial by CAF assess whether compliance is likely across HE U Washington, Penn State, Cornell pretty darned close: 50% all-OK, others do-able  deploy access to a real USG app summer 2005 requires E-Auth acceptance of univs as CSPs app will modify existing provisioning process practical feedback to alignment recommendations

39. US person  motivated by InCommon desire for attribute-based authorization  modeled on Internet2 eduPerson spec  framework on which agency/app definitions can be built  not just SAML generic information model, mapped to LDAP, SAML, XML provisioning  ambitious? yes...

40. 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 – adding privacy (secrecy), ease of verification, addition of role, etc.  The analytic framework (evaluation methodologies for risk in applications and strength of credentials) and infrastructure developed for PKI is useful for federations.  The same entity can offer both federation and PKI services

41. A Few Other Items  Signet  Diagnostics  Integration  Virtual organizations

42. What’s It Mean For Magic  Federated identity Get agencies to participate in “Fed-fed” Assess the applications Agree on LOA approaches Build agencyPerson as a subordinate class to USPerson  Understand the tools and services becoming available to virtual organizations Virtual organization service centers Registries  Trust-mediated transparency and other security issues