DiscoFeed and jsonp

[Brent Putman]

On 1/27/16 6:21 PM, Janusz Ulanowski wrote:
> On 27/01/16 23:12, Brent Putman wrote:
>>
>>
>> Supporting it would probably be very easy, I think.  Whether or not
>> it's
>> a good idea (security-wise, etc).... I don't know.  That's beyond my
>> Javascript.  I guess if it's turned off by default, and the consumer
>> takes responsibility for doing the right thing, then maybe it's ok.
>> Maybe the main concern would be about exposing the IdP data to pages
>> that don't live on the SP itself...?
>>
>>
>>
>> [1] https://en.wikipedia.org/wiki/JSONP
>>
>>
>>
>
> I'm not sure if there is security concern - if DiscoFeed is enabled
> you can still get the list with a direct request. To me it's just
> other way to represent data and for client is even more secure (AFAIK).

That's true, there might not be issues with the IdP data itself
exposed, since it's (I think) already public by virtue of the DiscoFeed.

But I was thinking mostly of all the complex front-end web security
stuff one has to think about.  The threat(s) are really to the
application consuming the disco feed. It's basically being handed back
a Javascript function which it just executes. If there were a bug in
the SP, or other mechanism by which to insert malicious code into the
JSONP feed, then the consuming page has to be concerned about things
like that.  For that, there's all the CSP [1] and CORS [2] stuff to
consider, which are also beyond my Javascipt, but I know they're there
and what the general concerns are.

But those are going to implemented (I think) at the web server level
(i.e. send back headers) and so not really with what the SP is directly
concerned. So maybe it would just be an "implementor beware" thing -
using such JSONP support would mean you need to know what you are doing....

[1] https://en.wikipedia.org/wiki/Content_Security_Policy

[2] https://en.wikipedia.org/wiki/Cross-origin_resource_sharing



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160127/90699185/attachment.html>