Mapping section

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

xacmlAttribute

The <xacmlAttribute> element can have 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

The optional <contentType> element specifies the content type of the message being sent, specifically for POST requests.

• When sending a JSON payload, use the value application/json.
• When sending an XML payload, use the value text/xml.

If unsure about the correct content type, consult the administrator of the target service.

template

The optional <template> element allows you to specify either the path to a resource containing the message template payload or the template payload itself. It's primarily used for HTTP POST messages and has two XML attributes:

• payload

  This boolean attribute defaults to false and the payload for an HTTP POST request is read from the file specified by the <template> value. If set to true, the <template> element itself contains the payload.

  tip

  You can escape XML within the payload 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 in the Using a template section.

• classpath

  This boolean attribute defaults to true. If set to true and <template> points to a location, the path is considered to be a resource on the classpath. For example, /example.json would point to a file located at the root of a JAR file or in the web application's /classes folder. When classpath is false, the HTTP Attribute Connector searches for the file in the filesystem.

Using a template

Aside from configuring the URL and HTTP headers, the HTTP client might also require a payload. This payload can be sourced from several places: a file on the filesystem, a resource located on the classpath, or even directly from the configuration. Notably, payloads are commonly used in HTTP POST requests.

Sample payload

The referred template in section Sample configuration could contain a sample JSON payload such as the one below:

{
    "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 Connector’s configuration.

The variables can have any name, must always be preceded with the @ sign, and they may be reused.

Important

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 an <xacmlAttribute> element as previously described.