Research and Scholarship and filter by relying party

Tom Scavo trscavo at gmail.com
Tue Mar 4 14:47:46 EST 2014


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 :)

> 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

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


More information about the users mailing list