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

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 Grouper Signet 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

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. Privileges Building Blocks Functional view Subsystems Categories Functions Scope, Limits Prerequisites & Conditions System view Permissions Subject Action Resource

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 By authority of the UPCI IRB grantor UPCI Researchers grantee (group/role) who have an approved UPCI IRB protocol prerequisite can access de-identified data and order tissue function from the network of caTIES participants scope for Study HD7687 resource up to 100 patients limit until January 1, 2006 as long as approved for material transfer … conditions Privilege Lifecycle

35. The duck test… 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

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 Grid Service Session authentication credential Attribute Authority Home Org Virtual Org Affiliated Org Authorities Grid user Signet, Grouper

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