...
IS&T is currently supporting customers intending to use Shibboleth 1.3x or 2.x. We recommend that new installations use Shibboleth 2.x based SPs.
*As of June 30, 2010, the Internet2 Shibboleth development team will no longer promise to supply security updates for version 1.3x. *
We strongly recommend that sites currently running Shibboleth 1.3 in production plan to upgrade to the current version of Shibboleth well in advance of the announced end-of-life date. This will protect against the possibility of a forced but unplanned migration from 1.3 should a security issue or incompatibility be discovered after the end-of-life date has been reached.
...
- session displayed if a session cannot be created after successful authentication, for example if shibd is not running. In a standard configuration, you can force this page to be displayed by visiting the server's /Shibboleth.sso location, e.g.: *https://mv-ezproxy-com.ezproxyberklee.flo.org/Shibboleth.sso*
- metadata displayed in certain cases where there is no valid metadata for an identity provider. This should not happen using our standard configuration; it should only be possible when using the Artifact profile, or "lazy sessions", and there is a configuration problem. You can force the page to be displayed by visiting: *https://mv-ezproxy-com.ezproxyberklee.flo.org/Shibboleth.sso?providerId=NoSuchIdP*
- rm displayed when an exception occurs when exporting assertions into request headers. This indicates a software problem, and should not happen.
- access displayed for access control failures. This should only happen if you have access control directives in the Apache configuration for your Shibboleth-protected content. You can force the page to be displayed by adding an access control directive that is certain to fail, for example "require NoSuchAlias" (remember to remove this configuration when you have completed testing).
- ssl displayed when a POST is attempted using http instead of https, and RedirectToSSL is in effect. This should not happen on a properly configured server.*Letting the IdP know about your application*Until the MIT Identity Providers know about your application, they won't release information about an authenticated user to your server. Each Touchstone enabled application running on a server needs to be registered with the IdPs.
...
We are intending to offer some hands on training during IAP 2009. Space will be limited to 18 participants. The hands-on lab is scheduled for January 20th, 1:30-3:30pm. There will also be session talking about configuration options on January 16th, from 2:30-4:00pm.
Who to Contact:
| Wiki Markup |
|---|
Web: [MIT |
Touchstone|http://mit.edu.ezproxyberklee.flo.org/touchstone] Email: [touchstone-support@mit.edu|mailto:touchstone-support@mit.edu]\[ |
mailto:touchstone-support@mit.edu\ ] |
