[Openid-specs-fastfed] FastFed Requirements

McAdams, Darin darinm at amazon.com
Wed Jun 7 19:07:35 UTC 2017


That’s a good summary. As always, there are devilish details in the reqs.

Since there are many paths to meet requirements, I realize it would be helpful to enumerate the underlying tenets that drove the original approach. Mike – I don’t mean to interrupt the OTTO discussion, but it would be good to ensure we have alignment on these, too. Else, it’s easy to get stuck. Here’s the angle I came from. Does the group think these sound right?

###############################################
# Tenet 1) Solve the Commercial SaaS Market
###############################################

This is about establishing SSO from enterprises to well-known products like DropBox, Workday, GoToMeeting… and thousands more.
This market has the following properties:

* No shared schema
  Each service provider defines the attributes they want, and how they are formatted on the wire.

* Minimal data requirements
  Typically, services only need a handful of attributes such as name, email, and mobile phone number.

* No trust federations
  Anyone can launch an IdP/SP. No certifications and no circle of trusts.

Because of these properties, setting up SSO requires a middle-man to connect the dots between the IdP and SP. By introducing a shared vocabulary for schemas and mappings (in machine readable formats), the effort can be reduced.

###############################################
# Tenet 2) Don’t Preclude Other Markets
###############################################

Other markets are different. For example, within the US educational sector, InCommon is a collective whose members agree to common schemas and can attest to shared compliance regulations. Other regions have similar federations.

Due to these preestablished agreements, the educational sector does not necessarily share the same pain points as the commercial market. In talking to members of this community, there was minimal interest in FastFed. However, should that change in the future, FastFed seeks to avoid decisions that block adoption in other segments.

###############################################
# Tenet 3) Advocate for the Admin
###############################################

Multiple actors participate in a SSO connection: the IdP, the SP, and the enterprise administrator who ultimately controls the configurations for their org.

FastFed’s priority is the user experience for the enterprise administrator. We strive to make this experience fast, easy to understand by non-Identity experts, and hard to get wrong.

###############################################
# Tenet 4) Push Implementation Complexity onto IdPs
###############################################

Or, inversely, “As Simple as Possible for SPs to Implement”.

The success of any specification depends on adoption. With FastFed, this means IdPs and SPs agree to do work. The biggest risk is service providers. There are thousands of them and growing. They are staffed by people who usually aren’t Identity experts, who are stretched thin, and who won’t necessarily share our motivations. To succeed, it must be trivial for non-experts to understand, deploy, and operate a FastFed-compliant service.

On the other hand, there are a small number of IdPs. They tend to be identity experts, and many are motivated to solve this problem (presumed by membership in this working group).

As a result of these dynamics, we lean toward pushing complexity of implementation into the IdPs.

###############################################
# Tenet 5) Purely Additive for SPs
###############################################

As part of the goal to make implementation as easy as possible for SPs (see previous tenet), the adoption of FastFed should not mandate that service providers modify existing implementations. For example, if the service expects a SAML assertion with user attributes labeled as “full_name” and “email”, they can continue to run in that manner.

This tenet is expressed as “FastFed is purely additive”, meaning it requires the introduction of new APIs and metadata, but doesn’t change existing federation endpoints.  (For example, the SP can vend a mapping that tells the IdP to send the SCIM value “name.formatted” in the form of a SAML attribute with type=“Unspecified” and name=“full_name”.)
###############################################
# Tenet 6) Support Multi-Tenancy
###############################################
Hosted services are typically multi-tenant.  FastFed must support both single-tenant and multi-tenant IdPs and SPs.

Multi-tenancy introduces complexity in how the SP and IdP communicate with each other. Before releasing information to another party, the tenant must authorize release of their private information, and that authorization must be enforced.

###############################################
# Tenet 7) Be Opinionated on Best Practices
###############################################

Providers want guidance on how to implement SSO endpoints. In the spirit of Tenet #3 (Advocate for the Admin), the FastFed specification will recommend practices that reduce the burden on administrators. For example, suggesting that service providers support automatic SAML certificate rotations without any downtime.

Because perfect shouldn’t be the enemy of the good, the best practices that are outside the core FastFed registration experience will be specified as “should” instead of “must”.




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

From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net> on behalf of "openid-specs-fastfed at lists.openid.net" <openid-specs-fastfed at lists.openid.net>
Organization: Gluu
Reply-To: Mike Schwartz <mike at gluu.org>
Date: Wednesday, May 31, 2017 at 8:19 PM
To: "openid-specs-fastfed at lists.openid.net" <openid-specs-fastfed at lists.openid.net>
Subject: [Openid-specs-fastfed] FastFed Requirements


From reading the spec, here is the list of requirements I gleaned:

1.   Machine readable format to expedite provisioning.
2.   Express whether SP requires user pre-provisioning
3.   User Schema: specify attribute identification
4.   User Schema: specify if required by RP
5.   User Schema: specify attribute format requirements
6.   User Schema: specify mapping / equivalency
7.   User Schema: Subject identification / naming requirements
8.   Expiration / Rotation of entity certificates used for trust
9.   Expiration / Rotation of RP credentials
10.  Client / SP registration requirements
11.  User Schema: support for custom requirements
12.  Specify required features of federation protocols (ignore esoteric 
SAML)
13.  Specify which protocols are supported
14.  How to obtain a software statement (token) for OpenID Connect 
Registration
15.  Publish location of federation configuration files (dynamic or 
static)
16.  Enable configuration of access rules for an RP

Did I miss anything?

- Mike

_______________________________________________
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