Research and Scholarship and filter by relying party

[Jeffrey Crawford]

On Tue, Mar 4, 2014 at 11:47 AM, Tom Scavo <trscavo at gmail.com> wrote:

> Hi Jeffrey,
>
> On Tue, Mar 4, 2014 at 2:28 PM, Jeffrey Crawford <jeffreyc at ucsc.edu>
> wrote:
> >
> > I hope I'm just missing something simple here. We have based our
> Shibboleth
> > configuration to communicate with SP's based on inCommon EntityID's in
> the
> > relying-party configuration file. We now want to support Research and
> > Scholarship and have set up the filter but I can't seem to find a way to
> > have the relying-party part allow Research and Scholarship in.
>
> https://spaces.internet2.edu/x/BoOVAQ
>
> > I've used EntitiesDescriptor to group non inCommon metadata before, but
> > InCommon hasn't grouped these SP's into an EntitiesDescriptor group that
> is
> > specific to Research and Scholarship.
>
> Right, we use entity attributes instead:
>
> https://spaces.internet2.edu/x/KgXvAQ
>
> (Marvelous invention, those entity attributes :)
>

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


> > Is there some other mechanism I can use or do I need to change our config
> > from relying-party based to filter based? I don't really like going to
> > filter based because I would think that when we have an SP we have not
> > authorized, it would look like we allow a login but then we simply don't
> > send any attributes. using relying-party it pretty clear we don't support
> > them because it generates an error.
>
> You might want to reconsider that strategy. Current wisdom is that the
> SP should be able to handle the lack of attributes:
>
> https://spaces.internet2.edu/x/m42KAQ
> https://spaces.internet2.edu/x/xa6KAQ


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.

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.



>
>
> The IdP's job is to authenticate the user and provide attributes
> (subject to policy). If it can't provide attributes (for one reason or
> the other), it should still authenticate the user and go on with life.
>
> Hope this helps,
>
> Tom
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140304/74d44a68/attachment.html