[Openid-specs-fastfed] WebFinger discovery using subdomains

Tue Jan 14 18:41:15 UTC 2020

Darin: I think your suggestion is the best approach, given where the world
is.

Karl: as I am sure you know, the OIDC methodology has not enabled easy
discovery. The OIDC issuer in practice has not been discoverable. Google's
issuer is https://accounts.google.com and discovery is at at
https://accounts.google.com/.well-known/  -- it is not obvious that a
google.com email address would have an issuer at https://accounts.google.com

Microsoft discovery documents are even more confusing:

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

It would appear that the https://{provider}/.well_known pattern has not
been adopted, and that metadata documents are off of a different subdomain.

Since using a subdomain is clearly what the industry wants to use, a
standardized subdomain mechanism will allow automatic discovery. An
advantage of DNS is that a hostname can point to another hosthame, allowing
an organization to delegate the management of the contents to a service
provider.

While IETF may be cranky, the current model for discovery is not working.

On Mon, Jan 13, 2020 at 11:58 PM McAdams, Darin via Openid-specs-fastfed <
openid-specs-fastfed at lists.openid.net> wrote:

> >> FastFed is not following the pattern of just publishing a .well-known
> discovery resource...  The discovery flow would have been the same as OIDC;
> find the issuer for the email, then fetch the
> {issuer}/.well-known/fastfed-metadata resource.  The only reason I can
> think of why this pattern wasn’t chosen was to enable the OpenID issuer to
> be a different host than FastFed metadata...
>
>
>
> It was actually a bit different. To illustrate, consider our email
> addresses. Mine ends with “@amazon.com”. Erik’s is “@google.com”.
> Adhering to the prior pattern would necessitate hosting files at “
> https://amazon.com/.well-known/...” or “https://google.com/.well-known/...
> ”.
>
>
>
> Those are customer-facing website properties, run by product engineering
> teams. They are not generally accessible by internal enterprise IT.
> Therefore, asking for workforce discovery metadata to be hosted from the
> core public properties is a hefty organizational friction, regardless of
> whether the purpose is for OIDC or FastFed or whatever. It crosses trust
> boundaries we generally don’t want to cross, and requires access that
> people don’t have.
>
>
>
> We believe this is not unusual in large enterprise environments, causing
> the classic “.well-known” approach to be a non-starter for enterprise SSO.
>
>
>
> In contrast, enterprises find subdomains easier. It’s not unusual for
> enterprises to create subdomains (and DNS zones) which are delegated to
> portions of the enterprise.
>
>
>
> Agree that DNS TXT records would be easiest, hosted at a subdomain. Absent
> that, the next easiest would be hosting a static file. For Amazon, that
> means we’d simply drop a file in S3, for example.  To enable that, it would
> be nice to specify a location such as “https://fastfed._
> well-known.amazon.com” which can simply point to the S3 file.
>
>
>
> The use of WebFinger protocols in the FastFed spec has remained because,
> in very limited circumstances, some enterprises wish to vary the answers
> for different users under a single email domain. A full-fledged WebFinger
> server enables that flexibility. However, since I suspect most don’t need
> it, it would be ideal to allow a simpler-to-implement mechanism for
> enterprises.
>
>
>
> Personally, I like the approach of “https://{resource}._well-known.{issuer}/”.
> It’s simply an inversion of the OIDC approach, using subdomains instead of
> paths. We anticipated pushback from IETF-land, but since no other
> shovel-ready approach was identified, the outcome of the IIW discussion was
> to ask forgiveness instead of permission. It’s something I’m toying with
> while revising the spec with latest feedback.
>
>
>
> *From: *Openid-specs-fastfed <
> openid-specs-fastfed-bounces at lists.openid.net> on behalf of
> Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
> *Reply-To: *Karl McGuinness <kmcguinness at okta.com>
> *Date: *Thursday, December 19, 2019 at 5:56 PM
> *To: *Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
> *Subject: *Re: [Openid-specs-fastfed] WebFinger discovery using subdomains
>
>
>
> Hi Matt,
>
>
>
> I was thinking that something similar to
> https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01  that is
> DNS based would be defined as an extension to
> https://openid.net/specs/openid-connect-discovery-1_0.html.   Each
> service that supports discovery in OIDF such as FastFed would register its
> URI (rel) in a common OIDF managed registry.   This would enable the
> service to be discoverable via DNS or HTTP API.
>
>
>
> If we expect each OIDF service to be owned/hosted by different
> administrators, then having a DNS record per service has advantages.  If we
> expect the majority use case to be the same administrator then there is
> simplicity in having just one TXT record with a tag for each service.
>
>
>
> I would have expected that in most deployments the FastFed metadata
> provider is the same host as the OpenID provider (issuer).  FastFed
> endpoints defined in the metadata could always be different.  This must not
> be the case as FastFed is not following the pattern of just publishing a
> .well-known discovery resource like OpenID, RISC, etc off the issuer.  The
> discovery flow would have been the the same as OIDC; find the issuer for
> the email, then fetch the {issuer}/.well-known/fastfed-metadata resource.
> The only reason I can think of why this pattern wasn’t chosen was to enable
> the OpenID issuer to be a different host than FastFed metadata such as
> common issuer but tenant-specific fastfed metadata.
>
>
>
> I agree with you on the DNSSEC requirement,  it will prevent adoption due
> to deployment friction.  This may be a deal breaker itself as without
> integrity of DNS its possible for an attacker to mix-up the FastFed host
> returned via DNS and attempt to have the administrator federate the service
> with their provider.   Not sure how this will play out in practice as
> having folks copy/paste or click URLs in docs/emails to bootstrap FastFed
> flows has its own problems.
>
>
>
> -Karl
>
>
>
>
>
> On Thu, Dec 19, 2019 at 4:00 AM <
> openid-specs-fastfed-request at lists.openid.net> wrote:
>
> Message: 1
> Date: Wed, 18 Dec 2019 20:42:38 +0000
> From: Matt Domsch <matt.domsch at sailpoint.com>
> To: "openid-specs-fastfed at lists.openid.net"
>         <openid-specs-fastfed at lists.openid.net>
> Subject: Re: [Openid-specs-fastfed] WebFinger discovery using
>         subdomains
> Message-ID:
>         <
> SN6PR04MB5168A044A14C5E80E18755F9F2530 at SN6PR04MB5168.namprd04.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> I certainly think that discovery via a well-known DNS entry is simplest
> for most organizations with the common config of having a single IDP for a
> single domain name.  Sanz does allow for records to be scoped by email
> address as well, should that need arise, though I?d consider it DNS
> pollution to have to put all email addresses into DNS for this discovery
> purpose when few would in practice be used. Maybe a BCP specifies an email
> address to be used for such discovery (e.g. discovery-it at example.com
> <mailto:discovery-it at example.com> and discovery at example.com<mailto:
> discovery at example.com> when multiple IDPs are in use for subsets of the
> population.
>
> Karl, would you expect to add a new tag=value pair the _openid TXT record
> specified in Sanz, or create a new _fastfed TXT record, similar to but
> separate from _openid?  Given that FastFed uses, but it separate from,
> OIDC, SAML, and SCIM, I?d think the latter would be most appropriate, and
> would require the least coordination with other WGs and standards bodies.
>
> My only concern with DNS comes from Sanz section 5, which requires DNSSEC
> to be valid.  In practice this is still not widely-enough used.
>
> Thanks,
> Matt
>
> Matt Domsch
> VP, Lead Corporate Architect
> matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>
> mobile: 512-981-6486
> www.sailpoint.com<http://www.sailpoint.com/>
>
> _______________________________________________
> Openid-specs-fastfed mailing list
> Openid-specs-fastfed at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fastfed
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20200114/32401e51/attachment.html>