Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Before accepting and using a new attribute for access control purposes, ensure that you're fully aware of the definition and population of the attribute. This should be supplied either by your federation or the ! IdP with which you're interoperating. Ensure that good naming practices are followed.

...

The only change that must be performed is to add the attribute to AAP.xml. This is done by editing the file and adding a section such as the following:

Code Block
xml
xml
&lt;AttributeRule<AttributeRule Name=&quot;"https://www.example.org/sports/battingaverage&quot;" Header=&quot;"Shib-BattingAverage&quot;" Alias=&quot;BattingAverage&quot;&gt;
	 &lt;AnySite&gt;
		  &lt;AnyValue/&gt;
	 &lt;/AnySite&gt;
&lt;/AttributeRule&gt;"BattingAverage">
	<AnySite>
		<AnyValue/>
	</AnySite>
</AttributeRule>

This will accept any attribute value from any trusted ! IdP. The parameters for your situation should be informed by local policy needs, such as a controlled vocabulary or a limited number of trusted asserters.

...

If you wish to ensure that this attribute is considered required for a given application or for your SP in general, information needs to be added to shibboleth.xml or metadata.xml. One or more <saml:AttributeDesignator> attributes may be added to an <Application> element using the SAML attribute names to restrict the attributes available to it, while one or more <RequestedAttribute> elements in your metadata will express your desire for this data.%COMMENT%