Research and Scholarship and filter by relying party

[Scott Koranda]

Hi Jeffrey,

Thank you for supporting the InCommon R&S program. I run some SPs that
are in the R&S category on behalf of the LIGO project, a large
international research effort aimed at detecting astrophysical sources
of gravitational waves (think black holes colliding) and using them to
open a new window for learning about the structure of the Universe.

Your support of the R&S program as a campus IdP is worth the effort
because it will significantly enhance the ability of your campus
researchers to collaborate with projects like LIGO.

For example, at UCSC you have an astrophysicist doing interesting
simulations of black holes. See

http://news.ucsc.edu/2014/02/tidal-disruption.html?utm_medium=rss

That type of simulation research helps people in our field tune data
analysis pipelines.

I would not be surprised if Professor Ramirez-Ruiz soon decides to
closely collaborate with some LIGO researchers (he could be a
collaborator now, it is a large project and I simply do not know
everything people are doing). If he does he will want to access some
of our SPs so that he can efficiently collaborate with my LIGO
colleagues and get access to LIGO data analysis products.

Since you are pro-actively enabling support for R&S it will just
work--he will not need to contact me or you (he may have to initially
register but he does that using his UCSC federated identity and we do
not have to issue him a LIGO identity).

The more IdPs that support R&S the easier the scientists and
researchers can just get work done without having to get us operators
involved. It also saves me from having to contact each IdP out of band
and try to convince them to interoperate with my SPs. That's a huge
time savings.

Thanks again. The effort is truly appreciated by this SP operator.

Sincerely,

Scott K for LIGO


On Tue, Mar 4, 2014 at 3:18 PM, Jeffrey Crawford <jeffreyc at ucsc.edu> wrote:
>
>
> 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
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net