[Openid-specs-fastfed] WebFinger discovery using subdomains

Tue Jan 14 20:13:35 UTC 2020

Hey Karl,

Just as the IT org points their MX record at the SaaS, they could point
their FastFed hostname to a SaaS vendor.

DNS record
fastfed._well-known.corp.example.     CNAME     fastfed.saas.example.

DNSSEC is not available on a large number of TLDs, which makes it a
non-starter.

Having the discovery mechanism in the core FastFed spec does not seem the
right place. Creating it somewhere else is going to add lots of friction.
Perhaps have a separate discovery spec in the FastFed WG that can be
super-ceded when and if a revised "WebFinger" is released?

ᐧ

On Tue, Jan 14, 2020 at 11:55 AM Karl McGuinness <kmcguinness at okta.com>
wrote:

> Thanks Dick and Darin for refreshing my memory.
>
> I agree that the OIDC issuer URI doesn’t neatly align with the user
> identifier suffix in practice.  I support an alternative strategy for
> discovery.
>
> What I was after was a mechanism that didn’t require organizations to host
> a HTTPS endpoint and could just use DNS exclusively.  Dropping a file in a
> S3 bucket unfortunately is foreign to folks still.  My assumption was IT
> orgs today already need to manage MX records for their email addresses in
> DNS.   A great majority of folks use SaaS for their email and delegate to
> MS/Google/etc and also use additional email security gateways that need MX
> routing.  They have a process to publish/manage these DNS records even if
> an engineering org owns the DNS namespace and/or infrastructure.
>
> Supporting a DNS-based mechanism was appealing as it required no
> additional infrastructure, leveraged existing processes, and aligned with
> how they manage records for their user identifier suffixes.
>
> I do agree that if a DNS based approaches requires DNSSEC for security,
> then HTTPS is less friction.
>
> Whatever discovery mechanism we align on, my suggestion is that it should
> probably live outside of fastfed spec so it can be leveraged by any OIDF
> protocol including OIDC for issuer discovery as an alternative to the
> current WebFinger spec (which is what I was originally after)
>
> Thanks,
> Karl
>
>
>
> On Jan 14, 2020, at 10:41 AM, Dick Hardt <dick.hardt at gmail.com> wrote:
>
> *This message originated outside your organization.*
> ------------------------------
> 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/a5eb9dc3/attachment-0001.html>