<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 4, 2014 at 11:47 AM, Tom Scavo <span dir="ltr"><<a href="mailto:trscavo@gmail.com" target="_blank">trscavo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jeffrey,<br>
<div><br>
On Tue, Mar 4, 2014 at 2:28 PM, Jeffrey Crawford <<a href="mailto:jeffreyc@ucsc.edu" target="_blank">jeffreyc@ucsc.edu</a>> wrote:<br>
><br>
> I hope I'm just missing something simple here. We have based our Shibboleth<br>
> configuration to communicate with SP's based on inCommon EntityID's in the<br>
> relying-party configuration file. We now want to support Research and<br>
> Scholarship and have set up the filter but I can't seem to find a way to<br>
> have the relying-party part allow Research and Scholarship in.<br>
<br>
</div><a href="https://spaces.internet2.edu/x/BoOVAQ" target="_blank">https://spaces.internet2.edu/x/BoOVAQ</a><br>
<div><br>
> I've used EntitiesDescriptor to group non inCommon metadata before, but<br>
> InCommon hasn't grouped these SP's into an EntitiesDescriptor group that is<br>
> specific to Research and Scholarship.<br>
<br>
</div>Right, we use entity attributes instead:<br>
<br>
<a href="https://spaces.internet2.edu/x/KgXvAQ" target="_blank">https://spaces.internet2.edu/x/KgXvAQ</a><br>
<br>
(Marvelous invention, those entity attributes :)<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Although that may be true, we've been running the IdP for a little over 5 years and at the time listing entityID's was a pretty convenient way to support the campus policy of only allowing SP's that were deemed "authorized" to communicate with the IdP. Granted this was a long time ago and we may need to change that but we have a list of over 80 entries we need to convert from RelyingParty to Filters</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> Is there some other mechanism I can use or do I need to change our config<br>
> from relying-party based to filter based? I don't really like going to<br>
> filter based because I would think that when we have an SP we have not<br>
> authorized, it would look like we allow a login but then we simply don't<br>
> send any attributes. using relying-party it pretty clear we don't support<br>
> them because it generates an error.<br>
<br>
</div>You might want to reconsider that strategy. Current wisdom is that the<br>
SP should be able to handle the lack of attributes:<br>
<br>
<a href="https://spaces.internet2.edu/x/m42KAQ" target="_blank">https://spaces.internet2.edu/x/m42KAQ</a><br>
<a href="https://spaces.internet2.edu/x/xa6KAQ" target="_blank">https://spaces.internet2.edu/x/xa6KAQ</a></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'courier new',monospace">Well okay so if an SP doesn't even get NamedID it's supposed to handle that? there are various reasons for controlling what our IdP allows logins to, the simplicity of simply saying that we don't support an SP unless it's authorized covers most if not all those reasons.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">It doesn't look like Metadata Filtering is going to help in this case so It's starting to look like I'm going to have to change from relying-party based to filter based.</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
The IdP's job is to authenticate the user and provide attributes<br>
(subject to policy). If it can't provide attributes (for one reason or<br>
the other), it should still authenticate the user and go on with life.<br>
<br>
Hope this helps,<br>
<br>
Tom<br>
<div><div>--<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>
</div></div></blockquote></div><br></div></div>