Agenda

1. Deploying a Collaboration Infrastructure Across State and Higher Education Federations Ken Klingenstein

2. Agenda • Scenarios to set the stage • Untangling the concepts of trust • Federations and their characteristics • Update on current events • Questions to ponder

3. Scenarios • Student accessing class resources from several different campuses • State system doing bulk purchases and access management of educational materials for their K-20, vocational, and continuing education programs as well as state-supported medical and incarceration facilities. • K12 teacher taking a distance course at a university and accessing state-shared resources as both a teacher and a student. • University participating in a state consortium for seamless management of student information, an international consortium for computational research, and higher-ed library partnership with other regional schools.

4. A note about terms • Identities, attributes, and directories • Authentication and authorization • Credentials in the electronic context • Target and origin • Security domain

5. Concept of trust • Exists in almost every transaction between entities • Works in complex fashion • E.g. in an end-user-enterprise-target transaction, • user trusts enterprise to release attributes according to user preferences • Enterprise trusts user to protect their security credentials • Enterprise trusts target to properly dispose of attributes once they are used • Target trusts enterprise to faithfully provide attributes about the user • Trust itself is personal and subjective, though laws and contracts affect that. • One size didn’t fit all and proved intractable; several sizes seem more comfortable and may prove more tractable

6. Unified field theory of trust • Bridged, global hierarchies of identification-oriented, often government based trust – laws, identity tokens, etc. • Passports, drivers licenses • Federated enterprise-based; leverages one’s security domain; often role-based • Enterprise does authentication and attributes • Federations of enterprises exchange assertions (identity and 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. • Virtual organizations could leverage any of these fabrics

7. What are federations? • Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions • Built on the premise of • Initially “Authenticate locally, act globally” • Now, “Enroll and authenticate and attribute locally, act federally.” • Federation provides only modest operational support and consistency in how members communicate with each other • 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. • Over time, this will all change…

8. Three types of federations • Internal federations are occurring among the many subsidiaries of large companies, especially for those companies with more dynamic aggregations. • Private federations occur among enterprises, typically within a market sector, that want to facilitate a specific set of transactions and interactions. Many will be bi-lateral, short-term or otherwise constrained. • Public federations address more free-standing, long-term, general-purpose requirements, and need to be more open about rules of engagement. Public federations face significant scaling issues and may not be able to leverage contractual relationships that private federations can.

9. The good • Very flexible – easy to establish and operate; can work for 2 or 2000 members • Very customizable – tailored to fit the precise membership • Address the whole problem space – security, data schema, privacy, security, transport – of inter-realm collaborations • Are relatively simple to install and operate, both for enterprises and for end-users

10. The bad • They aren’t real, yet • They don’t do everything • Are web services based right now • Will hit scaling walls in several dimensions; we don’t see clear answers yet…

11. The unknown • The scaling walls • How reality will unfold • The convergence of the various federating software solutions • Users’ willingness to manage their privacy and security

12. Requirements for federations • Federation operations • Federating software • Exchange assertions • Link and unlink identities • Federation data schema • Federation privacy and security requirements

13. Federating software • Liberty Alliance • V 1.1 of their functional specs released; 2.0 under discussion • Federation itself is out of scope • Semi-open source under development • Current work is linked identities • Shibboleth • V1.1 released; 2.0 under discussion • Most standards-based (though Liberty has said that they will turn their enhancements into standards organizations) • Pure open source • Current work is attribute release focused. • WS-*

14. WS-* • Work by Microsoft, with participation from IBM and BEA et al • 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. • Several of the specifications areas still unreleased • Standards process very unclear; significant IPR issues exist • No implementations yet; indeed a lofty set of abstractions that will need considerable convention and detail to resolve into a working instantiation

15. Interoperability among federations Or, more precisely, interoperability between two members of distinct federations • Ability to pass each other assertions • Protocols and architectures • Ability to understand each other’s assertions • Syntax and semantics of objectclasses and schema • Ability to trust each other’s assertions • Er……

16. A note about public key infrastructure • You’ll hear about it…. • Different technology and policy efforts moving along in parallel • Hierarchical model like roots of a tree • Users have a private token which can be used for both authentication and authorization • Service providers must verify the issuer of the token, then the verifying party, then the party doing the verification, and so on until they see a common trusted party • What happens if your root authorities are different? • Set up relationship with Higher-ed Bridge Certification Authority • Map the technologies and policies among peers

17. More notes about PKI:Federations and classic PKI • They are very similar • Both imply trust models • Federations are a enterprise-enterprise PKI • Local authentication may well be end-entity certs • Name-space control is a critical issue • And they are very different • End user authentication a local decision • Flat set of relationships; little hierarchy • Focus as much on privacy as security • Web Services only right now: no other apps, no encryption • We get to define…

18. Shibboleth-based federations • InQueue • InCommon • Club Shib • SWITCH • NSDL ------------------------------------ • State networks • Medical networks • Financial aid networks • Life-long learning communities

19. InQueue • The “holding pond” • Is a persistent federation with “passing-through” membership… • Operational today. Can apply for membership via http://shibboleth.internet2.edu/ InQueue federation guidelines • Requires specific directory information (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

20. InCommon • A persistent, multipurpose federation for US R&E • Two stage set up process • Direction setting group to establish InCommon • Chaired by Greg Jackson, includes 5-6 campus CIO’s, 1-2 target CTO’s • Decisions on organizational structure, membership, management • InCommon going forward • Management group • Storefront and backend; fees • Operations • Operational date within a month or two

21. InCommon key issues • Who is the membership? Origins? Targets? Univ? Application or Content Service Providers? • How is membership packaged and priced? • How are membership covenants enforced? • How is InCommon operated? • What kind of entity is InCommon?

22. REF Cluster InQueue (a starting point) Other clusters Other potential US R+E feds Other national nets SWITCH InCommon NSDL The Shib Research Club State of Penn Fin Aid Assoc The research and educationfederation space Indiana Slippery slope - Med Centers, etc

23. Trust pivot points in federations • To respond to real business drivers and feasible technologies, we will need to increase the strengths of • Campus/enterprise identification, authentication practices • Federation operations, auditing thereof • Campus middleware infrastructure in support of the federating architecture (including directories, attribute authorities and other components) and auditing thereof • Relying party middleware infrastructure in support of the architecture • Moving in general from self-certification to external certification

24. Case Studies

25. Other examples • Dell store selling discounted hardware to folks in higher ed •  Dining card access account status     • E-procurement application sends assertions to vendor X that person Y is allowed to charge on A, B, & C accounts for Z amount.

26. Questions to ponder • What services would you like to offer that need Federating? • Why do the services need it? • Will we want to offer/use services with different security requirements? • What kind of entity do we set up that protects itself and still fosters inter-institutional collaborations? • Who are the members of the entity? • What are the business and management models?