Search Google Appliance

Touchstone at MIT

On this page:
Obtaining an Account
Using MIT Touchstone
Helpful Links


IS&T operates MIT Touchstone as a single sign-on web authentication service that allows members of the MIT community to login to participating MIT and federated websites.  Based on Internet2's Shibboleth System, the service allows MIT users to authenticate to protected websites, both on- and off-campus, and enables non-MIT users to register Collaboration accounts, if necessary, or use their accounts at an InCommon Federation participant, to access some protected MIT sites.


People with an MIT Kerberos account can use either their username/password or MIT X.509 certificate to authenticate securely to any MIT Touchstone-enabled application as well as a growing number of off-campus applications.

People that do not have an MIT Kerberos account can also authenticate to some MIT Touchstone-enabled applications by self-registering for a Collaboration Account; alternately, a user having an account with another university (or other organization) that is a member of the InCommon Federation may be able to authenticate using that account.

In all cases, when using a Touchstone-enabled application, your password will never be passed to the application server.

Since many MIT Touchstone-enabled applications support users with a Collaboration Account or an account with an InCommon Federation member, as well users with MIT Kerberos accounts, users may also be redirected to a page that allows them to select which account provider they will use to authenticate. Once familiar with this process, users can save the choice as a user preference.

Obtaining an account

MIT students, staff, and faculty members should not need to obtain a new account. Instead, use your existing MIT Kerberos username/password or MIT X.509 certificate.

  • New MIT students, staff, faculty, and affiliates should get a Kerberos (Athena) Account. It is required for systems that expect a direct MIT association in order to grant authorizations.
  • Other people, i.e. who are not MIT students, staff, faculty, or eligible affiliates, may be able to use an account with another member of the InCommon Federation to access some MIT Touchstone-enabled applications; otherwise, they can register for a Collaboration Account to access some applications.  Check with the application's support resources for information on which type accounts it will support for non-MIT users.

Using MIT Touchstone

Default browser settings should not prevent anyone from using MIT Touchstone for authentication. However, there are various optional settings that can affect the usability of Touchstone and Shibboleth:

Shibboleth, and hence MIT Touchstone, requires the use of browser cookies. If cookies have been disabled in the browser an error will result when attempting to use MIT Touchstone-enabled applications. To re-enable cookies within your browser, consult your browser's documentation.

Although MIT Touchstone uses Javascript and assumes it is enabled, it is still possible to authenticate if it is not. Instead of being automatically redirected back to the application that you are trying to access, you will have to click a button to complete a form post. (Some Touchstone-enabled applications may have their own requirements for Javascript in order for the application to work properly).

Changing your default account provider selection
Most MIT Touchstone-enabled applications support authentications from more than one account provider, or identity provider, e.g., an application might accept users authenticating with an MIT account, a Collaboration Account, or a Stanford University account.

Because of this added complexity, users must select which account provider they will be using to authenticate. The MIT server that prompts users to select their account provider also allows users to save the choice as a default preference within their browser, via a cookie, for the duration of the browser session or beyond.  A user who saves this preference will no longer be prompted by this server during the lifetime of the cookie (currently several months for the persistent cookie).

Since, in this case, a user will not have an opportunity to select an account provider when authenticating to the Touchstone-enabled application, we provide a way for users to remove or modify the saved account provider preference (without having to delete the appropriate cookie from the browser), i.e. by visiting A user who removes the preference in this way should be prompted again to select an account provider when subsequently authenticating to the application.

Note: There are some MIT applications that only support users with MIT Kerberos accounts, and so bypass prompting for the account provider.  Changing the settings via will have no effect on these applications.

Setting your default authentication mechanism selection (MIT users)
Typically, for the initial authentication in a browser session, users with an MIT Kerberos account will land at a login page offering three possible authentication mechanisms, i.e. their MIT X.509 certificate, Kerberos username and password, or existing Kerberos tickets.  Users with an MIT X.509 certificate in their browser can set a preference to authenticate with the certificate automatically, thus bypassing the login page; this preference setting will persist across browser sessions.  People using the Athena or managed desktop systems might choose instead to use their existing Kerberos tickets to authenticate automatically.  We also provide a separate page where users can test and reset their preferred authentication mechanism.  Note that some applications may require the use of a particular authentication mechanism, such as username and password.


The most effective and secure way to log out of a Touchstone enabled application is to close the browser.

Some applications also provide a local logout capability. However, since MIT Touchstone provides a single sign-on capability across enabled applications, and does not currently support any global logout capability, the user is generally not logged out in a way that would prevent someone from clicking on the login button once again, and gaining access to a protected resource anyway.  In short: The most effective and secure way to log out of a Touchstone enabled application is to close the browser.

Looping, or being stuck at the Redirect page
Occasionally, a browser gets stuck at the "Redirecting to requested site" page, or the page is continuously redisplayed. This kind of looping is almost always caused by a misconfiguration on the application web server.  For example, if the web application server is configured to protect a resource accessible via http, but the browser is told to send the cookie containing authenticated session information via https only, then any attempt to access the resource via http will result in a loop.

To troubleshoot this, you can try to access the resource using https instead of http. If that resolves the problem, contact the Service Desk or the team that is responsible for the application so they can fix the configuration (usually by configuring the web server to redirect any attempted access to a protected resource via http to use https instead; Shibboleth provides a redirectToSSL setting for this purpose).  Alternately, provide the information to contact touchstone-support. We will relay the information to the application maintainers.

If using https does not resolve the problem, contact touchstone-support and remember to include the URL that you were first attempting to access when you encountered the problem.

Helpful links