...
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 | ||||
---|---|---|---|---|
| ||||
<AttributeRule<AttributeRule Name=""https://www.example.org/sports/battingaverage"" Header=""Shib-BattingAverage"" Alias="BattingAverage"> <AnySite> <AnyValue/> </AnySite> </AttributeRule>"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%