<br>
<br>
On Wed, Dec 11, 2013 at 11:00 PM, Sean McHugh <<a href="javascript:;" onclick="_e(event, 'cvml', 'sean8sean@gmail.com')">sean8sean@gmail.com</a>> wrote:<br>
> I've recently discovered the joy of Anonymous relying parties as my Shib IdP<br>
> infrastructure has now grown.<br>
><br>
> While I find it convenient to utilize this as a way to reduce overhead in<br>
> managing SPs, I've grown more concerned about the potential for abuse:<br>
><br>
> in theory, one could coax a user to a URL configured to send a proper<br>
> AuthNRequest to my IdP, thereby capturing attributes released by default<br>
<br>
I understand both points of view, yes. Of course the two perspective are at total odds with each other.<br>
<br>
> Am I correct here? Is there documentation or a collection of thoughts on<br>
> other potential security concerns surrounding Anon RPs?<br>
<br>
I suggest you go read the relevant parts of the emerging OpenID Connect spec, which encourages what you are calling "anonymous relying parties" but also gives advice to IdPs in this regard. You won't find anything in the SAML world along these lines. SAML is much too entrenched in the enterprise way of doing things.<br>
<br>
> So, while I could potentially limit the default released attributes to<br>
> almost nothing, that would erode the benefit i've seen from utilizing<br>
> Anonymous RPs;<br>
><br>
> I'm wondering, has anyone proposed, or does there exist an implementation of<br>
> a whitelist functionality to only enable sending an AuthNResponse to a set<br>
> of approved Issuers? Perhaps sometime of wildcard functionality, etc.<br>
<br>
It seems like you're asking for an either-or capability, which sure sounds like SAML metadata to me.<br>
<br>
> I realize that the answer is probably: get the metadata for the SP and<br>
> configure it in relying-party.xml and disable Anonymous RPs ...<br>
> however, the administrative overhead involved in this is a burden for<br>
> smaller shops.<br>
<br>
All I can say is go read the OpenID Connect spec. In their view, the IdP needs to be smarter about how it responds to AuthnRequests. You start with Zero Trust (TM) and then build up the trust relationship over subsequent requests. Sounds good on paper, I know. How to realize that in practice? I don't know.<br>
<br>
This would be a great question for John Bradley, btw.<br>
<br>
Tom<br>