An AAP is a policy defining rules for the processing of SAML attributes by a ServiceProvider. These rules include:


The ShibOnedotThree ServiceProvider includes a backward-compatible, but revamped system for AAP processing. Roughly the same system should be included in the Java ServiceProvider. New features include:


The <AnyAttribute> wildcard is a signal in a policy file to bypass any filtering at all, and only use the AAP mechanism to configure header export and alias rules. This enables filtering rules to be supplied in one file, but specific export rules to be supplied in a second file. Without this signal, processing proceeds as follows for each SAML attribute received:

Each policy is examined for a matching <AttributeRule> and if none are found, then the attribute is ignored (accepted) for the purposes of that policy. If more than one policy contains a matching rule, then all are applied conjunctively (a value must be acceptable to all policies for it to pass through unmolested). At the end of the process, if no policy contains a rule for a particular attribute, it is rejected/deleted.

In each matching <AttributeRule> rule, an empty rule means to accept any values. Otherwise, the <AnySite> and any matching <SiteRule> elements are evaluated. Matching is based on the entityID of the IdentityProvider but also on any containing named <EntitiesDescriptor> elements. Rules are evaluated in sequence from most specific to least specific match.


The Shibboleth implementation includes support for so-called scoped attributes, which are relations between a value and a scope or context for the value. This enables the scope to be processed separately from the value instead of treating both as a combined string to be filtered.

Scope filtering happens along with, but distinctly from, value filtering rules. Within a given policy, scope filtering runs whenever a matching <AttributeRule> contains a Scoped XML attribute set to true . This means that a single policy indicating an attribute is scoped will ensure that (in SAML 1.x assertions) each <saml:AttributeValue> contains a Scope XML attribute, preventing any attempts by an IdentityProvider to subvert the rules. Even if SP-specific policies were to omit the flag, a single federation-supplied "definition" file is enough to get the basics correct. The specifics of this will change for SAML 2.0 assertions, but the rules will still be enforced properly.

Any time scope filtering is in effect for an <AttributeRule> , the default rule in effect is that any scope is illegal. The rule then denies or accepts specific scopes for specific IdentityProviders. The <AnySite> and any matching <SiteRule> elements are examined for scope rules. As above, matching is based on the entityID of the IdentityProvider and any containing named <EntitiesDescriptor> elements, and rules are evaluated most-specific to least-specific.

Finally, any <shibmd:Scope> extension elements in MetaData take effect (these are always used to indicate acceptance).


Accept eduPersonPrincipalName in scope .

<AttributeRule Name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
		 <Scope Accept="true"></Scope>