[Openid-specs-fastfed] WebFinger discovery using subdomains

Tue Jan 14 07:58:11 UTC 2020

>> 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<mailto: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<mailto:matt.domsch at sailpoint.com>>
To: "openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>"
        <openid-specs-fastfed at lists.openid.net<mailto: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<mailto: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><mailto:discovery-it at example.com<mailto:discovery-it at example.com>> and discovery at example.com<mailto:discovery at example.com><mailto: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><mailto:matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>>
mobile: 512-981-6486
www.sailpoint.com<http://www.sailpoint.com><http://www.sailpoint.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20200114/69616166/attachment.html>