New in Shibboleth 1.3.1, ARP Constraints allow the decision to release a given attribute (or group of attributes) to a service provider to be based on the value(s) of other attributes. These constraints were added to address two general use cases:
Complete Suppression of Attribute Release When Not Authorized
In some cases the authorization decision is appropriately made by the Service Provider requiring the release of the attribute payload, while in other cases the Identity Provider is aware of the services a user is authorized for and has either recorded them as entitlements or can derive them from one or more user attributes. Using constraints, an !IdP is able to suppress the unnecessary release of attributes for users that are known to not be authorized for a given service.
Selective Release of Attributes Based on Other Attribute Values
There is often a need to suppress the release of selected attributes based on the values of other attributes. This is particularly necessary in the United States where students can request that certain personal information about them not be released under the Family Educational Rights and Privacy Act (FERPA). This suppression request may be stored in a directory or database as a simple attribute for the user. Using constraints, a policy may be defined in which a Service Provider may receive certain information about all users, and then additional attributes only for those users who have not requested FERPA suppression.
the id of the attribute definition that this constraint value will be matched against
the match function URN that will be used to attempt to match the constraint. All match functions that are defined in Shibboleth are allowed.
this can be one of three values (any, all, or none) and describes how many of the attribute values for the given user must match the defined value in order for the constraint to apply
the attribute value to match against. This is required when the specified match function requires an input value. At the time of this writing, the only match function that does not require an input value is "urn:mace:shibboleth:arp:matchFunction:anyValueMatch"
Use Cases and Examples
Complete Suppression of Attribute Release Using Rule Constraint
Selected Suppression of Attribute Release Based on Other Attribute Values
One common rule and three variant rules are shown. Which of the variants is used depends on how the institution specifies FERPA suppression is in effect. Institutions that populate a FERPA attribute with a specific known value could use either of the first two methods. Institutions that use the mere population of an attribute to indicate FERPA suppression (for example, if the attribute is populated with the date a user requested suppression) would use the third method.
Must have one specific attribute value, but cannot have another
Logical expression: Px and not Py
Example: Release for all users who have an affiliation of "staff" AND do not have an affiliation of "student" (ie, staff who are not also classified as students)
Rule Constraint: (note: multiple constraints are ANDed)
Must have one attribute value or not a value for another attribute
Logical expression: Px or not Qy
Example: Release for all users who have an affiliation of "staff" or those that do not have isPrivate equal "Y" (ie, release all staff and also release all who are not Private)
This cannot be accomplished within one rule but must be separated into two rules that differ only in the Rule Constraint:
<!-- First of Two Rules -->
<AnyValue release="permit" />
<!-- Second of Two Rules -->
<Constraint name="myeduIsPrivate matches="none">Y</Constraint>
<AnyValue release="permit" />
In the existing Shibboleth flow, all authorization decisions occur solely at the Service Provider. With the addition of ARP Constraints, this decision-making may be duplicated at the Identity Provider and therefore could create a problem of keeping these authorization rules synchronized. This proves to be less of a problem if authorization decisions are based on entitlements ? the method of provisioning the entitlement can be modified with no changes to the ARP or AAP.
If a Rule Constraint causes the suppression of all attributes, the Attribute Authority will reply with a completely empty response. The Service Provider will need to ensure that it fails gracefully in this case.