[prev in list] [next in list] [prev in thread] [next in thread]
List: shibboleth-users
Subject: Re: InCommon AttributeFilterPolicy PolicyRequirementRule?
From: Baron Fujimoto via users <users () shibboleth ! net>
Date: 2023-05-03 17:22:12
Message-ID: CAAjLUL0YWKs6vyXFMYpiHiqcsRDSCARvK=JBwbutkzJuwjF-pA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
On Mon, May 1, 2023 at 6:37 AM Kevin Foote <kevin.foote@colorado.edu> wrote:
> Hello Baron,
>
> 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.
>
> thanks
> - kevin.foote
>
>
>
>
>
>
> > On Apr 28, 2023, at 8:19 PM, Baron Fujimoto via users <
> users@shibboleth.net> wrote:
> >
> > [External Email - Use caution]
> >
> > 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?
> >
> > On Fri, Apr 28, 2023 at 2:55 PM Baron Fujimoto <baron@hawaii.edu> wrote:
> > Can anyone provide a pointer to the current recommended practice for an
> AttributeFilterPolicy PolicyRequirementRule for the InCommon Federation?
> My searches at incommon.org and shibboleth.net have been unsuccessful.
> >
> > The InCommon AttributeFilterPolicy for InCommon we have carried forward
> over many upgrades is:
> >
> > <AttributeFilterPolicy id="InCommon_Federation">
> > <PolicyRequirementRule xsi:type="AND">
> > <Rule xsi:type="EntityAttributeExactMatch"
> > attributeName="
> http://macedir.org/entity-category"
> > attributeValue="
> http://id.incommon.org/category/registered-by-incommon" />
> > <Rule xsi:type="RegistrationAuthority"
> > registrars="https://incommon.org" />
> > </PolicyRequirementRule>
> > ...
> >
> > Where I think we expect something like the following in the entity's InC
> metadata:
> >
> > <Extensions>
> > <mdrpi:RegistrationInfo
> xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi" registrationAuthority="
> https://incommon.org"/>
> > <mdattr:EntityAttributes
> xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
> > <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> Name="http://macedir.org/entity-category"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> > <saml:AttributeValue>
> http://id.incommon.org/category/registered-by-incommon
> </saml:AttributeValue>
> > </saml:Attribute>
> > </mdattr:EntityAttributes>
> > </Extensions>
> >
> > However, we have now encountered an SP (entityID="
> https://login.offcampuspartners.com") 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?
> >
> > Any suggestions would be appreciated.
> > --
> > Baron Fujimoto <baron@hawaii.edu> ::: UH Information Technology Services
> > minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
> >
> >
> > --
> > Baron Fujimoto <baron@hawaii.edu> ::: UH Information Technology Services
> > minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
> > --
> > For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> > To unsubscribe from this list send an email to
> users-unsubscribe@shibboleth.net
>
>
--
Baron Fujimoto <baron@hawaii.edu> ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
[Attachment #5 (text/html)]
<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>
--
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic