[Openid-specs-fastfed] FastFed meeting Thursday, Oct 25, 2PM at Boole room, Computer History Museum, MV CA

McAdams, Darin darinm at amazon.com
Thu Oct 4 04:02:11 UTC 2018


Thanks Dick!



To kick things off, I’ve summarized “the story so far” at the bottom of this email. Over the next couple days, I’ll be sharing emails that deep-dive into the listed topics. This gives everyone a chance to contribute even if not attending. Looking forward to the feedback and we’ll see many of you at the meeting.



-Darin





The Story So Far

--------------------------------

The goal of FastFed is to reduce the effort to configure identify federation from weeks to minutes. In addition, it should be doable without reading documentation or knowing identity standards. The ideal experience is a few button clicks in a web-based flow.



The spec is on the second iteration. Here’s a description of the major changes.



In the first iteration, the flow began at the IdP. The assumption was that one person would own the entire configuration, both in the IdP and the SP. In this scenario, starting at the IdP was a nice consistent launch pad for adding new SSO apps into the catalog for an organization. The feedback was this wasn't always a valid assumption. In large enterprises, the administrator of the app may not be the administrator of the Idp. For example, if I were to launch a Salesforce instance, I may need to submit a request to my Corp IT to enable SSO for me. In addition, there are circumstances where the App owner and IdP owner may have no preexisting relationship at all. This can occur in several scenarios such as:



* Business Process Outsourcing - in which an application owner may invite another company to SSO into their app to assist with work.

* Franchise Scenarios - in which a parent organization, like the Girl Scouts of America, invites independently run franchises like Girl Scouts of Washington to SSO into the nationally available shared resources. Each franchise may use different identity providers.



The original IdP-initiated flows made an awkward experience in the multi-admin scenario. As a result, the flows were restructured such that an Application owner initiates the process. If they lack the permissions to modify the IdP side, there is a clean break where the flow can be paused and enqueued (in whatever way makes sense for an IdP), and then finally approved by the proper IdP administrator. In scenarios where a single person administers both the Application and the Idp, the breakpoint is skipped and everything reduces to a seamless experience. Finally, it remains possible to build an IdP catalog of preconfigured apps available for SSO, as seen in many popular IdP providers. The catalog entries would essentially be quicklinks into the FastFed flows for various apps.



In short, we are taking the "Social Login" experience most of us are familiar with through products like Login with Google and bringing that experience to the enterprise world. When configuring SSO, an application owner sees a page that allows selection of an identity provider. They click a few buttons and are done. Or nearly done, waiting for their IT department to approve.



The analogy to Social Login is a convenient mental model, but there are differences between enterprise vs. consumer. These differences give rise to a number of challenges. The remainder of this email summarizes the challenges and each item will be a topic of a future deep-dive email.



Challenge 1) Idp Discovery



In the consumer world, WebFinger was proposed as a discovery mechanism but never really got traction. As a result, we have today's world; a handful of providers with critical market share. If a consumer wants to use an IdP that an app doesn’t support, tough luck. Tough luck isn't a valid answer in the enterprise space. We need a working discovery mechanism and/or means to specify an IdP manually. Compounding the problem is multi-tenancy of cloud IdPs. It’s insufficient to just discover the provider. Knowing it’s Okta, Azure or GSuite isn’t good enough. We need the specific tenant of the provider.



Challenge 2) Schema



In the consumer space, OpenID claims have become a lingua franca. Enterprise remains fragmented across SAML, OIDC, and SCIM, and many applications just make up their own schema. There is no consensus. As a result, admins are on the hook for attribute mapping. We need a lingua franca to remove the attribute mapping burden. There are open questions on that lingua franca and how it gets represented inside SSO protocols like SAML and OIDC.



Challenge 3) User Provisioning



Enterprises want to quickly deprovision users upon termination of employment. Many apps also require pre-provisoning. This necessitates a way to specify the provisioning needs of an application. And, though SCIM is a go-to choice, there has been feedback that not all applications are able to take that leap. Even those who do seek guidance on which portions of the SCIM spec are necessary to implement.



Challenge 4) Key Rotation



The first question I often receive when explaining FastFed to others is "Will it help with SAML certificate rotation". Enterprises want automated rotation of secrets without downtime. Instructions for key rotation aren't formally specified for either SAML or OIDC. Because the goal of FastFed is to make federation easy to setup and maintain without knowledge of the underlying protocols, key rotation instructions have leaked into the FastFed profiles.



Challenge 5) Metadata Refresh



Providers exchange metadata, including icon images. These images can appear in places like application catalogs vended by IdP’s. Should there be a mechanism to automatically update icon images and other metadata?


From: Dick Hardt <dick.hardt at gmail.com>
Date: Wednesday, October 3, 2018 at 6:10 PM
To: "openid-specs-fastfed at lists.openid.net" <openid-specs-fastfed at lists.openid.net>
Cc: Nat Sakimura <n-sakimura at nri.co.jp>, "McAdams, Darin" <darinm at amazon.com>
Subject: Re: FastFed meeting Thursday, Oct 25, 2PM at Boole room, Computer History Museum, MV CA

Reposting message as list manager rejected previous message as it had too many recipients ...

On Wed, Oct 3, 2018 at 4:58 PM Dick Hardt <dick.hardt at gmail.com<mailto:dick.hardt at gmail.com>> wrote:
Hey everyone!

Reminder about the meeting that is at the tail end of the Internet Identity Workshop (who have graciously allowed us to use one of their rooms).

2 - 5PM, Thursday Oct 25
Boole Room
Computer History Museum
1401 N Shoreline Blvd, Mountain View, CA 94043

Latest drafts are at https://bitbucket.org/openid/fastfed/src

/Dick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20181004/9c4e92b9/attachment-0001.html>


More information about the Openid-specs-fastfed mailing list