Page History

...

For services not (yet) covered by any other methods (see above), enumerating entityIDs in the configuration allows to apply a set of common rules to a list of services sharing certain properties. Here's an example configuration releasing only basic attributes to selected services that will be useful to most institutions. The Service Providers' entityIDs (i.e., their globally unique names) are OR'ed together in the PolicyRequirementRule, meaning the policy will apply to any of the services listed, e.g.:

<AttributeFilterPolicy id="CollaborationAndNRENServices">
  <PolicyRequirementRule xsi:type="OR">
    <Rule xsi:type="Requester" value="https://www.aco.net/shibboleth" />
    <Rule xsi:type="Requester" value="https://eduroam.aco.net/shibboleth" />
    <Rule xsi:type="Requester" value="https://wiki.univie.ac.at/shibboleth" />
    <Rule xsi:type="Requester" value="https://www-vhosts.univie.ac.at/shibboleth" />
    <Rule xsi:type="Requester" value="https://www03.univie.ac.at/shibboleth" />
 </PolicyRequirementRule>
  <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true" />
  <AttributeRule attributeID="displayName" permitAny="true" />
  <AttributeRule attributeID="mail" permitAny="true" />
  <AttributeRule attributeID="eduPersonScopedAffiliation" permitAny="true" />
</AttributeFilterPolicy>

...

One policy you'll probably want to add is releasing all locally defined attributes to the eduID.at Demo Service Provider in order to be able to easily check the configuration and attribute values. (Note that the eduID.at Demo SP does not record (or persist) any recieved attribute values, these are only processed in volatile memory as part of your session.)
An A policy releasing all the attributes defined in this documentation to the eduID.at Demo SP could be as simple as this:

...

Of course the file containing the metadata would need to be registered with the IDP once (in a MetadataProvider, in /opt/shibboleth-idp/conf/metadata-providers.xml) for the IDP to know about those entities. But only that one file with all local SPs, instead of having to add every single SAML SP to the IDP that way (which does not scale and also introduces the problem of having to reload the metadata providers configuration for each SP addition/change/removal). That one metadata provider could be set to reload automatically so new (or changed or removed) SPs contained in that file will be discovered automagically. Though since only you or your own local processes will be updating the content of that local metadata file you could as well reload only that metadata (from the command line or via HTTP/S) specifically after having updated it.

...

An institution may also decide (in addition to all the rules above rules!) to release a very small set of attributes – possibly even more limited than that of the R&S attribute bundle – attributes unconditionally and to every SP it knows via trusted metadata. That allows the institution's members the use of more services than are currently covered by any of the methods outlined above, with essentially no additional risk due to the innocuous nature of the data involved. A simple rule to implement such an approach could look like this, releasing only eduPersonScopedAffiliation (a person's role or affiliation within an institiution, in very coarse standardized terms such as "student" or "faculty") and schacHomeOrganization which only contains the institiution's canonical DNS domain.:

<AttributeFilterPolicy id="InnocuousDataToAnyServiceViaTrustedMetadata">
  <PolicyRequirementRule xsi:type="ANY"/>
  <AttributeRule attributeID="eduPersonScopedAffiliation" permitAny="true" />
  <AttributeRule attributeID="schacHomeOrganization" permitAny="true" />
</AttributeFilterPolicy>

While it's possible to add more or other AttributeRule elements to such an "open" release policy (thereby also releasing more/other attributes) this should only be done after careful consideration of the consequences. If in doubt contact the ACOnet team first.

Consent

Finally, in other cases where the institution (or rather its management) does not want to be responsible for the release of attributes to services, i.e., in cases where none of the above applies (no Service Category or enumeration covering the SP, but the service needs more attributes than one is willing to release to "anyone", as per above, in order to allow access), the IDP could release any attributes an SP requests (in its SAML Metadata , – of course provided the IDP has the attributes configured locallyavailable) but makes the release release conditional to the subject's own freely given, informed, revocable consent. This is intended to still allow subjects from an institution get access to a wide range of services they might need, even when the institution has no policy in place covering those specific services (yet).

For specifics on consent configuration for now please see the Shibboleth IDP documentation on consent and discuss on the community mailing list!

If you're done with editing your filter configuration you can activate the changes in a running IDP by reload reloading only the IDP's attribute filter sub-system, without having to restart the whole Java Servlet container:

/opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.AttributeFilterService

...