You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Service Categories (or Entity Categories) help managing the secure release of the right attributes to only appropriate Service Providers – within the eduID.at federation and beyond. As such the use of Service Categories within local policies is highly recommended as basis for scalable attribute release policies/decisions. The ultimate responsibility for the release of any personal data to third parties rests with the institution releasing the data, though.

Service Categories for Attribute Release

Based on prior work by RENATER the international Identity Federations community (lead by Internet2, REFEDS and GEANT/eduGAIN) has started to create Service Categories (technically called "Entity Categories", since they apply to SAML "entities") in order to ease the management of release of personal data ("attributes") to services: It has long been apparent that manually writing and maintaining attribute release rules based on individual services does not scale sufficiently, esp. taking into account that science and research today requires international collaboration and does not stop at national or "federation" borders. Dealing with individual services on a case-by-case basis creates too much work for institutions and their staff (if done "right"), often resulting in students or scientists not being able to access (inter-)federated resources because the institiutional SAML Identity Provider did not release any data to the accessed service.

Entity Categories solve this problem by grouping related services into clearly defined categories (taking into account purpose, risk/benefit and legal requirements) and scaling the management of those categories (i.e., which services are part of which category) across Identity Federations.

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

Make sure to get the use of these rules within your IT systems approved by upper management of your institution (e.g. by the CIO, possibly also involving works council/Betriebsrat/ÖH). Service Categories allow for such approval processes to only occur once per category, covering potentially unlimited numbers of services belonging to that category.

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 and all questions relating to Service Categories!

REFEDS Research & Scholarship

Membership in this category https://refeds.org/category/research-and-scholarship/ is reserved to services "that support research and scholarship interaction, collaboration or management as an essential component." This globally applicable category takes a risk-based approach, enabling access to high-benefit resources with low-risk services, releasing only low-risk personal data. Basically only the minimum personal data required for scientific collaboration and attribution of a person's work (name, email address and an identifer) is released.

<afp:AttributeFilterPolicy id="REFEDSResearchAndScholarship">
  <afp:PolicyRequirementRule xsi:type="saml:AttributeRequesterEntityAttributeExactMatch"
    attributeName="http://macedir.org/entity-category"
    attributeValue="http://refeds.org/category/research-and-scholarship"/>
 
  <!-- minimal subset of the R&S attribute bundle -->
  <!-- assuming non-reassigned ePPN values, otherwise also include eduPersonTargetedID here -->
  <afp:AttributeRule attributeID="eduPersonPrincipalName">
    <afp:PermitValueRule xsi:type="basic:ANY" />
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="email">
    <afp:PermitValueRule xsi:type="basic:ANY" />
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="displayName">
    <afp:PermitValueRule xsi:type="basic:ANY" />
  </afp:AttributeRule>

  <!-- other attributes only if requested -->
  <afp:AttributeRule attributeID="givenName">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="surname">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="eduPersonTargetedID">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
</afp:AttributeFilterPolicy>

As part of the Code of Conduct 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 the Identity Provider are based in the EU/EEA (i.e., it does not help with services outside the EU/EEA) and takes a rather literal reading of the EU data protection directive. 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.

 GEANT EU/EEA Data Protection Code of Conduct

As this Category definition does not 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 this policy, possibly including more attributes (if you have those available in your IDP). The confguration below is an example based on the most commonly used attributes in Identity Federations today which also most/all IDPs should be able to generate.

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