...
MIT Touchstone is a new suite of technologies for authenticating a variety of web applications, being introduced by IS&T.
...
MIT Touchstone does provide a single sign-on solution for applications that have been coded and configured to use the system. Within the context of Touchstone enabled applications, users will be able to seamlessly transition between systems without be being prompted for additional authentication information.
...
MIT Touchstone introduces some new functionality into the MIT environment. It allows MIT people to use a wider variety of authentication mechanisms, under a variety of conditions, when accessing a number of MIT web applications. As we move forward it will it will also enable MIT users to access some web applications at other sites without establishing a new account with the other site. In addition to supporting MIT X.509 certificates, people may also use Kerberos, or a username and password over TLS. Web developers at MIT will be able to use federated authentication, so that they can easily determine that whether an MIT users has authenticateduser, or users a user from other authentication authoritiesanother authentication authority, has authenticated.
How will MIT Touchstone improve the user experience?
MIT users will be able to use a variety of mechanisms to authenticate to Touchstone enabled web applications. This means that if a user is barrowing borrowing a computer or sharing a computer with others, they may choose to use a password instead of installing a certificate. On the other hand, users of the WIN.MIT.EDU or Athena environments may choose to configure their profiles so that native Kerberos is used. This means that the system will automatically authenticate the user to web applications when needed by using the Kerberos ticket obtained when first logging into the workstation. Of course, certificates are still supported so users can continue to use their current procedures.
...
By adopting one technology, the web server essentially outsources the authentication task and ends up enabling the users to authenticate with a much wider variety of authentication mechanisms, including passwords, X.509 certificates, Kerberos, and OpenID. At the same time the web server will avoid the typical risks and concerns associated with consuming passwords. Nor will the system have to have any code to deal with certificates, Kerberos, or OpenID.
...
MIT Touchstone is actually a suite of technologies, including Stanford's WebAuth, Internet 2's Shibboleth, SAML (the Security Assertion Markup Language), and a new account management system for some of users outside of the traditional MIT community. The system also relies upon http HTTP redirection.
The primary login server is using Stanford's WebAuth code package for initial authentication. Touchstone does not use the other component of Stanford WebAuth. The login server will initially support three authentication mechanisms which are -- MIT X.509 certificates, Kerberos (via the http-spnego protocolHTTP/SPNEGO protocol), and MIT usernames and passwords over TLS. The WebAuth server is bound to a Shibboleth Identity Provider (IdP). The IdP is then treated as a trusted third party by the web application servers; it makes signed assertions to these applications servers, communicating information about the authenticated users to each web server. From an architectural perspective, this is very similar to the model used by Kerberized applications on campus today, although different protocols are used.
Each web application server that wishes to use Touchstone will have to run the Shibboleth Service Provider (SP) component as well. This required software required is available for Apache and IIS . In web servers; in the future we may also support web server servers that use Tomcat without Apache, but that option will not be available initially.
In conjunction with Touchstone, IS&T is creating a new accounts management system intended to support users that are not part of the core the core MIT community, and thus would not have MIT Kerberos accounts. Accounts managed by this system will identify the user by their external email address. This system will also provide a login server that will accept passwords; additionally, OpenID will be supported as an authentication mechanism. This system will also serve as a Shibboleth Identity Provider (IdP) within the Touchsone environment.
...
At its simplest, Touchstone will set some one or more environment variable variables on your Apache or IIS server, include including REMOTE_USER. Your application can then use these results. A demonstration application is available which shows the environment variables that do get set, this can be viewed at https://mv-ezproxy-com.ezproxyberklee.flo.org/shib-testenv. Of course, your web server will have to have Shibboleth installed, and the MIT IdP will need to be made aware of your application. To secure the communication between your web application and the MIT IdP you will also need an MIT certificate for your server.
The most important fact for a web developer to consider when integrating Touchstone is that a successful authentication should not apriori grant privileges. Instead the system should examine the identifier of the authenticated user and then determine which privileges to grant to that user. Within Touchstone, authenticated users are not necessarily from MIT, ; the user may come from anywhere in the world, and may be authenticated via other another organization's systemssystem. The user identifier will normally look like an email address, e.g. JohnDoe@mit.edu or JohnDoe@example.com.
...
Federated Authentication is the current jargon for outsourcing authentication to multiple known providers. Touchstone will initially support a small number of authentication providers, namely MIT's IS&T and ProtectNetwork. Overtime Over time the number of providers will grow. Our intent is to join the InCommon federation which has many members from the U.S. higher-ed community.
...