1 / 17

Shibboleth and Local Web-ISO

Explore the scope of work, architectures, policies, and technologies of Shibboleth and Web-ISO for web resource sharing and user authentication. Learn when to use each system and the potential for long-term convergence.

cassandrap
Download Presentation

Shibboleth and Local Web-ISO

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. Shibbolethand Local Web-ISO Scott Cantor cantor.2@osu.edu The Ohio State University Internet2/MACE

  2. Shibboleth “Scope of Work” Architectures, policy structures, practical technologies, and an open source implementation to support inter-institutional sharing of web resources subject to access controls. • Federated Administration • Access Control Based On Attributes • Active Management of Privacy • Standards Based • Extensible Policy and Trust Framework (“Clubs”)

  3. Web-ISO “Scope of Work” Share expertise and develop common solutions to standardize user authentication to intra-enterprise web-based services with single sign-on and other useful functionality. • Multiple domains, but not multiple organizations • Strictly deals with authentication and identity • Protects privacy only externally to system • Collects requirements from many proprietary SSO systems

  4. Shibboleth “fits” with Web-ISO • Implements an industry-standard SSO protocol designed for both inter- and intra-organizational use • Capable of communicating a superset of the information Web-ISO provides to applications • Applications used by extra-organizational users are also used by intra-organizational users • Other application and security requirements are equally applicable to both systems

  5. Shib “misfits” w/ Web-ISO • Pubcookie (and other code bases) are more mature in performance, stability, and features • Focus of Shibboleth architectural work is on the new features beyond Web-ISO • Privacy features imply that obtaining username requires an extra lookup • Security properties of the SAML SSO profiles may not match that of some Web-ISO implementations

  6. When Shibboleth Makes Sense • Deployed Web-ISO is primitive, non-existent, or aligns well with Shibboleth design • Enterprise LDAP and/or authorization services are immature or under-supported relative to web security projects • Internal politics create information boundaries that privacy/trust controls can help to cross • Simplicity of application access to attributes is a virtue

  7. When Web-ISO Makes Sense • Existing approach aligns better with Web-ISO design and assumptions • Advanced features of system are deemed important in the short term • Mature directory and/or authorization services are available for use by applications • Libraries readily available to simplify efficient access to attributes (caching, redundancy, etc.) • Majority of services want username and little else

  8. Long Term Convergence ofShibboleth and Web-ISO Assuming SAML maintains momentum, the Web-ISO project can meet requirements for better standardization by moving toward it. A SAML-compliant Web-ISO fundamentally differs from Shibboleth only with respect to trust/policy requirements and privacy controls. Timetables and plans for such convergence are not currently in place.

  9. Short Term: Using Shibboleth with Web-ISO • Shibboleth Handle Service can be deployed as a locally-secured application • Attribute Authority might utilize similar infrastructure to that used by applications • Applications straddling internal/external boundary must accommodate both modes of access • Some overlap in management of the two systems

  10. Short Term: Using Shibboleth as Web-ISO • Somewhat ahead of the project, so some gap-filling required • Handle Service expected for Beta-1 should provide cookie-based SSO across a replicated array of login sites, but still assumes authentication is already done • Small amount of work to merge in an existing form-based login service • PKI-based server interactions may be new

  11. Short Term: Using Shibboleth as Web-ISO • Analysis of required target-side functionality • Platform support (Linux, Solaris, Windows), but basic portability should be very high • Web server support (Apache 1.3), IIS likely to be next priority, but OSU (at least) will make iPlanet and Apache 2 versions available quickly • Performance, performance, performance

  12. Shibboleth at OSU:A Case Study • Homegrown Web-ISO assigns each session a UUID, then targets query back for user attributes (username, SSN, employee ID) via secure RPC and export attributes to HTTP headers for use by applications or access control modules • Shibboleth assigns each session a handle, then targets query back for user attributes via SSL, and export attributes to HTTP headers for use by applications or access control modules Hmm…

  13. Shibboleth at OSU:A Case Study What’s Different: • DCE-RPC is a lot faster than XML over SSL • Management of server identity and attribute access currently easy with DCE and groups; Shibboleth introduces PKI and ARPs • Some targets currently don’t have an SSL key-pair, where do they get one for free? • Should the entire local deployment be “club-compliant” or should there be a wall between external and internal Shibboleth?

  14. Shibboleth at OSU:A Case Study What’s Different: • Most important attributes used by OSU other than EPPN not yet defined by club • Existing applications may expect usernames of a certain format or length (“legacy mode”), or may conflate authentication with authorization (gasp!) • Existing Web-ISO does have some features not currently in Shibboleth code base (but not many) • Platform support (IIS, iPlanet, Apache)

  15. Shibboleth at OSU:Tentative Plan • Finalize SOW for Shibboleth 1.0 (what’s in/what’s out), to identify expected feature gaps • Fork Shibboleth code at OSU to add missing features, documenting the extensions for possible broader adoption (Liberty?) • First decision point: is LDAP service “cooked” enough or will relational data store be necessary?

  16. Shibboleth at OSU:Tentative Plan Phase One: • Deploy Handle Service behind existing Web-ISO • Migrate selected target servers (starting with mine) to Shibboleth for evaluation, in “legacy mode” • Should allow simultaneous SSO across both systems • Final acceptance testing by cutting over high volume applications at a busy time (grades, scheduling)

  17. Shibboleth at OSU:Tentative Plan Phase Two: • Deploy redundant Handle Services as stand-alone authenticators • Migrate remaining servers • Shut down legacy system! • Applications can be upgraded in parallel to decrease use of “legacy mode”

More Related