[Openid-specs-fastfed] FastFed: User Schema
McAdams, Darin
darinm at amazon.com
Mon Oct 15 19:58:08 UTC 2018
As part of the FastFed design discussions, this email dives into the topic of User Schemas.
Context:
-----------------------------
FastFed needs a user schema for two reasons.
First, it seeks to eliminate the friction that arises when service owners make up their own schemas. For example, one SAML provider could want email address labeled as "Email", whereas another wants "EmailAddress", and a third wants "email_address". As a result of the inconsistency, the person configuring SSO must define an attribute mapping for each provider. To eliminate this friction, there needs to be consensus on how to describe attributes and represent them in SSO protocols like SAML and OIDC.
The second reason pertains to consent for data release. To illustrate, it's helpful to contrast with the consumer space. In the world of consumer SSO, consent often happens when a user first authenticates with a provider. For example, the service provider could ask for a set of OIDC claims. The identity provider displays a confirmation page to the user, asking if they consent to release of the claims. Upon confirmation, the authn dance is completed and the service has access to those claims.
In the enterprise space, things are a little different. First, each employee doesn't necessarily consent 1x1 to releasing their data. Instead, one enterprise administrator typically consents on behalf of all employees. This happens up front, when configuring SSO with the provider. So, FastFed needs a way for service providers to declare the attributes they want. The declaration must be available during the configuration flow. Another difference from consumer SSO is that data sometimes needs to be shared immediately, before any employees have logged into the service. This can occur with applications that require pre-provisioning of users with protocols like SCIM. A common example is an email provider that creates inboxes for an organization, before anyone logs in.
In summary, FastFed needs two things:
(1) A consistent schema that everyone agrees on
(2) A mechanism for the service provider to declare their desired attributes when configuring SSO
Challenges:
-----------------------------
Naturally, getting consensus on a schema is hard. Therefore, the current version of FastFed piggybacked on SCIM and recommends SCIM schemas as the lingua franca.
This manifests in a few places in the spec:
(1) In Section 3.3.1, both providers declare which schemas they understand as part of their default capabilities. (See attribute "user_schemas_supported".)
(2) In Section 3.3.4, the application provider declares the attributes they require. (For example, a provider may declare their schema as " urn:ietf:params:scim:schemas:core:2.0:User", but all they want is the "username" and "primary email". This is the section to declare the specific attributes. It powers the consent flows.)
(3) Finally, it's necessary to bind the desired attributes into a specific SSO protocol like SAML or OIDC.
** The last point, #3, is a big open issue in the current spec. **
Details are in each sub-profile. In summary:
The SCIM profile is easy. It just uses the SCIM schemas.
https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFedProfile-SCIM-1.0-Draft-01.txt?at=master&fileviewer=file-view-default
The OIDC profile gives 2 choices. Either the SCIM endpoint as the UserInfo Endpoint (using a draft proposal I stole from Chuck and Phil), or there is a default recipe for binding into OIDC claims.
https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFedProfile-OIDC-1.0-Draft-01.txt?at=master&fileviewer=file-view-default
The SAML profile is TBD. I totally punted until we can discuss as a group.
https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFedProfile-SAML-1.0-Draft-01.txt?at=master&fileviewer=file-view-default
One final feedback I heard is that SCIM is too big a leap for some service providers. Some providers support OIDC with Just in Time provisioning and are relatively happy. They have a consistent schema as defined in OIDC. They only want (1) a standard way to represent enterprise attributes in a OIDC schema, and (2) some notification of user deletion, perhaps via secevents. So, there's an open question about whether to incorporate this simplified mode into the spec. Perhaps letting service providers declare their schema as OIDC while recognizing the doing so precludes use of other protocols like SAML or SCIM.
Discussion Topics:
-----------------------------
(1) Of course, if anyone wants to suggest a totally different way of delivering the user experience, that's open. But, if we continue down the current path...
(2) ... we need to determine how to bind attributes into SAML/OIDC in a consistent way. (*)
(3) And finally, whether to offer an "escape hatch" for service providers that use OIDC, enjoy OIDC, and want to continue using OIDC without additional complexity.
(*) Footnote: In the first version of the spec, providers were permitted to bind attributes into SAML/OIDC in non-consistent, customized ways. There was a description language for performing the transform. For example, the service provider could express that they wanted the SCIM "primary email" represented as a SAML property named "email_address". However, while technically feasible, the effort to implement this was deemed "too big to fund" by early reviewers. I agreed with the feedback.
More information about the Openid-specs-fastfed
mailing list