[Openid-specs-fastfed] FastFed: IdP Discovery
McAdams, Darin
darinm at amazon.com
Wed Oct 17 00:33:12 UTC 2018
Sharing some quick offline feedback with everyone.
A suggestion for "Option 2" is using subdomains.
For example, given the email address "darinm at amazon.com", the discovery logic would:
(1) Check the root domain "https://amazon.com/.well_known/webfinger"
(2) Fallback to a well known subdomain "https://webfinger.amazon.com/" (for example)
The subdomain has a couple benefits. First, the feedback is it can be easier for Corp IT teams to setup. Second, it opens the door to using CNAMES. This can be helpful when organizations use a 3rd party Identity Provider that hosts FastFed configuration for them. Such an org can simply alias their well-known domain to the 3rd party endpoint.
If we pursue this approach, we'll need to decide on the well-known subdomain value.
-Darin
On 10/9/18, 10:57 AM, "Openid-specs-fastfed on behalf of McAdams, Darin via Openid-specs-fastfed" <openid-specs-fastfed-bounces at lists.openid.net on behalf of openid-specs-fastfed at lists.openid.net> wrote:
Hi all,
As mentioned, we’ll be diving into a couple topics. First up is IdP Discovery. This email explains what it is & why the spec isn’t quite right yet.
Context:
-----------------------------
The FastFed flow begins in the Application. At this point in the story, an end-user with proper permissions has decided to establish SSO with their identity provider.
The first step is discovering the IdP. This could be accomplished by asking the end-user to copy/paste a pointer to the IdP. In fact, this mechanism is defined in the spec via the “FastFed URL”. We could make the case this is enough of a major improvement over existing mechanisms and therefore worth delivering alone. However, it would be nice if we could go further and automatically discover the IdP location (when possible) so end-users don’t have to copy/paste. After all, the goal is to make federation dirt simple for non-experts and dropping strange terminology on people like “FastFed URL” isn’t ideal.
We can look to the consumer world for inspiration, such as "Login with Google". In this space, the practical reality is that discovery happens via the NASCAR page in which a list of common Identity Providers is displayed. The user simply clicks one. Behind the scenes, the Application owner has incorporated SDKs and pre-established trust with these providers via an out-of-band registration process.
Unfortunately, this pattern doesn’t transpose cleanly into the enterprise space. First, the Application owner will not know in advance the full set of possible IdPs; it’s not feasible to preconfigure everything. In response, one could argue that implementors may preconfigure a list of popular IdPs (Azure, Okta, etc...) which work with automatic discovery, and then fall back to manual configuration if the IdP isn't listed. However, there is a bit more complexity that makes even this challenging. The complexity arises due to multi-tenancy.
Specifically, it's insufficient to simply select Azure or Okta (for example). The Application needs to determine the specific tenant whom should be permitted to SSO into the application instance. Adding yet more complexity, the current spec needs to discover the IdP tenant upfront and then _whitelist_ that tenant so when the IdP administrator later completes the registration, they are allowed to do so. This advance whitelisting was incorporated to avoid the security risk of passing around a "registration token" that permits anyone to register their IdP with the application instance. Without this control, anyone who intercepts the FastFed exchanges could theoretically be able to set up SSO into somebody else's application. This is a very real possibility in the enterprise space in which many participants are involved in approving the SSO configuration and various workflows or messages can be passed around.
So, in summary, the current spec seeks to (1) Discover the specific tenant of the IdP, and (2) Whitelist that tenant in the app. This happens early in the flow. More details in Section 6.2.1 of the spec.
https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFed-1.0-Draft-01.txt?at=master&fileviewer=file-view-default#FastFed-1.0-Draft-01.txt-1303
As a proposed mechanism to discover the IdP+Tenant, the current spec steals a page from OpenID and describes WebFinger as means to query this information via a user’s email address:
https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFed-1.0-Draft-01.txt?at=master&fileviewer=file-view-default#FastFed-1.0-Draft-01.txt-906
Challenges:
-----------------------------
WebFinger, as described in the spec, presents barriers to adoption.
First, it relies on the existence of a “.well_known” file at the users email domain name. For example, my email is ‘darinm at amazon.com’. So, the discovery mechanism would look for ‘https://amazon.com/.well_known/fastfed’.
In a large enterprise setting, this implies the corporate IT team that manages the IdP infrastructure has to approach the product team which manages the public-facing product and ask them to insert a special file at the ‘.well_known’ location. There would be healthy reluctance to host internal employee metadata in external products, plus cross-org collaboration is a hurdle. I suspect this would be true of most enterprises. In order to be successful, the IdP discovery configuration should be hosted at a location that is owned or easily modified by the same people that manage the IdP itself.
Second, the discovery mechanism adds complexity on Application owners. They must implement code to lookup the provider and handle situations where such queries are slow or timing out. This isn’t a huge amount of work, but in a world where everybody has constrained budgets, every bit of effort reduces the likelihood of adoption. We want to be mindful about the implementation effort.
Options:
-----------------------------
* Option 1 is to totally punt on discovery. Come back to it later as a future extension. In the first release, end-users must explicitly copy/paste a FastFed URL to initiate the process.
* Option 2 is to preserve the current flows, but use a discovery method that avoids the challenges described above. For example, would a DNS entry be easier to adopt? Or, other ideas?
* Option 3 is to completely change the FastFed flows so that IdP discovery doesn't happen up front. I'm not sure how to do that while maintaining an equivalent user experience and security controls. But, if anyone wants to suggest alternatives, it's an option.
_______________________________________________
Openid-specs-fastfed mailing list
Openid-specs-fastfed at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-fastfed
More information about the Openid-specs-fastfed
mailing list