Mapping section

All the <mapping> elements conform the mappings section. Each mapping element corresponds to the mapping of a XACML attribute being requested by the PDP to an underlying web service call. The mapping element consists of the following elements.

<xacmlAttribute>

This element contains the following attributes:

Attribute	Description	Mandatory
AttributeId	Represents the XACML identifier of the attribute. For example, pip.payload.	Yes
Category	Represents the category to which the XACML attribute belongs. For example, urn:oasis:names:tc:xacml:1.0:subject-category:access-subject.	Yes
DataType	Represents the data type of the XACML attribute. For example, http://www.w3.org/2001/XMLSchema#string.	Yes
Issuer	Represents the issuer of the attribute and is not typically used.	No

<contentType>

This element represents the content type of the message being sent in the case of a POST request and is optional. If the payload is JSON, then the value is application/json. If the payload is XML, then the value is text/xml. Check with the administrator of the target service for the correct value (if any).

<template>

This element can be a path to a resource containing the message template payload or it can be the template payload itself. This element is optional. It is typically only used in an HTTP POST message. The template element contains two XML attributes:

• payload: this XML attribute is a Boolean. By default it is false. If it is false, in the case of an HTTP POST request, the payload will be read from the file located using the value of template. If it is true, the actual value of the template element is considered to be the payload itself. The value may be escaped XML using <![CDATA[ *the value goes here* ]]>. More details on CDATA can be found hereOpens in a new tab. The payload and template mechanism is further described here.
• classpath: this XML attribute is a Boolean. By default it is true. If classpath is true and template points to a location, then the path is treated as a path to a resource on the classpath. For instance /example.json would point to a file stored either at the root of a jar file or in the web application’s /classes folder. If classpath is set to false, then the HTTP Attribute Connector looks in the filesystem for the file.

Using a template

In addition to setting a URL and HTTP headers, the HTTP client may also need a payload which can be read from a file on the filesystem, a resource on the classpath, or from the configuration itself. A payload is typically used in HTTP POST requests.

Sample Payload

The template referred to in section Sample Configuration could contain a sample JSON payload such as the one below (illustration only):

{
    "authorization": {
        "status": "Active",
        "subject": {
            "identifier": {
                "type": "@var1",
                "valueRoot": "acme"
            }
        },
        "target": {
            "identifier": {
                "type": "ACME",
                "valueRoot": @var2
            }
        },
        "authorizationType": {
            "value": @var2,
            "event": @var3{
                "type: "Create",
                "Preferences": [{
                    "type": "Permission",
                    "value": "ReadWrite"
                }]
            }
        }
    }
}

Using variable placeholders

The sample template contains special placeholders such as @var1, @var2, and @var3. The Rythm EngineOpens in a new tab will look for and substitute these placeholders with the values of the key attributes defined in the HTTP Attribute Finder’s configuration.

The variables can have any name. They must always be preceded with the @ sign. They may be reused. Note that variable names cannot contain periods (.).

<key>

A sequence of key elements. Each key represents a XACML attribute which is required in order to complete the template and send a request to the web service. The key element contains a <xacmlAttribute> element as previously described.