Download presentation
Presentation is loading. Please wait.
Published byBernadette Cunningham Modified over 9 years ago
1
Dr Ken Klingenstein Shibboleth and InCommon: An Update and Next Steps
2
Topics Developments and designs Shibboleth and InCommon Signet – an authority system Integrated diagnostics Discussion International trust fabrics Virtual organization support Coordinated software development
3
Shibboleth Status Open source, privacy preserving federating software Being very widely deployed in US and international universities Target - works with Apache(1.3 and 2.0) and IIS targets; Java origins for a variety of Unix platforms. V2.0 likely to include portal support, identity linking, non web services (plumbing to GSSAPI,P2P, IM, video) etc. Work underway on intuitive graphical interfaces for the powerful underlying Attribute Authority and resource protection Likely to coexist well with Liberty Alliance and may work within the WS framework from Microsoft. Growing development interest in several countries, providing resource manager tools, digital rights management, listprocs, etc. http://shibboleth.internet2.edu/
4
Adoption Over 40 + universities using it for access to OCLC, JSTOR, Elsevier, WebAccess, Napster, etc. Common status is “moving into production” The hard part is not installing Shibboleth but running “plumbing” to it: directories, attributes, authentication Deployments in Europe and the UK Development efforts broadening to the UK and Australia Likely to be the interrealm aspect to Sakai, Lionshare, video
5
Federated administration Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so Build consistent campus middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then Federate (multilateral) those enterprise deployments with interrealm attribute transports, trust services, etc. and then Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, from p2p to virtual organizations, etc. while we Be cautious about the limits of federations and look for alternative fabrics where appropriate.
6
Federated administration OTOT OTOT TT A CM CM A VO T Campus 1 Campus 2 Federation
7
InCommon federation Federation operations – Internet2 Federating software – Shibboleth 1.1 and above Federation data schema - eduPerson200210 or later and eduOrg200210 or later Becomes operational April 5, with several early entrants to help shape the policy and membership issues. Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon http://www.incommonfederation.org http://w
8
InQueue Origins 2.12.04 Rutgers University University of Wisconsin New York University Georgia State University University of Washington University of California Shibboleth Pilot University at Buffalo Dartmouth College Michigan State University Georgetown Duke The Ohio State University UCLA Internet2 Carnegie Mellon University National Research Council of Canada Columbia University University of Virginia University of California, San Diego Brown University University of Minnesota Penn State University Cal Poly Pomona London School of Economics University of North Carolina at Chapel Hill University of Colorado at Boulder UT Arlington UTHSC-Houston University of Michigan University of Rochester University of Southern California
9
InCommon Management Operational services by I2 Member services Backroom (CA, WAYF service, etc.) Governance Executive Committee - Carrie Regenstein - chair (Wisconsin), Jerry Campbell, (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teetz, (OCLC), David Yakimischak (JSTOR). Project manager – Renee Frost (Internet2) Membership open to.edu and affiliated business partners (Elsevier, OCLC, Napster, Diebold, etc…) Contractual and policy issues being defined now… Likely to take 501(c)3 status
10
Trust in InCommon - initial Members trust the federated operations to perform its activities well The operator (Internet2) posts its procedures, attempts to execute them faithfully, and makes no warranties Enterprises read the procedures and decide if they want to become members Origins and targets trust each other bilaterally in out-of- band or no-band arrangements Origins trust targets dispose of attributes properly Targets trust origins to provide attributes accurately Risks and liabilities managed by end enterprises, in separate ways
11
InCommon Trust - ongoing Use trust Build trust cycle Clearly need consensus levels of I/A Multiple levels of I/A for different needs Two factor for high-risk Distinctive requirements (campus in Bejing or France, distance ed, mobility) Standardized data definitions unclear Audits unclear International issues
12
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
13
The potential for InCommon The federation as a networked trust facilitator Needs to scale in two fundamental ways Policy underpinnings need to move to normative levels among the members; “post and read” is a starting place… Inter-federation issues need to be engineered; we are trying to align structurally with emerging federal recommendations Needs to link with PKI and with federal and international activities If it does scale and grow, it could become a most significant component of cyberinfrastructure…
14
Beyond web services… Federated security services Collaborative incident correlation and analysis Trust-mediated transparency and other security-aware capabilities Federated extensions to other architectures Lionshare project for P2P file sharing IM Federated Grids
15
Virtual Organizations Geographically distributed, enterprise distributed community that shares real resources as an organization. Examples include team science (NEESGrid, HEP, BIRN, NEON), digital content managers (library cataloguers, curators, etc), life-long learning consortia, etc. On a continuum from interrealm groups (no real resource management, few defined roles) to real organizations (primary identity/authentication providers) Want to leverage enterprise middleware and external trust fabrics
16
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; solicitation is on the streets (see (http://www.jisc.ac.uk/c01_04.html); builds on NSF NMIhttp://www.jisc.ac.uk/c01_04.html Tool set likely to include seamless listproc, web sharing, shared calendaring, real-time video, privilege management system, etc.
17
Leveraging V.O.s Today VO Target Resource User Enterprise Federation
18
Leveraged V.O.s Tomorrow VO Target Resource User Enterprise Federation Collaborative Tools Authority System etc
19
Stanford Authz Model
20
Signet Deliverables The deliverables consist of A recipe, with accompanying case studies, of how to take a role-based organization and develop apprpriate groups, policies, attributes etc to operate an authority service Templates and tools for registries and group management a Web interface and program APIs to provide distributed management (to the departments, to external programs) of access rights and privileges, and delivery of authority information through the infrastructure as directory data and authority events.
21
Home
22
Grant Authority Wizard
23
Person
24
Steps to Enable Diagnostic Applications Establish the common event record Enable the collection of events from a wide array of event sources Network: NetFlow, SNMP, RMON, etc Security: IDS, Snort, firewalls, etc Applications: Shib, Dir, IM, P2P, smtpd, named, httpd, Kerberos, etc Hosts: /var/log/*, Syslog, etc
25
Steps to Enable Diagnostic Applications (2) Build tools to create dissemination infrastructures that, Allows access to the diagnostic data Provides operators to filter, anonymize, aggregate, tag, store and archive the data Enables pipelining of data operators to organize and manipulate diagnostic data based on an organization or federations policies Provide a common API so applications can access the diagnostic data
26
Enabling Diagnostic Applications With a Common Event Descriptor Security Related Events Middleware Related Events Network Related Events Collection and Normalization of Events Dissemination Network Diagnostic applications (Middleware, Network, Security) can extract event data form multiple data sets
27
Discussion International trust fabrics – national federations – International peering Virtual organization support – the nature of our collaborations –Difficult issues of inconsistent level of campus and country middleware infrastructure Coordinated software development
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.