Anyonymous relying parties
Tom Scavo
trscavo at gmail.com
Thu Dec 12 00:30:12 EST 2013
On Wed, Dec 11, 2013 at 11:00 PM, Sean McHugh <sean8sean at gmail.com> wrote:
> I've recently discovered the joy of Anonymous relying parties as my Shib IdP
> infrastructure has now grown.
>
> While I find it convenient to utilize this as a way to reduce overhead in
> managing SPs, I've grown more concerned about the potential for abuse:
>
> in theory, one could coax a user to a URL configured to send a proper
> AuthNRequest to my IdP, thereby capturing attributes released by default
I understand both points of view, yes. Of course the two perspective
are at total odds with each other.
> Am I correct here? Is there documentation or a collection of thoughts on
> other potential security concerns surrounding Anon RPs?
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.
> So, while I could potentially limit the default released attributes to
> almost nothing, that would erode the benefit i've seen from utilizing
> Anonymous RPs;
>
> I'm wondering, has anyone proposed, or does there exist an implementation of
> a whitelist functionality to only enable sending an AuthNResponse to a set
> of approved Issuers? Perhaps sometime of wildcard functionality, etc.
It seems like you're asking for an either-or capability, which sure
sounds like SAML metadata to me.
> I realize that the answer is probably: get the metadata for the SP and
> configure it in relying-party.xml and disable Anonymous RPs ...
> however, the administrative overhead involved in this is a burden for
> smaller shops.
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.
This would be a great question for John Bradley, btw.
Tom
More information about the users
mailing list