...
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.
| Table of Contents | ||
|---|---|---|
|
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).
...
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:
...
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.
...
It supports all of the attributes common to all reloadable configuration resources:
| Include Page | ||||
|---|---|---|---|---|
|
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 |
|---|---|---|
| 1 | Root element of configuration |
When a non-inline configuration is used, it supports the following child elements common to all reloadable configuration resources.
| Include Page | ||||
|---|---|---|---|---|
|