Research and Scholarship and filter by relying party

[Cantor, Scott]

On 3/5/14, 6:28 PM, "Jeffrey Crawford" <jeffreyc at ucsc.edu> wrote:
>
>Well therein lies the problem, if we are not sending attributes an app
>wants and it behaves badly we might be causing error pages go up with
>sensitive information.

I don't know what you mean by sensitive information. What you normally get
is a bad error message or a crash/stack trace. Nothing sensitive (not that
it's the IdP's responsibility if it were).

This is simply a difference in philosophy. I'm not trying to convince you,
just pointing out it's not the only way to approach the question.

>As long as the file is present and being updated the IdP will continue to
>read it correct, or did I miss someplace that requires configuration that
>the IdP periodically reads the file?

If you're asking whether the IdP will reload a local file source when it
changes, yes, it does that by default.

>Well this will incur a special kind of madness :). If I may post an
>example to work with xlstproc, we want to allow certin entityID's and all
>entityID's that are part of RandS (by the way
> I don't pretend to know xslt all that well) does this look resonable?:

I'm no particular expert at XSLT, I just dabble in it when I have to, but
that looks to be something like what I would expect. The proof is in the
pudding, what it actually spits out.

Of course, you would need to offload the signature check from the IdP to a
script running xmlsectool or something of that sort, and run that via
cron. Personally, I would probably just write the small bit of Java code
to build a filter, because that avoids extra pieces, but if you don't know
Spring, that can appear to be a lot of work.

-- Scott