[Openid-specs-fastfed] FastFed Requirements

Mike Schwartz mike at gluu.org
Wed Jun 7 19:38:53 UTC 2017


More organizations have IDPs then SaaS providers support federated 
authentication. Frankly, SaaS providers only support federated authn 
when they get enough demand from customers, which sort of speaks to the 
ratio I am positing.

I'd be interested to hear from the group... what does everyone else 
think?

- Mike


On 2017-06-07 14:07, McAdams, Darin wrote:
> 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