Page History

...

Below you'll find copy&paste-able attribute release filter rules for the Shibboleth Identity Provider v2.4 (TODO: IDPv3) for v3 for each of the most important Service Categories. Be sure to carefully read and understand each category's description/definition before use.

...

People managing technical infrastructure (such as servers and Shibboleth configuration files) should not be ultimately responsible for decisions resulting in the (non-)release of personal data to third parties. Contact ACOnet with any questions relating to Service Categories!

...

...

As part of the GÉANT Data Protection Code of Conduct's Cookbook you'll find the Recipe for a Home Organisation, giving complete instructions on the necessary steps for deployment. This Service Category only applies when both the Service Provider and  (as well as the Identity Provider are ) is based in the EU/EEA ( or countries with adequate data protection), and uses the EU Data Protection Directive 95/46/EC as common frame for disparate implementations thereof throughout the EU. As such it is mostly meant as a reminder and a reassurance to both service owners and home organizations that the services covered are already subject to (national implementations of) EU data protection law.

As this Category definition does not currently specify an attribute bundle (i.e., it doesn't reference specific attributes which should be released) the list of attributes to release is basically open-ended. As such you may need to adapt the attribute rules included within the policy, possibly including (fewer or) more attributes (depending on what attributes you have available in your IDP and whether the institution is willing to release them under these terms). In practice, however, only a very limited set of data is being exchanged within/across academic Identity Federations today: A person's name, email-address, identifier(s) and role infomation ("affiliation", e.g. "student" vs. or "staff").
The confguration below is an example based on the most commonly used attributes in Identity Federations today which most/all eduID.at Identity Providers should be able to generate.

<AttributeFilterPolicy id="GeantEEADataProtectionCodeOfConduct">
  <PolicyRequirementRule xsi:type="EntityAttributeExactMatch"
    attributeName="http://macedir.org/entity-category"
    attributeValue="http://www.geant.net/uri/dataprotection-code-of-conduct/v1"/>
  <!-- Release data to EU/EEA/Adequat CoCo-SPs, based on RequestedAttributes in SAML metadata -->
  <AttributeRule attributeID="displayName">
    <PermitValueRule xsi:type="MappedAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="givenName">
    <PermitValueRule xsi:type="MappedAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="surname">
    <PermitValueRule xsi:type="MappedAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="email">
    <PermitValueRule xsi:type="MappedAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="eduPersonScopedAffiliation">
    <PermitValueRule xsi:type="MappedAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="eduPersonPrincipalName">
    <PermitValueRule xsi:type="MappedAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="eduPersonTargetedID">
    <PermitValueRule xsi:type="MappedAttributeInMetadata" onlyIfRequired="false"/>
  </AttributeRule>
  <AttributeRule attributeID="schacHomeOrganization">
    <PermitValueRule xsi:type="MappedAttributeInMetadata" onlyIfRequired="false"/>
  </AttributeRule>
</AttributeFilterPolicy>

 See also

IDP2 Attribute release, from Again, be sure to check out the more general attribute release documentation in our Shibboleth IDP 2.4 documentation sectionv3 documentation, which contains more ready-to-use examples and approaches.