1. The New Problem Space: Issues for the Future Ken Klingenstein Director, Internet2 Middleware and Security

2. Topics  Shib Coordination of Shib development process Integration of InCommon into applications  Institutional use Identity management systems: 0, 1, more… The closing of open shelves Impact of transparency on help desks  Interinstitutional use Realizing federations Boundary uses of Shib Virtual organizations Federated security services Peering of federations

3. Coordination of Shib development  Development now taking place in several countries, with significant investments outside the original development crew.  A reasonable re-layering of architecture and code might be helpful  Management role models: Likely: OpenLDAP, Apache Less likely: GGF  Alignment of licensing and copyright could be challenging

4. Integration of InCommon into applications  Rethinking the architecture versus slapping on Shib  Moving campus-oriented systems into an inter-institutional model (authn is not in a desktop file…)  Providing authn/z for outsourced services

5. Campus identity management  Identity management systems are the key origin component  Many campuses still don’t have one; many have just one; some campuses have more than one  Can introduce significant user confusion Which one do I select from the WAYF What attributes get released from which origin

6. Closing of open shelves  Attribute based access control is a fine granularity, allowing campuses to perhaps reduce licenses costs by reducing eligible members  Is that desirable? Is that understandable by students? Are the management costs worth the license savings?  Do the content providers want this?  Do we need a policy on persistent targetID release standards?

7. Transparency and problems  Fine grain transparent access controls are going to be difficult to diagnose.  Right now, at least four different failure points result in the same Shib error message The target host is down Network performance caused time out of the Shib protocols Firewall blocked the ARP communications Shib itself is misconfigured  And that error message sucks… (Shire not found)  Worst, fine grain access controls will be harder for coarse users…

8. Realizing federations  Concluding policy frameworks  Creating a widely endorsed and useful level of initial trust  Being able to grow that trust (in scale and in levels of assurance)  Limiting the complexity

9. Boundary uses of Shib  The Canoe Club wants to control access of some of its web content to other canoe clubs. Who decides what attributes they can get and vouch for the privacy handling?  Associated health clinics want to access Medline through the medical school contract. Who vouches for their authentication services?

10. Virtual organizations  Need a model to support a wide variety of use cases Native v.o. infrastructure capabilities, differences in enterprise readiness, etc. Variations in collaboration modalities Requirements of v.o.’s for authz, range of disciplines, etc  JISC in the UK has lead; builds on NSF NMI see http://www.jisc.ac.uk/index.cfm?name=c01_04http://www.jisc.ac.uk/index.cfm?name=c01_04  Tool set likely to include seamless listproc, web sharing, shared calendaring, real-time video, privilege management system, etc.

11. Leveraging V.O.s Today VO Target Resource User Enterprise Federation

12. Leveraged V.O.s Tomorrow VO Target Resource User Enterprise Federation Collaborative Tools Authority System etc

13. Federated Security Services  Federated networks Share a common network substrate Share a common trust fabric Together they could permit…  Collaborative incident analysis and response Network-wide views Leveraged diagnostic help Ability for automated tools to use distributed monitors Protect privacy at several layers  Security-aware capabilities Trust-moderated transparency Integrated security/performance diagnostics  Moving it into the broader Internet

14. Collaborative Incident Analysis  Moving beyond the “border” to see network-wide views I’m seeing activity X? Are others seeing it? What variants are they seeing? Real-time attack recognition From the central observatory, let me see the full address of the attacking node at site Y in the federation I’m seeing an attack ostensibly from source address z at enterprise Y. Let me look at logging within site Y to verify Correlate signatures and traffic among sites A-Z to provide an early warning system of DDOS Let external experts from site Z examine our forensic information to assist our diagnostics  Requires federated backbone (meters, log files, etc) and federated trust fabric (for scaling, role-based access control, contact info, etc.)

15. Collaborative incident analysis  Scaling requires managing large data sets Centralized – the Abilene Observatory, perhaps others Distributed – on a per enterprise level  Which in turn requires a clear data model Common event records, likely distilled and reformatted from native logs Is enterprise-level security sufficient  And also pluggable modules for harvesting records by tools  Tools that permit analysis and yet preserve privacy  And also a trust fabric that permits multiple levels of authentication and fine-grain authorization

16. Federated Security-aware Capabilities  Federated user network authentication for on-the-road science  Control spam through federated verification of sending enterprises  Tell me which firewall is dropping which service request  Permit end-end videoconferencing through firewalls and NATs  Allow enterprise-specific patching paradigms to coexist  Create end-end transparency for use of Grids  Personal firewall configuration based on authorization

17. Inter-federation issues  Managing the complexity  Nested federations – UT and InCommon  Overlapping federations - IHETS and InCommon  Peering federations

18. Touch points for federation peering  Cross map attributes  Correlate LOA’s  FOP FOP Trust  Apps/trust matrix

19. Federations that could peer  Intra-campus federations  System federations (UT, SUNY, UC, UNC, etc.)  National federation (InCommon)  Other national federations (UK, Switch, Finland, Australia, Netherlands, FEIDE, etc.)  Federal federations

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

21. Upper Slaughter, England

22. International federation peering  Shibboleth-based federations being established in the UK, Netherlands, Finland, Switzerland, Australia, Spain, and others  International peering meeting slated for October 14-15 in Upper Slaughter, England  Issues include agreeing on policy framework, comparing policies, correlating app usage to trust level, aligning privacy needs, working with multinational service providers, scaling the WAYF function  Leading trust to Slaughter…