<div dir="ltr">This is what I ended up doing as well. On the Slack channel, Scott Cantor confirmed that the "registered-by-incommon" value is what defines the InC Federation membership. Since this was not the case here, I decided to just treat them as a standalone entity even though we could potentially get their metadata via InC, in order to avoid a potentially confusing mix of configs.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 1, 2023 at 6:37 AM Kevin Foote <<a href="mailto:kevin.foote@colorado.edu">kevin.foote@colorado.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello Baron, <br>
<br>
I’m not sure if “recommended practice” fits how we handle / deal with these issues but, locally we end up making a specific filter for entities or SPs that fall into scenarios such as the one you describe. <br>
<br>
thanks<br>
- kevin.foote<br>
<br>
<br>
<br>
<br>
<br>
<br>
> On Apr 28, 2023, at 8:19 PM, Baron Fujimoto via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> wrote:<br>
> <br>
> [External Email - Use caution]<br>
> <br>
> I've received some additional information from the SP. They advise, "... we are not direct members of InCommon but members of the CAF Federation. CAF, publishes their members to eduGain (a global federation), and InCommon pulls in OffCampus Partners metadata from eduGain". So perhaps this explains their lack of the elements we rely on for InC membership, but I'm not sure how we should handle this in a way that leverages the InC metadata source?<br>
> <br>
> On Fri, Apr 28, 2023 at 2:55 PM Baron Fujimoto <<a href="mailto:baron@hawaii.edu" target="_blank">baron@hawaii.edu</a>> wrote:<br>
> Can anyone provide a pointer to the current recommended practice for an AttributeFilterPolicy PolicyRequirementRule for the InCommon Federation? My searches at <a href="http://incommon.org" rel="noreferrer" target="_blank">incommon.org</a> and <a href="http://shibboleth.net" rel="noreferrer" target="_blank">shibboleth.net</a> have been unsuccessful.<br>
> <br>
> The InCommon AttributeFilterPolicy for InCommon we have carried forward over many upgrades is:<br>
> <br>
> <AttributeFilterPolicy id="InCommon_Federation"><br>
> <PolicyRequirementRule xsi:type="AND"><br>
> <Rule xsi:type="EntityAttributeExactMatch"<br>
> attributeName="<a href="http://macedir.org/entity-category" rel="noreferrer" target="_blank">http://macedir.org/entity-category</a>"<br>
> attributeValue="<a href="http://id.incommon.org/category/registered-by-incommon" rel="noreferrer" target="_blank">http://id.incommon.org/category/registered-by-incommon</a>" /><br>
> <Rule xsi:type="RegistrationAuthority"<br>
> registrars="<a href="https://incommon.org" rel="noreferrer" target="_blank">https://incommon.org</a>" /><br>
> </PolicyRequirementRule><br>
> ...<br>
> <br>
> Where I think we expect something like the following in the entity's InC metadata:<br>
> <br>
> <Extensions><br>
> <mdrpi:RegistrationInfo xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi" registrationAuthority="<a href="https://incommon.org" rel="noreferrer" target="_blank">https://incommon.org</a>"/><br>
> <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"><br>
> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="<a href="http://macedir.org/entity-category" rel="noreferrer" target="_blank">http://macedir.org/entity-category</a>" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><br>
> <saml:AttributeValue><a href="http://id.incommon.org/category/registered-by-incommon" rel="noreferrer" target="_blank">http://id.incommon.org/category/registered-by-incommon</a></saml:AttributeValue><br>
> </saml:Attribute><br>
> </mdattr:EntityAttributes><br>
> </Extensions><br>
> <br>
> However, we have now encountered an SP (entityID="<a href="https://login.offcampuspartners.com" rel="noreferrer" target="_blank">https://login.offcampuspartners.com</a>") that is in the InC metadata, but for which these requirements are not present. I think this is the first time we've encountered issues with these conditions. But maybe we should be doing this differently now?<br>
> <br>
> Any suggestions would be appreciated.<br>
> -- <br>
> Baron Fujimoto <<a href="mailto:baron@hawaii.edu" target="_blank">baron@hawaii.edu</a>> ::: UH Information Technology Services<br>
> minutas cantorum, minutas balorum, minutas carboratum descendus pantorum<br>
> <br>
> <br>
> -- <br>
> Baron Fujimoto <<a href="mailto:baron@hawaii.edu" target="_blank">baron@hawaii.edu</a>> ::: UH Information Technology Services<br>
> minutas cantorum, minutas balorum, minutas carboratum descendus pantorum<br>
> -- <br>
> For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
> To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><font face="arial, sans-serif">Baron Fujimoto <<a href="mailto:baron@hawaii.edu" target="_blank">baron@hawaii.edu</a>> ::: UH Information Technology Services<br>minutas cantorum, minutas balorum, minutas carboratum descendus pantorum</font></div></div>