Overview
Identified by type="XML", this AttributeFilter implements an XML-based rule syntax for filtering attributes that was forked off from the original filtering language that was designed for the Identity Provider software.
As of V3.1, a serious attempt has been made to rationalize the language to better align to what is currently supported by the V4 IdP. Further details on the differences are outlined below.
This filter's configuration is implemented as a reloadable XML resource, which means that the XML content can be supplied inline, in a local file, or a remote file, and can be monitored for changes and reloaded on the fly. The root of the XML in any of those cases MUST be an <afp:AttributeFilterPolicyGroup> element, either as a child element in an existing file or the root of a different file (usually the latter).
General Configuration
The language in SP V3.0 (and prior) was generally similar to that of the V2 Identity Provider. V3.1 has been updated with changes that bring the language largely into alignment with the V4 IdP, including the deprecation (and eventual elimination) of the additional "basic" and "saml" namespaces, the shortening of many plugin names, and some additional (though generally minor) functionality.
The match is not exact because not every IdP feature can be supported in the SP and there are features needed in the SP that aren't relevant to the IdP.
As of V3.1, only the "top-level" namespace, "urn:mace:shibboleth:2.0:afp" is needed in policies, and warnings are logged when the other two namespaces are encountered.
Supported Plugin Types
The following IdP policy and attribute rule function types are supported. Unless otherwise noted, the syntax should be assumed to be identical to the IdP version.
| Type | Additonal Notes |
|---|---|
ANY | |
AND | |
OR | |
NOT | |
Requester | |
Issuer | |
Value | |
Scope | |
RequesterRegex | |
IssuerRegex | |
ValueRegex | |
ScopeRegex | |
NumberOfAttributeValues | |
EntityAttributeExactMatch | Implemented, but unusable due to lack of metadata supplied for the requester (the SP) |
EntityAttributeRegexMatch | Implemented, but unusable due to lack of metadata supplied for the requester (the SP) |
IssuerEntityAttributeExactMatch | |
IssuerEntityAttributeRegexMatch | |
NameIDFormatExactMatch | Implemented, but unusable due to lack of metadata supplied for the requester (the SP) |
IssuerNameIDFormatExactMatch | Not yet supported by the IdP, but the syntax is identical to the requester variant above |
InEntityGroup | Implemented, but unusable due to lack of metadata supplied for the requester (the SP) |
IssuerInEntityGroup | |
RegistrationAuthority | Implemented, but unusable due to lack of metadata supplied for the requester (the SP) |
IssuerRegistrationAuthority | |
ScopeMatchesShibMDScope | |
ValueMatchesShibMDScope |
The following additional types are also supported:
NameIDQualifierString
Enforces the content of NameQualifier and SPNameQualifier attributes in decoded <NameID>-valued attributes. It supports the following XML attributes for configuration:
| Name | Type | Default | Description |
|---|---|---|---|
attributeID | String | If set, indirects the function evaluation through another attribute. | |
NameQualifier | String | Attribute issuer | Overrides the qualifier to require/check for |
SPNameQualifier | String | Attribute requester | Overrides the qualifier to require/check for |
Rule Referencing
One feature maintained in the SP that was not supported by the IdP is rule referencing. The <afp:PolicyRequirementRule>, <afp:PermitValueRule>, and <afp:DenyValueRule> elements can appear alone, with an id attribute. In turn, anywhere these elements would be used within an <afp:AttributeFilterPolicy> or <afp:AttributeRule>, the previously defined rules can be referenced via <afp:PolicyRequirementRuleReference>, <afp:PermitValueRuleReference>, <afp:DenyValueRuleReference>, and <afp:RuleReference> elements.
The default policy distributed with the software includes an example of this approach.
Wildcarding
Another SP-only feature is wildcarding. The SP does not require that a rule be defined for every possible attribute mapped since a lot of attributes would simply be passed through to applications unfiltered and the mapping capability itself can be used to ignore unwanted inputs. As a result, an <afp:AttributeRule> can contain an attributeID set to "*" in order to auto-apply the contained rule to every attribute not otherwise identified by a dedicated rule.
Reference
Attributes
Aside from the type="XML" attribute itself, there is no other attribute content specific to this plugin type.
It supports all of the attributes common to all reloadable configuration resources:
Names | Type | Default | Description |
|---|---|---|---|
id | string |
| Identifies the component for logging purposes. |
url | URL |
| Remote location of an XML resource containing the required configuration. The SP does not verify the transport (i.e. it does not verify the X.509 certificate presented by the remote server when HTTPS is the transport). |
path | local path |
| Path to a local file containing the required configuration |
validate | boolean | false | If true, XML validation is performed when loading the resource |
reloadChanges | boolean | true | If a path attribute is used, the local file is monitored for changes and reloaded dynamically. This incurs some runtime overhead for locking, so should be disabled if not needed. |
maxRefreshDelay | time in seconds | 0 | If a url attribute is used, this attribute sets the time between attempts to download a fresh copy of the resource. If 0 (the default), no reloading occurs. This incurs some runtime overhead for locking, so should be left at 0 if not needed |
reloadInterval |
|
| Synonym for maxRefreshDelay |
backingFilePath | local path |
| If a url attribute is used, the downloaded resource is copied to this location. If the software is started and the remote resource is unavailable or invalid, the backing file is loaded instead |
certificate | local path |
| Path to a certificate containing a public key to use to require and verify an XML signature over the resource. The certificate's other content is ignored. |
signerName | string |
| If present, the name is supplied to the <TrustEngine> used to verify an XML signature over the resource. A certificate containing the name must be available in the verification process (typically inside the signature). |
Child Elements
The following child element must be provided, either inline, or as the root element of a local or remote XML resource to load from, which would be specified via the attribute(s) above.
| Name | Cardinality | Description |
|---|---|---|
<afp:AttributeFilterPolicyGroup> | 1 | Root element of configuration |
When a non-inline configuration is used, it supports the following child elements common to all reloadable configuration resources.
These child elements are typically only used when relying on a remote configuration resource and are for advanced use cases.
Name | Cardinality | Description | |
|---|---|---|---|
0 or 1 | Used to require the presence of a top-level signature over the entire resource and to control the verification process | ||
0 or 1 | Used to require the presence of a top-level signature over the entire resource and to control the verification process. Mutually exclusive with the | ||
0 or more | Provides low-level control over the library used to remotely access the resource | ||