1 / 33

Shibboleth and InCommon: An Update and Next Steps

Explore the background of Shibboleth, trust fabrics, federations, and federating software in the context of InCommon. Learn about the milestones, status, adoption, and federated administration of Shibboleth.

awashington
Télécharger la présentation

Shibboleth and InCommon: An Update and Next Steps

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Shibboleth and InCommon:An Update and Next Steps

  2. Topics • Background on Shibboleth • Trust fabrics • Federations and Federating Software • InCommon • Of particular interest • Next Steps

  3. OK, I redirect your request now to the Handle Service of your home org. Please tell me where are you from? I don’t know you. Not even which home org you are from. I redirect your request to the WAYF I don’t know you. Please authenticate Using WEBLOGIN 2 3 4 5 6 1 7 Credentials SHIRE HS 8 Handle User DB Handle Resource Manager Handle 9 AA SHAR OK, I know you now. I redirect your request to the target, together with a handle Attributes 10 Attributes I don’t know the attributes of this user. Let’s ask the Attribute Authority Let’s pass over the attributes the user has allowed me to release OK, based on the attributes, I grant access to the resource Shibboleth AA Process WAYF Users Home Org Resource Owner Resource

  4. Shibboleth Architecture

  5. Shibboleth Architecture -- Managing Trust Federation Shib engine Attribute Server Target Web Server Browser Target Site Origin Site

  6. Milestones • Project formation - Feb 2000 Stone Soup • Process - began late summer 2000 with bi-weekly calls to develop scenario, requirements and architecture. • Linkages to SAML established Dec 2000 • Architecture and protocol completion - Aug 2001 • Design - Oct 2001 • Coding began - Nov 2001 • Alpha-1 release – April 24, 2002 • OpenSAML release – July 15, 2002 • v1.0 April 2003 • v1.1 July 2003 • V1.2 April 2004 • V2.0 likely end of the major evolution

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

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

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

  10. Federations • Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions • Enroll and authenticate and attribute locally, act federally. • Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*) common attributes (e.g. eduPerson), and a security and privacy set of understandings • 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. • Several federations now in construction or deployment

  11. Federated administration VO VO O T A CM O T CM A Campus 1 Campus 2 T T T Federation

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

  13. 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 InQueue Origins2.12.04

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

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

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

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

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

  19. Next Steps • Shibboleth • The GUI’s – SysPriv, Autograph, MySpace • Linked identities • New development model – international participation • InCommon • Policy development • Membership • Distnguishing buyers clubs from federations

  20. GUI’s to manage Shibboleth

  21. SysPriv ARP GUI • A tool to help administrators (librarians, central IT sysadmins, etc) set attribute release policies enterprise-wide • For access to licensed content • For linking to outsourced service providers • Has implications for end-user attribute release manager (Autograph) • GUI design now actively underway, lead by Stanford • Plumbing to follow shortly

  22. End-user attribute release manager(Autograph) • Intended to allow end-users to manage release policies themselves and, perhaps, understand the consequences of their decisions • Needs to be designed for everyone even though only 3% will use it beyond the defaults. • To scale, must ultimately include extrapolation on settings, exportable formats, etc.

  23. Privacy Management Systems

  24. Personal Resource Manager

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

  26. 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 NMI • Tool set likely to include seamless listproc, web sharing, shared calendaring, real-time video, privilege management system, etc.

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

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

  29. Stanford Authz Model

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

  31. Home

  32. Grant Authority Wizard

  33. Person

More Related