[Openid-specs-fastfed] FastFed vs. OpenID Federation

McAdams, Darin darinm at amazon.com
Thu Oct 4 21:58:24 UTC 2018


Continuing the FastFed discussions, a common question is how FastFed relates to OpenID Federation. (https://openid.net/specs/openid-connect-federation-1_0.html)

Roland and I did a session at the previous IIW to dig in. Thought it worthwhile to share notes with the FastFed group. Short answer: They are disjoint but complementary. Each solves different problems. Full notes are at the bottom of the email.

Any easy source of confusion is the overloaded use of the word “federation” for different purposes. Most people in the group are aware of this, but I’ll quickly summarize for anyone who finds this thread in the archives or is just ramping up in the space. In the enterprise world, federation typically refers to leveraging an existing corporate directory for SSO into 3rd party SaaS apps like Salesforce. However, there is another world of higher education and research that uses the word differently. In this domain, there are privacy requirements about sharing data regarding students & faculty.  For schools to collaborate with each other, or use 3rd party apps in a way that exchanges identity information, they must attest they meet the necessary compliance requirements. This is often done by undergoing an audit with some group and then using a form of attestation to prove they are “legit” and able to participate. As a side effect, these groups often align on a common schema as well, to make interoperability easier. A well-known example in the US is InCommon: https://www.incommon.org/

FastFed is focused on the former enterprise domain, making it easy to configure SSO to SaaS apps. OIDC Federation is focused on the latter scenario. Specifically, OIDC Federation is defining a way to sign OIDC metadata so that a provider can prove they are a legitimate member of the InCommon club, or the equivalent in other countries.

There is overlap in that both want a common schema for user data. But, otherwise, it’s two different goals.

Below are the detailed session notes.

-Darin

Session Notes from IIW #26 on May 4, 2018
----------------------------------------------------------------
Wednesday 3D
Convener: Darin McAdams and Roland Hedburg
Notes-taker(s): Darin McAdams
Tags for the session - technology discussed/ideas considered: SSO, Federation, OIDF

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 beyond what's required in the basic specs.

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”.




More information about the Openid-specs-fastfed mailing list