The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

InCommon Federated Error Handling Service

The goal of Federated Error Handling is to provide a better user experience in those situations where an IdP provides an SP with insufficient information (attributes) to make an access control decision. Federated Error Handling makes use of the Error Handling URL in IdP metadata.

The InCommon Federation operates a centralized Federated Error Handling Service that SPs can use to generate simple but effective error pages for the end user. This service is deployed on the same infrastructure that hosts InCommon metadata and the InCommon Discovery Service. All of these services are available 24x7 with manual failover to a redundant hot spare in the event of an outage.

Using the Service

The InCommon Federated Error Handling Service can be used by SPs in a couple of different ways. If the user arrives at the SP with insufficient attributes, the SP redirects the user to the Error Handling Service with the entity ID of the user's IdP such that:

  1. The service will display an SP-branded error page to the user, with a link to the public Error Handling URL for the given IdP.
  2. The service will determine the Error Handling URL for the given IdP and return it to the SP for further processing, so that the SP can roll its own error handler.

See examples of each case in the next section.

Requesting the Service

The URL prefix to the Error Handling Service is:

https://ds.incommon.org/FEH/sp-error.html...

The full URL includes a query string with syntax as follows:

Any given request must contain exactly one of the return or sp_entityID parameters in the query string. The idp_entityID parameter should be included as well, otherwise the result will be completely predictable (and not very useful).

Case 1. If both the sp_entityID and idp_entityID parameters are included in the query string, the Service constructs a simple SP-branded error page from user interface elements in SP metadata. A link to the IdP’s error handling URL is included in the body of the error page and the user is encouraged to visit this page at the IdP for further information about the error that just occurred.

Example 1: https://ds.incommon.org/FEH/sp-error.html?sp_entityID=https%3A%2F%2Fcilogon.org%2Fshibboleth&idp_entityID=urn%3Amace%3Aincommon%3Aosu.edu

Case 2. If both the return and idp_entityID parameters are included in the query string, the Service will determine the error handling URL (errorURL) of the given IdP and then redirect the client to the given return URL with the errorURL included in the query string. If the IdP has no errorURL in metadata, the client is simply redirected to the return URL without a query string.

Example 2: https://ds.incommon.org/FEH/sp-error.html?return=http%3A%2F%2Fincommon.org%2F%3Ffoo%3Dbar&idp_entityID=urn%3Amace%3Aincommon%3Aosu.edu

Visit the Federated Error Handling (FEH) Service home page to determine test URLs for arbitrary parameter values.

Service Integration

TBD

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels