Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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. The best link to it for the moment is to the old docs because the V3+ language has significantly drifted.

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

Not a lot, this continues to point back to the old V2 IdP software docs for the moment. The main point of divergence with the V3 IdP is the collapsing of namespaces and shortening of some of the function plugin names, which was not backported to the SP.

Reference

This page refers to several different namespaces by convention as detailed below:

Namespace

URI

Description

afp

urn:mace:shibboleth:2.0:afp

The Shibboleth attribute filter rules namespace
basic

urn:mace:shibboleth:2.0:afp:mf:basic

The "basic" Shibboleth attribute filter rules namespace
samlurn:mace:shibboleth:2.0:afp:mf:samlThe "SAML" attribute filter rules namespace
conf
urn:mace:shibboleth:3.0:native:sp:configThe Shibboleth SP configuration namespace

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.

NameCardinalityDescription
<afp:AttributeFilterPolicyGroup>1Root 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

<TrustEngine

0 or 1

Used to require the presence of a top-level signature over the entire resource and to control the verification process

<CredentialResolver>

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 <TrustEngine> element and the certificate attribute.

<TransportOption>

0 or more

Provides low-level control over the library used to remotely access the resource

Examples

Inline Attribute Filter
<config:AttributeFilter type="XML">
	<afp:AttributeFilterPolicyGroup>

	<!-- Shared rule for affiliation values. -->
	    <afp:PermitValueRule id="eduPersonAffiliationValues" xsi:type="OR">
    	    <basic:Rule xsi:type="basic:AttributeValueString" value="faculty"/>
        	<basic:Rule xsi:type="basic:AttributeValueString" value="student"/>
	        <basic:Rule xsi:type="basic:AttributeValueString" value="staff"/>
    	    <basic:Rule xsi:type="basic:AttributeValueString" value="alum"/>
        	<basic:Rule xsi:type="basic:AttributeValueString" value="member"/>
	        <basic:Rule xsi:type="basic:AttributeValueString" value="affiliate"/>
    	    <basic:Rule xsi:type="basic:AttributeValueString" value="employee"/>
        	<basic:Rule xsi:type="basic:AttributeValueString" value="library-walk-in"/>
	    </afp:PermitValueRule>
	<afp:AttributeFilterPolicyGroup>
<config:AttributeFilter type="XML">
External Attribute filter
<AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>

The best example to this point is the file shipped with the software.

  • No labels