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
MIT IS&T wishes to improve web authentication in several ways:
1) We wish to improve the experience for users that are using kiosk machines that do not support the use of soft certificates or hardware tokens.
2) We wish to improve the experience for users new to the MIT community that have not yet obtained a soft certificate or a hardware token.
3) We wish to provide a solution for web server administrators that they will find easy to configure and will not prompt users for a username and password.
The goal of this project is to:
1) develop the technical requirements necessary to improve our web authentication mechanism
2) investigate existing web authentication mechanisms and select a system that meets our desires and requirements
3) prototype an implementation at MIT to flesh out any issues and demostrate the results
4) communicate the work of this effort broadly within IS&T and the community
5) work within the IS&T framework to form a core team that will bring the project to full support and deployment.
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.
Sam's requirements for a scope statement:Abstract: What problem are we solving, who ill it benefit and thow
will they take advantage of it?
Problem: How do things work today? Why is this not optimal? What
customer needs are there?
Solution: A brief outline of the solution.
How customers will use the solution; how it ]solves there problem;
what properties of the solution are important to it being useful to the customer?
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.Project plan: resources, timelines etc.