What is MIT Touchstone?
MIT Touchstone is IS&T new suite of technologies for authenticating a variety web applications.
Is MIT Touchstone a single sign-on solution?
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 prompted for additional authentication information.
Why is IS&T introducing Touchstone?
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 an MIT users has authenticated, or users from other authentication authorities.
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 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.
Why should a department, lab, or center, integrate their web application into Touchstone?
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.
Another benefit is that the web application will no longer have to deal with local accounts or special accounts for external users and collaborators. Instead the management of that community can be outsourced to Touchstone's external account management system. By doing so, the users are provided with self-service passwords resets, and the ability to use OpenID if they don't want to use passwords. This means that web applications will have the same interfaces and code paths to deal with authenticated users.
DLCs should also be aware that Touchstone supports federated authentication. This means that as Touchstone establishes relationships with other identity providers, the web applications will be able to interact with an even wider audience if desired. Touchstone has already established a relationship with ProtectNetwork.org and is expected to join the InCommon federation in the near future.
What technologies does Touchstone use?
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 redirection.
The primary login server is using Stanford's WebAuth code 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 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 software required is available for Apache and IIS. In the future we may also support web server 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. 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.
What MIT applications support Touchstone today?
Touchstone is just entering its pilot phase. During the pilot only a small number of applications will be part of Touchstone. The following applications are expected to participate in the pilot:
- Stellar
- Wiki.mit.edu, the MIT Confluence wiki system
- Jira
- Dspace
- Thalia
- Alfresco
How do I integrate my web application with MIT Touchstone?
At its simplest, Touchstone will set some environment variable on your Apache or IIS server, include 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 organization's systems. The user identifier will normally look like an email address, e.g. JohnDoe@mit.edu or JohnDoe@example.com.
During the pilot phase of introducing Touchstone on campus, we suggest that you contact the MIT webauth-dev list for some free, individual consulting. As we move into production there will be additional IS&T groups that can help you with your project and we will have more online documentation.
You may also be interested in looking at some of the existing 3rd party Shibboleth documentation. The Shibboleth wiki can be found at https://spaces.internet2.edu/display/SHIB/WebHome and the Shibboleth home page can be found at http://shibboleth.internet2.edu/.
What is federated authentication?
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 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.
Any user can obtain a ProtectNetwork account and use that to authenticate to MIT Touchstone enabled servers. More information about ProtectNetwork can be found at http://protectnetwork.org/.
More information about the InCommon Federation can be found at http://www.incommonfederation.org/. The current list of InCommon Federation participants can be found at http://www.incommonfederation.org/participants.cfm. Note that users from each of these organizations will be able to authenticate to MIT Touchstone systems. Similarly, MIT users will be able to authenticate to some of the web applications at these sites.