The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.
ResponseMapping
The <ResponseMapping>
 element provides an instance of the HTTPResponseMappingStrategy interface that produces result attributes from a web service response, in real time, using a script. The supplied script is expected to consume the HttpResponse instance and produce any desired results. It may raise exceptions if necessary.
For simple use cases, the HttpClientSupport class includes a number of toString
 methods that can translate the entire response into a string using appropriate character set handling and while enforcing size limits. This supports chunked responses for which the server doesn't know the actual size ahead of time, which is common with web services.
In addition, note that Javascript interpreters include a JSON
 object that automates the parsing of JSON data.
Schema Name and Location
The <ResponseMapping>
 element is a configuration element of type ScriptType
. Both the element and its type are defined in the urn:mace:shibboleth:2.0:resolver
 namespace, the schema for which is located at http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd.
The following sections describe the attributes and elements of the ScriptType
 type.
An element of type Name Type Default Description If the An element of type The script may be stored in a local file (with Always wrap inline scripts with a CDATA section Always wrap inline scripts with a CDATA section, even if the script contains no special XML characters. This will future-proof your script.Attributes
ScriptType
has the following XML attributes:Use language
string optional "javascript"
Defines the JSR-223 language to use. The default is ECMAScript using either the Rhino (Java 7) or Nashorn (Java 8) engines. customObjectRef
3.2string optional The ID of a Spring bean defined elsewhere in the configuration. customObjectRef
attribute is present, the result of the referenced Spring bean is made available to the script in a variable named custom
. This is in addition to the normal script context discussed below.Child Elements
ScriptType
has the following child elements:Name Cardinality Description <Script>
Exactly OneAn inline script <ScriptFile>
Path to a local file or classpath resource containing the script <ScriptFile>
) or written inline (with <Script>
). An inline script should be wrapped with a CDATA section to prevent interpretation of any special XML characters that may be included in the script.
Script Context
As enumerated below, several variables are available in the template context.
Name | Description |
---|---|
| Instance of HttpResponse to process |
| A class logger for debugging |
custom | Custom object supplied via customObjectRef configuration attribute, if any |
connectorResults | Pre-defined Set<IdPAttribute> variable to populate with output results |
Unlike a lot of the scripted versions of objects across the system, there is no direct access to the ProfileRequestContext tree that exposes the state of the request. However, it's easy to get access to it by using a servlet request attribute named "opensamlProfileRequestContext". You can inject the servlet request object through the customObjectRef
 hook (set it to "shibboleth.HttpServletRequest").
Example
The example illustrates a JSON-based web service. Some of the error handling in the JSON structure is elided, but it illustrates that the response data can be trivially turned into native Javascript objects with a couple of lines of code, and the rest is mechanical.