Fast Fed – Making SSO Easier to Set Up. Intro and Looking for Others Who Are Interested

FastFed - Intro and Status

Tuesday 5A Convener: Darin McAdams

Notes-taker(s): Darin McAdams

Tags for the session - technology discussed/ideas considered: SSO Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: The FastFed problem statement was presented. The information is available here: https://bitbucket.org/openid/fastfed/src/4e4a20f183508fd34059de6b93b8bdf23e2e77f8/FastFedIntro.docx?at=master

The table of contents from the current draft specification was also shared. This is available here: http://openid.net/specs/fastfed-1_0.html

The discussion was about the intial feedback on the draft. In particular, the first draft attempted to define a FastFed experience for every common protocol including OIDC, SAML, and SCIM and the combinations of them. The result was essentially too big for anyone to fund and implement.

Therefore, the question discussed was “what not to do” if hard decisions were made on prioritization. In particular, should OIDC be prioritized ahead of SAML, even though most of the SaaS market uses SAML? In this approach, FastFed would become a nudge to move people toward OIDC.

There was little pushback on prioritizating OIDC ahead of SAML. Feedback from IdP and SP providers in the room: some customers are getting off it for security. XML bugs. Move to the future. Or, they want to use Google Logins. SAML is like mainframes - still used, but no one is rushing into it. RocketChat is an example of an app that implemented OIDC before SAML. People building new things are starting with OIDC.

Still provide an extensibility mechanism - not just for OIDC. Enable FastFed to be used for /SAML, of the next new protocol, if there is justification to do that work later.

In the academic space, 10’s of thousands of IdPs. Most academic departments have moved to the cloud. The trend to hosted IdP is going way up.

If FastFed solves user deprovisioning, that’s the key feature in academia. Pure university brings in 100,000 people every year. Don’t want to get to 6 years from now and realize half-a-million people on a service license who are gone. Today, need an out-of-band process for that.

The typical deprovisioning flow is to block access to the app, not delete. Want to assign it to someone in compliance to determine what can/can’t be deleted. One IdP vendor had APIs to support both modes (immediate delete vs block user and retain the data). Customers aren’t choosing the hard-delete option.

Businesses want to preserve, or don’t care until the bill reaches a limit. Business have regulations that make them want to preserve. Only recently have we seen customers start enforcing a higher degree of security and SSO.

In contrast, universities will tend to hard-delete accounts. With tens-of-thousands of students entering/leaving each year, impossible to examine each one. Seeing universities who put together an “update” spreadsheet. Graduating seniors and dropouts uploaded to APIs for deprovisioning. Don’t do it day after finals. They have a flow and timeline.

Two concepts: preserving the data, and preserving the licensed seat. Are SP’s differentiating these two? Not really. Most SP’s have an export process. Workflow is to block user access, then export, then purge. Or, might assign that account to someone else. Some have an additional step of removing entitlements. Kill access, unlicense, but don’t delete anything. Legal - retain documents for litigation and such.