Open ID Foundation – Fast Fed & DIDC Federations = Enough Similarities to Share/Merge?

From IIW

FastFed & OIDC Federation: Enough similarities to share/merge?

Wednesday 3D

Convener: Darin McAdams and Roland Hedburg

Notes-taker(s): Darin McAdams

Tags for the session - technology discussed/ideas considered: SSO, Federation, OIDF

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

FastFed and OIDC Federation are two standards under the Open ID Foundation. This session examined the similarities/differences between the goals and how they should align. This was done by enumerating the market segments and goals for each spec.

FastFed went first. The initiative originated from the commercial/enterprise space. In this world, a company may use an IdP such as Google/Azure/Shibboleth/ADFS... The company may also use SaaS apps such as Salesforce, DropBox, etc... Today, setting up SSO between an IdP and a Saas app can take 1-2 weeks by an enterprise administrator. Goal of FastFed is for it to take 1-2 minutes.

To achieve this target, FastFed aims for the following measures of success:

  • Configuring SSO is self-service by the enterprise administrator. No need to talk to anyone at the IdP or SP.
  • No identity knowledge required. An administrator shouldn’t need to understand SAML or OIDC; this is largely abstracted away.
  • Mouse clicks only. Administrator don’t need to read documentation, copy and paste values into forms, or upload/download files. A simple wizard experience.
  • Solve both SSO and User Provisioning

Assumptions:

  • The administrator(s) have existing accounts at the IdP and SP for their company.
  • IdP provides the governance controls about what administrator(s) can do. For example, a member of the organization can be given permission to configure SSO to all apps, or to a specific type of app like “Salesforce”. This is defined and controlled within the IdP. Out of scope of FastFed.

NOT Goals:

  • Trust relationships between the IdP and SP. There is no relationship between these parties, no compliance schemes. An enterprise decides what they want to use.
  • No SSO Metadata validation, except for the following:
    • Knowing “This is a Salesforce app” so the IdP can enforce access controls for administrators around whether they are permitted to configure SSO to Salesforce (or whatever app).
    • Redirect URIs are valid for the app vendor. E.g. Salesforce only uses Salesforce URLs for redirects. Basic security stuff.

Problems to be solved in order to achieve these goals with OIDC:

  • Dynamic Client Registration: how to make it self-service by an administrator? How does the SaaS app attain the registration endpoint and initial access token?
  • User Schema: Need a shared schema to avoid asking the administrator to specify attribute mappings. OIDC schema is insufficient. SCIM has EnterpriseUser, but no finalized specs for binding SCIM->OIDC
  • Trusted way for Salesforce to prove “I’m Salesforce” during the SSO configurations flows.
  • User Provisioning: How. (SCIM?) When. (JIT, Pre, Other?)

Next, OIDC Federation took the floor to explain the goals. In essence, everything that FastFed specified as “NOT a goal” is what OIDC Federation took as an explicit goal. No overlap. It’s seeking to bring the federation concepts from SAML into OIDC protocols (e.g. InCommon) Proposal is to sign the OIDC metadata statements to prove compliance and membership in various federations. OIDC Federation is focused on sectors like higher education.

The remainder of the discussion was about the different market segments, how they behave, and whether some customers may desire both FastFed and OIDC Federation (short answer: yes, and the two standards should play well together).

Q) How does someone join a federation? There is an audit, either on-prem or self-certified. Goal is to prove this audit happened.

Q) What is a use case for RP to depend on OP in federation. Student taking classes at another university.

Q) How to discover the OP for a user? OIDC Discovery doesn’t really work. They might all have gmail addresses. May force people to specify a university name, or select from drop-down. Universities just own identities, can rely on other service providers like google for authentication.

Q) User Schemas? Still a hard problem. It’s a mess.

Q) Is anyone looking at defining a SCIM schema for the educational sector?

Still need to define a standard set of claims in educational sector. One thing in progress within Internet2. Search for: “APIs and Schema — The Relationship between TIER and SCIM”.

If we can all agree to use SCIM for user schema modeling, then the problems becomes one of binding SCIM to OIDC and we can all share. No need to define yet-another-user-schema in OIDC.

Retrieved from "https://iiw.idcommons.net/index.php?title=Open_ID_Foundation_–_Fast_Fed_%26_DIDC_Federations_%3D_Enough_Similarities_to_Share/Merge%3F&oldid=21529"