[Openid-specs-fastfed] Draft 00 feedback - redirect approach CSRF/XSRF

[McAdams, Darin]

Sorry for just getting around to this. Thanks for the feedback.
I share the worry that we are creating the next great phishing attack vector. Why steal someone’s password when I can just trick an admin into clicking a button and adding my IdentityProvider to a SaaS app?  I can attack with my own password. Neat.

That being said, the status quo is terrible too. Forcing admins to spend a week tearing their hair out to configure federation may be more secure, but no way to live.

We’re on the search for that safe middle ground. We absolutely need more discussions in the security model around these flows, and they could totally change.

Regarding similar approaches like OIDC Dynamic Registration, many of them include a hand-wavy statement like “The server may require an initial access token or credential to initiate the process. How this is defined is outside the scope of the spec.”  They never quite get to the root of trust. There is some out-of-band magic. In practice, that magic can be a frustrated administrator following online instructions and clicking through webforms that vary between providers  in order to establish that trust.  It pushes the problem around. But, perhaps my knowledge of the space is stale.

FastFed doesn’t have the option to pass the buck. No out-of-band magic. No reading of documentation. It’s a human-centric flow that needs to just work. That’s uniquely tricky.

Totally open to other implementation options that deliver the same customer experience outlined in the docs (or close enough to win).


From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net> on behalf of Phil Hunt via Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Reply-To: Phil Hunt <phil.hunt at oracle.com>
Date: Wednesday, November 29, 2017 at 11:23 AM
To: Dick Hardt via Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Subject: [Openid-specs-fastfed] Draft 00 feedback - redirect approach CSRF/XSRF

Darin,

Thanks for putting pen to the discussion and publishing the proposed draft:

  *   http://openid.net/specs/fastfed-1_0-00.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_fastfed-2D1-5F0-2D00.html&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=R4edHOJ4D3y6Io0IIy7FDhWt7otbYR_u-URtfF102-8&s=jlQ7jhJB9MTS8gtpPAGr3YLwrx0_SX56qezj8FK24dM&e=>

While FastFed is very important to my organization, I have substantial worries about FastFed being a two-edge sword and a thus a potential attack vector.

I like the idea, that requests are authorized and initiated using administrator credentials. But in an every expanding scope of relationships, trust based on administrators can be somewhat weak.

Can you comment about how you propose to secure the spec from CSRF/XSRF attacks in the multi-step, multi-redirect process?  In the case of OAuth this has been the single most difficult thing to lock down causing all sorts of new requirements such as we see in FAPI and iGov.

Why not pursue an approach that is more of an evolution of the OIDC Dynamic Registration & Metadata approach that works in the back-channel?

With regards to the metadata and mapping, I think this is a great start.

All the best,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<http://www.independentid.com>
phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20171221/a4fc5d93/attachment.html>