It is important that the implementation and deployment of all InCommon services facilitate initial on-boarding processes to avoid operational and technical impediments to adoption, as described in Recommended Practices for InCommon Participants.
More specifically, R&S services generally have a broad user community, often including people who do not have a close relationship with the Service Provider, or whose IdPs do not have a close relationship with the Service Provider. For this reason, R&S Service Providers are encouraged to consider the following guidelines:
To reduce user confusion and frustration, R&S SPs will provide a detailed error page with specific instructions in the event the user is returned to the SP without sufficient attributes. In particular, the SP will direct the user to the administrative contact at the IdP. Thus administrative contact information in IdP metadata is essential information in our effort to reduce manual boarding processes at the SP.
The IdP can short-circuit such an error page simply by including an errorURL
in metadata. This gives the IdP the ability to own this problem by documenting (on the error page) and supporting whatever error handling process it desires.
An IdP releases attributes to any R&S SP (identified by an entity attribute), not specific SPs (identified by entityID
). In effect, an attribute release policy is configured just once for all R&S SPs.
An IDP can choose between possible configurations, depending on its policy needs:
There is only step:
<AttributeFilterPolicy>
element for R&S SPs.This example releases all of the R&S attributes; a campus should customize as appropriate (eg changing the attributeID values).<AttributeFilterPolicy id="releaseToRandS"> <PolicyRequirementRule xsi:type="saml:AttributeRequesterEntityAttributeExactMatch" attributeName="http://id.incommon.org/attribute/entity/category" attributeValue="research-and-scholarship"/> <AttributeRule attributeID="eduPersonPrincipalName"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> <AttributeRule attributeID="email"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> <AttributeRule attributeID="displayName"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> <AttributeRule attributeID="givenName"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> <AttributeRule attributeID="surName"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> <AttributeRule attributeID="eduPersonScopedAffiliation"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy> |
There are two steps to configure a new attribute release policy for R&S SPs:
<md:RequestedAttribute>
elements in SP metadata.<AttributeFilterPolicy>
element for R&S SPs.These two configuration steps taken together constrain the release of attributes to precisely those requested by R&S SPs (which are necessarily a subset of the R&S attribute bundle).
The uApprove addon to the Shibboleth IdP includes a plugin that limits attribute release to the <md:RequestedAttribute>
elements in SP metadata.
uApprove is not required to release attributes to R&S SPs. The steps below do not install the uApprove addon. |
To install and configure the plugin, perform the following steps:
<br><code>$ <b>cp $UAPPROVE_INSTALL$/idp-plugin-2.2.1/lib/* $IDP_INSTALL$/lib/</b></code> |
xmlns:ua="http://www.switch.ch/aai/idp/uApprove/mf"
to the root <AttributeFilterPolicyGroup>
element.The plugin adds a new PermitValueRule
of type ua:AttributeInMetadata
.
The following configuration requires Shibboleth IdP v2.3.4 or later, which fully supports using entity attributes in SP metadata as part of an attribute release filter policy.
Shibboleth IdP v2.3.4 was released on October 27, 2011. For IdPs prior to v2.3.4, InCommon will provide a tool|^policy.xsl\ that filters InCommon metadata into an explicit |
The following IdP configuration implicitly releases attributes to any R&S SP. An attribute is released if and only if it is listed in SP metadata.
<AttributeFilterPolicy id="releaseToRandS"> <PolicyRequirementRule xsi:type="saml:AttributeRequesterEntityAttributeExactMatch" attributeName="http://id.incommon.org/attribute/entity/category" attributeValue="research-and-scholarship"/> <AttributeRule attributeID="eduPersonPrincipalName"> <PermitValueRule xsi:type="ua:AttributeInMetadata" onlyIfRequired="false"/> </AttributeRule> <AttributeRule attributeID="email"> <PermitValueRule xsi:type="ua:AttributeInMetadata" onlyIfRequired="false"/> </AttributeRule> <AttributeRule attributeID="displayName"> <PermitValueRule xsi:type="ua:AttributeInMetadata" onlyIfRequired="false"/> </AttributeRule> <AttributeRule attributeID="givenName"> <PermitValueRule xsi:type="ua:AttributeInMetadata" onlyIfRequired="false"/> </AttributeRule> <AttributeRule attributeID="surName"> <PermitValueRule xsi:type="ua:AttributeInMetadata" onlyIfRequired="false"/> </AttributeRule> <AttributeRule attributeID="eduPersonScopedAffiliation"> <PermitValueRule xsi:type="ua:AttributeInMetadata" onlyIfRequired="false"/> </AttributeRule> </AttributeFilterPolicy> |
No other IdP implementation is known to support entity attributes in SP metadata.
If a campus determines that it wants to block release of attributes for certain community members (e.g., students who have opted out under FERPA), IdP operators could create an additional attribute release policy to enforce this decision. An example is available on the Shibboleth wiki. IdP plugins, such as uApprove, that provide end-user control over attribute release may also be useful to satisfy additional controls.
Upon approval, the following R&S entity attribute is inserted into SP metadata:
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="http://id.incommon.org/attribute/entity/category"> <saml:AttributeValue>http://id.incommon.org/category/research-and-scholarship</saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> |
Assuming other SP categories are added in the future, an SP belonging to multiple categories would have a single entity <saml:Attribute> with multiple <saml:AttributeValue>'s.