Overview

The objective of the ISDA Web SSO is to provide a single sign-on solution for MIT web applications requiring authentication.  It will accomplish this by developing a central authentication service, to which users will be redirected the first time they attempt to access a protected page of a participating web server.  Once users have authenticated successfully, they will be redirected back to the original web page.  They will not need to authenticate again during the browser session, even when they visit other participating web sites. This service will support several ways for users to authenticate.

What problem are we trying to solve?

  • Users of MIT web applications find X.509 certificates awkward to use, thus increasing the support burden for web server administrators
  • Certificates cannot be used in certain client machine environments, e.g. from "kiosk" types of machines where users cannot install personal certificates, or in applications using delegated credentials.
  • Developers of applications would like to be able to use one authentication service for multiple types of authentication (certificate, Kerberos credentials, username/password over TLS) 

How do we intend to solve it?

  • Evaluate existing Web SSO packages, to determine which one best addresses our requirements, and assess the development effort that would be needed to enhance and customize the packages
  • Once a base package has been selected, develop the needed enhancements and customizations
  • Pilot a Web SSO implementation with 2 or 3 web applications
  • Evaluate the results of the pilot and potentially revisit our implementation
  • Produce a production quality Web SSO with 24/7 availability and a high Service Level Agreement 

What have we done so far?

  • We considered the four packages: Pub Cookie, Yale CAS, WebAuth and CoSign. This was narrowed down to two, WebAuth and CoSign. CAS was eliminated due to unsolved security issues, and Pub Cookie was eliminated as the sponsoring organization is dropping support for it.
  • We have evaluated two leading packages: WebAuth from Stanford University and CoSign from the UniversityofMichigan and recommended to the TRB that we proceed with Stanford's WebAuth.

Results of the December 15, 2006 meeting:

The current proposed solution will move forward with the Stanford WebAuth Login Server as the core point of authentication and will use Shibboleth components for the application servers. The WebAuth solution will only be used as a method for signing into the Shibboleth infrastructure, and it will not be made available to web application servers as a SSO method at this time, and that there would need to be a further discussion before a change in strategy or direction with the various parties.

Interactions: How does this solution interact with other work that the customer is doing, that we're doing elsewhere and that other parts of the organization are doing.

Positioning: How do we want to position this project? Who is it
useful to? Where would it not be a good fit?

Long term strategy: How does this fit into our long-term goals? What future work can we build on this?

Marketing requirements: What work do we propose to do? Give specific requirements that are necessary for the work to be useful to the customers.

  • No labels