Current stuff

1. Current stuff Ken Klingenstein Director, Internet2 Middleware and Security

2. Topics • Middleware (30 min) • Shib, Federations, etc. • Privilege Management and Groups • The Big Picture and Gaps • Other efforts – Sakai, Kuali, Chandler, etc. • Virtual organizations • Security (20 min) • REN-ISAC and collaborative security • Network admission control – here and there • Other activities – beyond the present and beyond the low hanging fruit • Other topics (10 min) • Campus research computing cyberinfrastructure

3. A Map of Middleware Land

4. Components of Core Middleware

5. Federations Concept

6. The Art of Federating

7. 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

8. 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

9. 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

10. 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

11. Shibboleth v1.3b • Certified for use with the US Federaal Government e-Authentication Initiative • WS-Fed compatible, funded by Microsoft • Installs relatively easily • Plugins for non-web services – GridShib, Lionshare, etc. • Plumbing can take one day to four years, depending on local middleware infrastructure • Over-the-top hype is unfortunately starting

12. Shibboleth 2.0 Features • What is the definition of Shibboleth 2.0? Is a new profile needed? • Convergence with commercial Liberty and SAML products • Support for the published Shibboleth profile (would not interoperate with Shibb v1.2…?) • Support for SAML 2.0 AuthN, Logout, Attribute Artifact, and NameID management requests • everything but AuthnQuery and AuthzDecisionQuery) • how applications would influence the AuthnRequest process

13. Shib Add-ons • Institutional Privacy Managers (e.g. ShARPE from Australia) • Personal Privacy Managers • Lionshare (peer-to-peer file sharing coupled to enterprise) • GridShibs…

14. Shib adoption • As noted below, widespread adoption overseas • Several million students and teachers in UK, replacing Athens as the bulk content mechanism • Production at every university in Switzerland, Finland; national deployments underway in Australia, Germany, Denmark, France, etc… • Elsevier, EBSCO, Thomson, OCLC, JSTOR, Napster, Ruckus, etc all have Shib in production or in an upcoming release • Several hundred US universities registered in InQueue; about seventy-five in production; about 25 in InCommon

15. 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

16. 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.

17. 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

18. 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…

19. 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?

20. 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

21. 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

22. 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

23. 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

24. 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?

25. 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

26. 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

27. 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.

28. 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?

29. Connecting SoAs, Integrating with Existing Infrastructure

30. Relative Roles of Signet & Grouper • RBAC model • Users are placed into groups (aka “roles”) • Privileges are assigned to groups • Groups can be arranged into hierarchies to effectively bestow privileges • Grouper manages, well, groups • Signet manages privileges • Separates responsibilities for groups & privileges Grouper Signet

31. Signet Overview • Analysts define privileges in Signet in functional terms and specify associated permissions • Signet presents this view in a Web UI where users assign privileges and delegate authority across all areas in which they have authority • Signet internally maps assigned privileges into system-specific terms needed by applications • Stored in an RDBMS, the Privilege Registry • Privileges are published as XML docs, transformed, & provisioned into applications and infrastructure services

32. Functional view Subsystems Categories Functions Scope, Limits Prerequisites & Conditions System view Permissions Subject Action Resource Privileges Building Blocks

33. Functional View Subsystems contain… Limits • Qualifiers, constraints for a privilege. • Scope • Organizational hierarchy governing distributed delegation, • Functions The things a person can do; what they are getting privileges for. Categories • Provide useful arrangement of functions within a subsystem; for reporting, ease of use.

34. Privilege Elements by Example Lifecycle Privilege

35. Grouper Binary info – you’re either in some list or not Identity- or affiliation-based access control or distribution Identification layer of an encompassing access management scheme Locally tweak or combine other groups Signet Structured, qualified info – limits, conditions, scope, … Oriented to individuals rather than roles Human judgment and chain of authority essential for access decisions Enable functional, not just technical, people to manage privileges Supports policy control closer to source of authority Audit requirements The duck test…

36. Signet & Grouper Roadmaps • Now available • Grouper v0.6. Basic group management, full GUI • Demo release of Signet v0.5 toolkit and UI • Signet Roadmap • v0.6, early October 2005 – designated drivers, history • v1.0, late November 2005 – lifecycle conditions, XML • v1.1 Toolkit / API release • Grouper Roadmap • v0.9, mid-November 2005 - internal refactoring, some enhancement • v1.0, mid-January 2006 – compound groups • v1.1, mid-March 2006 – group & membership aging

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

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

39. And then there’s security… • CSI2 and the REN-ISAC • Netauth • FWNA • Reconnections and the Redux • GENI