Federations and Security: A Multi-level Marketing Scheme Ken Klingenstein Director, Internet2 Middleware and Security

Topics Context The Big Middleware Picture The Big Security Blob Areas of interactions Current status of federations International US deployments - Experimental, production, and federated Key issues Leveraging Federations trust attributes Roles Privacy and anonymization

A Map of Middleware Land

Components of Core Middleware

Federations Concept

The Art of Federating

The Big Security Blob Several fundamental problems Software complexity and flaws Naïve underlying protocols (SMTP, ICMP, DNS, etc) Human nature Others (economic gain, etc.) That compound with each other in multiple and diverse ways All in an embedded and growing base…

The Intersection Identity Management is a big part of security Authentication and authorization Data issues -encryption, privacy spills, etc And identity management may be a significant help in other areas of security Real time inter-realm incident handling, network access controls, etc Preserving core values – e.g. trust-mediated transparency

Federations Persistent enterprise-centric 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

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

SAML Security Access Markup Language – an OASIS standard SAML 1.0 current eAuth 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

Shibboleth v1.3b SAML and Shib open source implementation Certified for use with the US Federal Government e-Authentication Initiative WS-Fed compatible, funded by Microsoft Plugins for non-web services – GridShib, Lionshare, etc. Installs relatively easily Plumbing can take one day to four years, depending on local middleware infrastructure Getting some press…

Shibboleth 2.0 Features Convergence with commercial Liberty and SAML products refactors Shib What is the definition of Shibboleth 2.0? A SAML 2.0 profile An open source implementation of that profile, include SAML 2.0 as the building block Inclusion of open source add-ons such as ShARPE and Autograph

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

Federated model Enterprises and organizations provide local authentication and attributes, namespaces, 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. Provides a scalable alternative to multiple bi- lateral technical relationship management

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 Shib on the outside… Several million users in the UK between JISC and BECTA All working in concert with almost all major publishers for access control; some are using for security exchanges, software downloads,etc. EU WG29 may do a year-long study of privacy around Shibboleth

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

InCommon US R&E Federation 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…

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

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. Can federations happen in the US, or will we be bi-lateral hell? Can they be multi-application or should we have library feds (and Elsevier feds) and science feds?

Federal Eauthentication A federation of US Gov agencies, to provide services to each other and to the general population Services to be provisioned include NSF Fastlane, National Park Research and Camping Permits, Social Security management, export permits, etc Based on SAML protocol and Credential Service Providers to businesses and the general public A noble march through the DC political swamps

Inter-federation key issues Peering, peering, peering At what size of the globe? (Confederation for Europe?) 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

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 July 2006 application trials; implement via next e-auth, InCommon phases Peering Of InCommon and EAuth Definition of peering – attribute mappings, LOA, legal alignment, etc. Draft SAML 2.0 eAuthentication Profile Draft USPerson

Implications of using campus credentials in federations Level of Assurance (LOA) of Credentials Level 1 through Level 4 – maps to risk assessment of applications Many interesting applications are at levels 2-3 LOA depends on some organizational factors and User Identity proofing Delivery of credential to user Repeated acts of authentication

Take-aways for authn Single-Sign-On, and federated identity Think about several operational paths for identity management, with different types of users being credentialed differently (including two factor for certain applications), and a user going through several stages in identity proofing. Documenting policies and practices, with some internal audit processes.

Takeaways for authz Role-based access controls, both at the enterprise and virtual organization Privilege management for audit, compliance, and user scaling Local assignment of attributes evolving to community standards Privacy managers at both enterprise and personal levels Beware the side effects on network security

Leveraging federations Inter-institutional Trust Community Attributes and roles Privacy and anonymizations

Uses CSI2 Federated network access and eduroam Trust mediated transparency DKIM for spam control, etc DNSSec discovery Desktop firewall management (InfoCard)

Some specifics Infocard