Page History

By default the Shibboleth Identity Provider (IDP) software will not release any attributes data to any service (except for a short-lived, opaque identifer called transient NameID, also there are a few example rules included in the distributed attribute-filter.xml for illustration purposes).

While not sending any data to anyone is "secure" – much the same way as not connecting a computer to a network is "secure" – it's also not very practical, as essentially all Service Providers (SP) need attributes in order to provide their services and/or perform access control.

There are several approaches to enabling controlled release of attributes to the appropriate services , and most (or all) of them will probably need to be deployed within an institutional IDP:

The following policies and rules are meant to be added to your Shibboleth IDP's attribute filter configuration, by default in /opt/shibboleth-idp/conf/attribute-filter.xml

...

GÉANT EU/EEA Data Protection Code of Conduct for Service Providers

...

ACOnet-registered services

European Student Identifier

The MyAcademicID ESI category manages the scalable and controlled release of the European Student Identifier (ESI) as required e.g. by the European Commission's Erasmus+ services.

We're also using this category to control release of the Erasmus Without Paper (EWP) admin entitlement to keep things simple:

ACOnet-registered services

If you're satisfied with the checks performed by the ACOnet team during registration of new ACOnet Identity Federation member Service Providers – cf. our Metadata Registration Practice Statement, section 5.4 – you may decide to release any attributes that are listed as RequestedAttribute elements in the Service Provider's SAML Metadata to all services that have been registered by ACOnet and which are bona fide ACOnet Identity Federation members (If you're satisfied with the checks performed by the ACOnet team during registration of new ACOnet Identity Federation member Service Providers – cf. our Metadata Registration Practice Statement, section 5.4 – you may decide to release any attributes that are listed as RequestedAttribute elements in the Service Provider's SAML Metadata to all services that have been registered by ACOnet and which are bona fide ACOnet Identity Federation members (which are bound by the ACOnet Identity Federation Policy.) Whether those facts are considered sufficient to release personal data to a service remains a local decision.

...

<AttributeFilterPolicy id="RegisteredByACOnetRequiredAttributes">
  <PolicyRequirementRule xsi:type="RegistrationAuthority" registrars="http://eduid.at"/>
  <AttributeRule attributeID="displayName">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="givenName">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="surnamesn">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="mail">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="eduPersonScopedAffiliation">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="eduPersonPrincipalName">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="eduPersonUniqueId">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="eduPersonTargetedID">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
  <AttributeRule attributeID="schacHomeOrganization">
    <PermitValueRule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="false"/>
  </AttributeRule>
  <AttributeRule attributeID="eduPersonEntitlement">
    <PermitValueRule xsi:type="AND">
      <Rule xsi:type="MappedAttributeInMetadataAttributeInMetadata" onlyIfRequired="false"/>
      <!-- Limit entitlement values that can be released under this generic policy. -->
      <Rule xsi:type="OR">
        <Rule xsi:type="Value" value="urn:mace:dir:entitlement:common-lib-terms"/>
        <Rule xsi:type="Value" value="urn:mace:terena.org:tcs:personal-user"/>
        <Rule xsi:type="Value" value="urn:mace:terena.org:tcs:escience-user"/>
        <Rule xsi:type="Value" value="https://rdb.manz.at/student/remote-access"/>
        <Rule xsi:type="Value" value="https://rdb.manz.at/fellow/remote-access"/>
        <Rule xsi:type="Value" value="http://usi.at/student-discount"/>
      </Rule>
    </PermitValueRule>
  </AttributeRule>
</AttributeFilterPolicy>

Enumerating services

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.

SAML Subject-ID Attributes

Recent versions of the Shibboleth IDP software ship with a default/example attribute filter rule that releases the SAML Standard Identifier attributes (SAML Subject-ID, SAML Pairwise-ID) to any known SP that requests them according to the new signalling (using an extension Entity Attribute instead of the traditional RequestedAttribute metadata element). While that's helpful in getting up and running quickly you may want to further limit to whom you're passing along this personal data.

In the examples below we've added alternative requirements just when these identifiers should be released. In the first example shown below either of the requested SAML Subject-ID attributes would only go out to SPs belonging to the REFEDS Research & Scholarship service category (see above or Service Categories) or belonging to the GÉANT Data Protection Code of Conduct service category (ibid.) or having been registered locally by ACOnet (and therefore are bound by the ACOnet Identity Federation policy).

Arguably the safeguards added below are somewhat arbitrary but some may still find this preferrable over releasing personal data to just any SP that's capable of asking for them in the technically correct way.

<AttributeFilterPolicy id="subject-identifiers">
    

<AttributeFilterPolicy id="CollaborationAndNRENServices">
  <PolicyRequirementRule xsi:type="OR">
        <Rule xsi:type="RequesterEntityAttributeExactMatch" value
            attributeName="httpshttp://wwwmacedir.aco.net/shibboleth" />
org/entity-category"
          <Rule xsi:type="Requester" value attributeValue="httpshttp://eduroam.aco.net/shibboleth" refeds.org/category/research-and-scholarship"/>
        <Rule xsi:type="RequesterEntityAttributeExactMatch" value
            attributeName="httpshttp://wiki.univie.ac.at/shibboleth" />
macedir.org/entity-category"
          <Rule xsi:type="Requester" value attributeValue="httpshttp://www-vhosts.univie.ac.at/shibboleth" geant.net/uri/dataprotection-code-of-conduct/v1"/>
     <Rule   <Rule xsi:type="RequesterRegistrationAuthority" valueregistrars="httpshttp://www03eduid.univie.ac.at/shibboleth" />
 <    </PolicyRequirementRule>

    <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true" /samlPairwiseID">
  <AttributeRule attributeID="displayName" permitAny="true" />
  <AttributeRule attributeID="mail" permitAny<PermitValueRule xsi:type="trueOR" />
   <AttributeRule attributeID="eduPersonScopedAffiliation" permitAny="true" />
</AttributeFilterPolicy>         <Rule xsi:type="EntityAttributeExactMatch"
                attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
                attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                attributeValue="pairwise-id" />
            <Rule xsi:type="EntityAttributeExactMatch"
                attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
                attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                attributeValue="any" />
        </PermitValueRule>
    </AttributeRule>

    <AttributeRule attributeID="samlSubjectID">
        <PermitValueRule xsi:type="EntityAttributeExactMatch"
            attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
            attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            attributeValue="subject-id" />
    </AttributeRule>
</AttributeFilterPolicy>

An alternative implementation of such additional safeguards could apply those only for the "samlSubjectID" attribute but not for "samlPairwiseID": "samlPairwiseID" is much more privacy preserving – at least when not released together with more identfying data – and could therefore possibly be released without such additional safeguards:

<AttributeFilterPolicy id="subject-identifiers">
    <PolicyRequirementRule xsi:type="ANY" />

    <AttributeRule attributeID="samlPairwiseID">
        <PermitValueRule xsi:type="OR">
            <Rule xsi:type="EntityAttributeExactMatch"
                attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
                attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                attributeValue="pairwise-id" />
            <Rule xsi:type="EntityAttributeExactMatch"
                attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
                attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                attributeValue="any" />
        </PermitValueRule>
    </AttributeRule>
</AttributeFilterPolicy>

<AttributeFilterPolicy id="samlSubjectID">
    <PolicyRequirementRule xsi:type="OR">
        <Rule xsi:type="EntityAttributeExactMatch"
            attributeName="http://macedir.org/entity-category"
            attributeValue="http://refeds.org/category/research-and-scholarship"/>
        <Rule xsi:type="EntityAttributeExactMatch"
            attributeName="http://macedir.org/entity-category"
            attributeValue="http://www.geant.net/uri/dataprotection-code-of-conduct/v1"/>
        <Rule xsi:type="RegistrationAuthority" registrars="http://eduid.at"/>
    </PolicyRequirementRule>

    <AttributeRule attributeID="samlSubjectID">
        <PermitValueRule xsi:type="EntityAttributeExactMatch"
            attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
            attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            attributeValue="subject-id" />
    </AttributeRule>
</AttributeFilterPolicy>

It is expected we'll be seeing specific Service Categories being developed to help make better and more scalable use of these new identifiers.

Enumerating services

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.

<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>

Individual policies

Services requiring special configuration are often best dealt with by giving them their own, individual filter policy.
Examples can be found in this wiki, e.g.:

• Erasmus+ services
• TCS Personal Certs
• USI Wien
• RDB
• ubook

...

<AttributeFilterPolicy id="eduID.at-Demo-SP">
  <PolicyRequirementRule xsi:type="Requester" value="https://test-sp.aco.net/shibboleth/shibboleth" />
  <AttributeRule attributeID="givenName" permitAny="true" />
  <AttributeRule attributeID="sn" permitAny="true" />
  <AttributeRule attributeID="givenNamedisplayName" permitAny="true" />
  <AttributeRule attributeID="surnamemail" permitAny="true" />
  <AttributeRule attributeID="displayNamesamlSubjectID" permitAny="true" />
  <AttributeRule attributeID="mailsamlPairwiseID" permitAny="true" />
  <AttributeRule attributeID="subject-ideduPersonPrincipalName" permitAny="true" />
  <AttributeRule attributeID="pairwise-ideduPersonScopedAffiliation" permitAny="true" />
  <AttributeRule attributeID="eduPersonPrincipalNameeduPersonEntitlement" permitAny="true" />
  <AttributeRule attributeID="eduPersonScopedAffiliationeduPersonTargetedID" permitAny="true" />
  <AttributeRule attributeID="eduPersonEntitlementschacHomeOrganization" permitAny="true" />
  <AttributeRule attributeID="schacHomeOrganizationschacPersonalUniqueCode" permitAny="true" />
</AttributeFilterPolicy>

...

An attribute filter policy active for all Services Providers present in that file could then look like this, referencing the Name attribute (value) of the EntitiesDescriptor element (see above) in the groupID attribute of the PolicyRequirementRule (see below). In this (somewhat ficticious) example all Service Providers whose metadata is available in a metadata file with that Name attribute would recieve the (only locally relevant / or unique) attributes uid, employeeNumber, provided those were defined in the IDP and had any values for the given subject:

<AttributeFilterPolicy id="LocalEntitiesNOTinFederation">
  <PolicyRequirementRule xsi:type="InEntityGroup" groupID="https://example.edu/local-entities" />
  <AttributeRule attributeID="uid" permitAny="true" /<AttributeFilterPolicy id="LocalEntitiesNOTinFederation">
  <PolicyRequirementRule<AttributeRule xsi:typeattributeID="InEntityGroupemployeeNumber" groupIDpermitAny="https://example.edu/local-entities" />
  <AttributeRule attributeID="uid" permitAny="true" />
  <AttributeRule attributeID="employeeNumber" permitAny="true" />
</AttributeFilterPolicy>"true" />
</AttributeFilterPolicy>

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 itOf course the metadata would need to be registered with the IDP once for the IDP to know about those entities. See IDP 4 Metadata configuration for details.

Default/Fallback attribute release

An institution may also decide (in addition to all the above rules) to release a very small set of attributes – possibly even more limited than that of the R&S attribute bundle – 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 or only very little additional risk due to the innocuous nature 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") , plus eduPersonTargetedID (an opaque identifier/pseudonym that differs for every SP, even for the same person). You may also add and schacHomeOrganization which only contains the institiution's canonical DNS domain (and so isn't even personal data).

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

...