|
MIT Touchstone FAQ On this page: Answers: General | Using Touchstone | Accounts: MIT versus Collaboration Account | Developer Support | System Integrator questions about Shibboleth | Attribute release policies and privacy Questions: These are some commonly asked questions regarding MIT Touchstone. If you don't find what you need on this page, IS&T maintains an online database called Stock Answers. General
Using Touchstone
[Back to top] Accounts: MIT versus Collaboration Account
[Back to top] Developer Support
[Back to top] System Integrator questions about Shibboleth
[Back to top] Attribute release policies and privacy
[Back to top] Answers: General
- What is MIT Touchstone?
MIT Touchstone is a new suite of technologies for authenticating a variety of web applications, being introduced by IS&T. It is focused on supporting web applications. It is not suitable for authenticating native desktop applications.
- Do I need MIT Touchstone?
MIT Touchstone and Shibboleth is of interest if you're supporting a web application on an Apache, Microsoft IIS, or Netscape/iPlanet/Sun web server that needs to authenticate its users, especially if the population is drawn from not only the faculty, staff, or students of MIT, but also other educational institutions in the InCommon federation and other users that do not already have an MIT Kerberos account. MIT Touchstone will enable users to login with their MIT Kerberos account or other account, but avoids the need for your application to validate or manage passwords. Various kinds of attribute information about users can also be provided to your application for personalization or, in some limited cases, authorization.
- 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 being prompted for additional authentication information.
- Why has IS&T introduced 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 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 whether an MIT user, or a user from another 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 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.
- 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 users outside of the traditional MIT community. The system uses HTTP redirection extensively, and uses other standard web technologies such as SSL. The primary login server is using Stanford's WebAuth package for initial authentication. The login server will initially support three authentication mechanisms -- 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 required software is available for Apache and IIS web servers; in the future we may also support web 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 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.
- What applications support MIT Touchstone?
A list of applications that support MIT Touchstone can be found here.
[Back to top] Using Touchstone
- Does MIT Touchstone or Shibboleth provide authentication for native client applications?
No. MIT Touchstone and Shibboleth are designed to support web applications and use from a browser.
- Can I use MIT Touchstone or Shibboleth to secure SOAP based web services?
No, not at this time. Shibboleth and MIT Touchstone are intended for use from within a web browser.
- What browsers are supported by MIT Touchstone / Shibboleth?
We're not currently aware of any browsers that do not work with Shibboleth or MIT Touchstone. Functional testing has been performed using IE6, IE7, Safari on Mac OSX, Firefox 2.x and 3.x on Linux and Windows. Some mobile browsers have been tested as well. If you are aware of a browser that does not work well with Shibboleth or the MIT Touchstone login pages please contact the MIT computing help desk.
- Does MIT Touchstone or Shibboleth use cookies?
Yes, you must have cookies enabled on your browser in order to use Shibboleth and MIT Touchstone. There are multiple cookies stored for multiple domains. One cookie will identify the login site of your IdP. The cookie stores a session ID that is needed to know whether you are already authenticated or not. This cookie is required. This is a session cookie. Another cookie will identify the web server hosting the resource you want to access. This cookie stores a session ID and potentially the URL that you requested before being authenticated. This cookie is required. This is a session cookie. Depending on options that you have chosen, some persistent cookies may be stored. For example, if you have selected the option to always use existing Kerberos tickets to login, or if you have selected the option to always use certificates to login. The WAYF server may also store a persistent cookie so that you will not always have to reselect which IdP to use.
- Is it possible to configure Shibboleth in such a way that it writes the cookies as URL parameters?
No. At this time (October 2008) Internet 2 has not indicated that they are interested in supporting this feature in Shibboleth.
- Does MIT Touchstone or Shibboleth require Javascript?
Although MIT Touchstone assumes Javascript is enabled, and uses it, it is still possible to authenticate if you do not have Javascript enabled. Instead of being automatically redirected back to the application that you are trying to access, you will have to use a button to complete a form post. Note that some applications that use MIT Touchstone or Shibboleth for authentication may have their own internal requirements that require Javascript in order for the application to work.
- Can I use WGET to access a web page protected by Shibboleth or MIT Touchstone?
It should be possible to use WGET to access Shibboleth or MIT Touchstone protected pages. However, at this time we do not have specific documentation of how you would do this. More information on using wget can be found here.
- How do I configure my browser to use Kerberos tickets to authenticate to MIT Touchstone?
FireFox, IE, and Safari each offer some support for using existing Kerberos tickets to authentication to the login server used by the MIT user community. FireFox and IE each require the user to perform some browser configuration to enable the use of Kerberos authentication.
- What about privacy?
Shibboleth software was designed with privacy in mind. Please see the section on "Attribute release policies and privacy" for more details.
[Back to top] Accounts: MIT versus Collaboration Account
- What is an identity provider?
An 'Identity Provider' (sometimes abbreviated 'IdP') is a service hosted by an organization which publishes electronic identity information for users that have an account, or some relationship, with the organization. An 'Identity Provider' acts as a trusted third party when a user attempts to access an application. The application can communicate with the IdP to determine if the user is authenticated and potentially obtain further information about the user. As part of MIT Touchstone, MIT operates two IdPs. One of the IdPs serves all of the people that have an MIT Kerberos username. The other IdP serves people that have a Collaboration Account, hosted by TouchstoneNetwork.net.
- What is a WAYF?
WAYF stands for "Where Are You From". When an application is willing to communicate multiple identity providers, or a federation of identity providers, it needs to determine which IdP should be used for a specific user. The WAYF provides this ability, typically by asking the user to indicate which organization has his or her account information. MIT Touchstone operates one WAYF. Using that WAYF people may select the MIT IdP, the TouchstoneNetwork IdP, or they may select a third choice which will bring them to the WAYF operated by the InCommon Federation.
- What is federated identity and federated authentication?
Identity Federation provides users access to applications across the Internet without the need for multiple login credentials or accounts. Federated authentication allows organizations to share credentials and attributes for authentication and authorization, reducing the need to maintain user profiles in multiple systems.
- How do I know if I have an MIT account?
The term "MIT account" means that you have an MIT Kerberos account. If you are a registered student, or a full time employee, you have an MIT account. Many other people also have an MIT account. On prerequisite for having an MIT account is to have an MIT ID number. An MIT account comes with some default entitlements. It means that you also have an MIT email address. It means that you can obtain an MIT X.509 certificate. It means that you have some file system quota assigned to you.
- How do I obtain an MIT account?
If you are a registered student, or a full time employee, you have an MIT account or are eligible to register for one if you have not already done so. Any MIT faculty or staff member can sponsor MIT guest accounts.
- What is a Collaboration Account?
A Collaboration Account is not a traditional MIT account. MIT Touchstone created a new accounts management system in order to support people that are not part of the traditional MIT user community, and do not have an account with a member of the InCommon Federation. For lack of a better term we call these accounts Collaboration Accounts. The Collaboration Accounts management system allows nearly anyone in the world to self-register for an account at any time. A Collaboration Account does not grant the user an MIT email address. It does not grant the user any file system quota. It does not grant the user any default entitlements. However, web applications that are Touchstone enabled, may support authentication by people that have a Collaboration Account.
- What is CAMS?
CAMS stands for Collaboration Accounts Management System. It is one of services that makes up MIT Touchstone. If an MIT web application needs to support users that do not have an MIT Kerberos account, then the application should be configured to enable users with Collaboration Accounts to authenticate to it.
- How do I obtain a Collaboration Account?
You can register for a Collaboration Account here. Please note that MIT email address cannot typically be used to register for a Collaboration Account.
- How do I edit my Collaboration Account profile and manage my account?
You can edit your Collaboration Account profile, change your name, manage your account or delete your account here. Please note that MIT email address cannot typically be used to register for a Collaboration Account.
- Can I create Collaboration Accounts for others?
Most users do not have this ability. However, if you have a business need, this privilege and responsibility can be granted to you. The system also has support for creating accounts in batches. Email will be sent to each one of the external users telling them how to complete the account registration process.
- What is InCommon or the InCommon Federation?
InCommon's goal is to eliminate the need for researchers, students, and educators to maintain multiple passwords and usernames. Online service providers no longer need to maintain user accounts. Identity providers manage the levels of their users' privacy and information exchange. InCommon uses SAML-based authentication and authorization systems (such as Shibboleth®) to enable scalable, trusted collaborations among its community of participants. The mission of the InCommon Federation is to create and support a common framework for trustworthy shared management of access to on-line resources in support of education and research in the United States. To achieve its mission, InCommon will facilitate development of a community-based common trust fabric sufficient to enable participants to make appropriate decisions about access control information provided to them by other participants. InCommon is intended to enable production-level end-user access to a wide variety of protected resources. InCommon uses standards-based, SAML-compliant Shibboleth® as its federating system.
- Can an MIT email address be used to register a Collaboration Account?
Email addresses ending in "@mit.edu" cannot be used to register for a Collaboration Account. Users with these accounts can instead authenticate using the normal MIT Identity Provider (idp.mit.edu). MIT departmental address, e.g. "@example.mit.edu", can be used to register for a Collaboration Account. However, users are discouraged from doing so. The registration process will warn the user that they should probably use the normal MIT Identity Provider. Please note that Collaboration Accounts are likely to have less privileged access to many applications, and access to fewer applications in general.
- I have an account with an InCommon participant, can I still register for a Collaboration Account?
Yes. However, the registration process will normally warn you that you may not need a Collaboration Account and that your account from another InCommon Federation participant may meet your needs just as well.
- Can I use OpenID to authenticate to MIT Touchstone enabled applications?
In many cases yet, but there are several caveats. First, Touchstone enabled applications don't use OpenID natively. Instead they use Shibboleth as the native authentication mechanism. The Collaboration Accounts management system will let registered users associate an OpenID identifier with their Collaboration Account. Once a user has associated an OpenID identifier with their Collboration Account, then they can use OpenID to authenticate to the IdP at idp.touchstonenetwork.net. That IdP is normally accessed by selecting "b. Touchstone Collaboration Account" choice at the WAYF server. Not all OpenID providers are usable at this time. At the moment the system does not fully support the OpenID 2.0 specification. This means that OpenID's from Yahoo.com are not registerable or usable at this time. If we become aware of other OpenID domains that do not work, we will normally configure the accounts management system to issue a warning if you try to register an OpenID from one of the "problem" domains.
[Back to top] Developer Support
- If I am a developer interested in enabling an application, do I need to know about all of the MIT Touchstone technologies? Or do I just need to know about Shibboleth?
Most of the technologies and systems that are implemented and used by MIT Touchstone are abstracted away from the individual web application developer or system administrator. However, Shibboleth must be used by individual web applications. Developers, system integrators, and system administrators responsible for web applications should become familiar with Shibboleth.
- How can I get some help getting started?
Send mail to touchstone-support. This will create an MIT Request Tracker case with the group that is currently supporting MIT Touchstone.
- What platforms and environments are supported?
MIT is currently supporting Shibboleth 1.3. Shibboleth 2.1 is the latest officially supported SP release. We will soon be working with selected customers on Shibboleth 2.1. Both releases are supported for use with Apache, IIS, and Sun/iPlanet/Netscape web servers, and its range of officially supported platforms includes Windows NT4/2000/XP/2003/2008, Solaris, Mac OS X, and various flavors of Red Hat Linux. Other Unix platforms that support the GNU C/C++ compiler collection may also work, but are not supported officially.
- Do I need to register or sign up with IS&T to have my application use Shibboleth or MIT Touchstone?
Yes and no. It's possible to only consume the authentication messages produced by Shibboleth, but a very minimal set of information about the user will be available to your application, generally only the eduPersonScopedAffiliation attribute, and not including any unique or personally-identifying information. In other words, without registration, you'll know that some user has authenticated, but you won't know who that user is. This protects user privacy by insuring that only services that are known and authorized to receive personal information can do so. To receive additional information, applications must be registered with IS&T so that the IdP will know what information to release to the application. A server certificate is also needed to authenticate the application to the IdP. If you're interested in registering your services, you will be asked to describe your application(s) and how you intend to handle and protect the personal information you receive. The process is outlined here.
[Back to top] System Integrator questions about Shibboleth
- How long do user sessions last and is there an inactivity timeout?
The Shibboleth software allows you to control the time elapsed before sessions with your applications expire. A timeout based on inactivity with your applications can also be enforced. However, this is distinct from the lifetime of the overall session that enables single sign-on, and in most cases using a local timeout that is shorter than the overall period is not useful. The overall session lifetime enforced by the MIT identity provider is ten (10) hours. Other identity providers will likely have different policies.
- Does Shibboleth support logout?
No, not at this time. It will likely be supported in a future release in a best effort fashion, but it should not be relied upon. Instead users should logout of their desktop or at least exit the browser in order to logout. This is the same as we currently recommend for users of personal X.509 certificates.
- Can Shibboleth be set up without a WAYF?
Yes. This is reasonable if your application will only support one user community, or one identity provider. However, we recommend that strongly consider supporting a wider user community if it makes any sense for your application or business function. It is also possible to set up your application without using a WAYF even if you are supporting the use of more than one identity provider. Sometimes an application wants to tightly control its own look and feel. In such cases the application can function as if it were its own WAYF. Although this is possible we generally recommend that systems use the WAYF. We feel that consistency in appearence, across multiple applications, for this aspect of authentication is desirable.
[Back to top] Attribute release policies and privacy
- What is an attribute release policy?
- Can a user restrict what information about them gets released?
- What attributes do you release about MIT users?
- What attributes do you release about people with Collaboration Accounts?
[Back to top] |
| |
|
JavaScript use in the macro is restricted by your Confluence administrator at Macro Security hence it has been removed from the page. Please see your Confluence administrator for additional details.
About IS&T
