Note: this document is still being revised as I explore the issue.

Many of the applications I support use Shibboleth not only for authentication, but also to populate and synchronize metadata about the user: display name, UIN, group memberships, or anything else available in our central registry. An upcoming change in how FERPA suppressed users are presented got me looking at how I could better use the Shibboleth Native Service Provider (SP) to handle metadata (I won’t be considering other SP’s).

Some of the attributes I request are only for convenience and are not mandatory for the application. When a user requests FERPA suppression the application should only have access to the smallest set of attributes required. One way to do this would be to modify each application to behave differently under suppression. But you can also use the Shibboleth SP itself to filter attributes, and leave the application alone.

At the University of Illinois, FERPA suppression is indicated in the iTrustSuppress attribute. If your SP isn’t already requesting this attribute, log in to the I-Trust Federation Registry and add it. We also have to configure the SP to map this attribute to a name in attribute-map.xml

<Attribute name="urn:oid:1.3.6.1.4.1.11483.101.3"id="iTrustSuppress"/>

You can check that the new attribute is being delivered by visiting “https://your-server.illinois.edu/Shibboleth.sso/Login?target=https://your-server.illinois.edu/Shibboleth.sso/Session”. If you’d like to see the attribute values, edit your shibboleth2.xml and set the “Session” handler “showAttributeValues” to “true”.

The last step is to edit attribute-policy.xml and define an iTrustSuppress policy. What attributes you allow or deny will depend on your applications, but here is an example of minimal attributes for WordPress (eppn and mail).

<afp:AttributeFilterPolicy id="iTrustSuppressPolicy">
    <!-- Only run this policy if the user is suppressed -->
    <afp:PolicyRequirementRule xsi:type="AttributeValueString"
            attributeID="iTrustSuppress"
            value="y"
            ignoreCase="true"/>

    <!--
        Rules for attributes we should always allow the application to see.
        This will vary based on the requirements of the application.

        * eppn: used for REMOTE_USER
        * mail: required by WordPress for all users
        * persistent-id: unused, but not identifiable information
    -->
    <afp:AttributeRule attributeID="eppn">
        <afp:PermitValueRule xsi:type="ANY"/>
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="mail">
        <afp:PermitValueRule xsi:type="ANY"/>
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="persistent-id">
        <afp:PermitValueRule xsi:type="ANY"/>
    </afp:AttributeRule>


    <!--
        Attributes allowed by another filter policy,
        but should be FERPA supressed. If they are explicitly allowed
        by any non-wildcard filter policy then the wildcard rule
        will not run.
    -->
    <afp:AttributeRule attributeID="affiliation">
        <afp:DenyValueRule xsi:type="ANY"/>
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="unscoped-affiliation">
        <afp:DenyValueRule xsi:type="ANY"/>
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="primary-affiliation">
        <afp:DenyValueRule xsi:type="ANY"/>
    </afp:AttributeRule>

    <!--
        Default rule is to suppress the value. This wildcard
        rule will not run if the attribute matches any non-wildcard
        rules in other policies.
    -->
    <afp:AttributeRule attributeID="*">
        <afp:DenyValueRule xsi:type="ANY"/>
    </afp:AttributeRule>
</afp:AttributeFilterPolicy>Test

If you have other policies defined then make sure that any attributes they explicitly allow should be allowed for a suppressed user, or are explicitly denied in the iTrustSuppressPolicy. Filter policies are evaluated in the order they are defined, so it would probably be best to add the iTrustSuppressPolicy at the end of the filter policy group.