[Openid-specs-fastfed] FastFed SAML Feedback

McAdams, Darin darinm at amazon.com
Wed May 20 23:24:19 UTC 2020 

Really appreciate all the feedback. (And sorry it took so long to reply). It definitely called out a couple clarifications to make. I think I can color in the reasoning for some of the decisions where communities may continue having divergant practices. Let’s see if we can get to common ground.

Before addressing the specifics, I’ll start with general context. We had a few tenets going into the working group. Hope these help illuminate.

Tenet 1)  Solve the enterprise pain points (but don’t preclude usage in other domains)

Despite relying on the same standards, enterprise and higher education have historically diverged in their application. This is natural, as each has unique constraints. That led the education/research community into ecosystems such as InCommon and the eduPerson schema, whereas the enterprise landscape is... well, Wild West. Anyone can launch a SaaS app into the world. Anyone can use it with a credit card. There is no common schema. Anything that causes abandonment is ruthlessly cut. The net result is that enterprise tends to use simple subsets of the protocols, with a limited number of adhoc user attributes. Maybe a name and email. Sign-in usually occurs with an email address or phone number.  When extended attributes are needed, they tend to be enterprise specific, like Cost Center.

Interoperability is a lot harder in this ecosystem. FastFed aimed to solve this problem.

In the beginning, participants from the education/research space were questioning what we were solving. The original answer was “This isn’t for you”. However, upon deeper conversation with experts in the community via forums such as the Internet Identity Workshop, it was determined that some bits could be valuable. For example, the easy user experience. To allow other communities to leverage this, FastFed offers extensibility via Profiles.

The BasicSaml profile included in this spec is for the enterprise community. It would be fantastic if other communities defined their own preferences. For example, a FastFed InCommon SAML profile that referenced existing practices by that community. Similarly, you may want to consider an eduPerson extension to SCIM if that protocol looks useful.

FastFed allows implementors to support any number of these profiles in parallel.

Tenet 2)  Be additive, not transformative

To succeed, FastFed needs to rely on seductive adoption in the enterprise landscape. There is no regulatory force for change. To succeed, the ease of implementation was a key consideration. For that reason, we sought to avoid wholesale changes to existing implementations. Instead, we aimed to be mostly additive. E.g. Adding a new handshake atop what exists, but not forcing people to rewrite their existing SAML and SCIM endpoints.

As a result, the FastFed Profiles largely represent the current practices of the enterprise community. While we may wish those practices were different, that ship has largely sailed. We don’t believe it’s FastFed’s place to mandate a wholesale migration to different SAML practices, nor do we believe that is likely to succeed.

Rather, where the interop profiles require changes, they tend to be small nudges that have big returns on value. E.g. how to include multiple keys for certificate rotation.

Tenet 3) Put the burden on IdPs

If any portions of the spec unavoidably require a fair amount of effort for implementation, we leaned toward putting that burden on the IdPs. The reason for this is that, in the enterprise space, there exists a smaller number of IdP venders (when compared to the thousands of SaaS applications). They are in a better position to invest in the work and see that return.

Tenet 4) Solve the 80% case
FastFed was never going to be for everyone, even in the enterprise space. We prefer to deliver an easy user experience for the 80% of scenarios that can take advantage of it, rather than overcomplicate the spec (and slow down adoption) to handle the long tail.

Tenet 5) Use SCIM as the lingua franca

The enterprise community lacked consensus on a standard user schema. Most applications just made up their own. To align on interoperability, FastFed went with SCIM as the grammar to reference user attributes. This is true even if the application doesn’t run a SCIM server. For example, if the app relies upon JIT provisioning, it will still use the SCIM schema grammar to describe the user attributes. There are no references to eduPerson (although if the higher education community wanted a similar schema, they could define eduPerson extensions for SCIM).

Other Materials
There’s a 20 minute YouTube video that gives a quick overview of the problem statement; including the most common question, which is why this isn’t solved already by OpenID Connect.
https://www.youtube.com/watch?v=ucQl5p6sa4A

There’s also a set of use cases in the FastFed repo that dig deeper into the scenarios that FastFed is solving. (We started with Scenario 1).
https://bitbucket.org/openid/fastfed/src/master/scenarios/

------
I hope that helps illuminate some context. Given that foundation, here are answers to the specific questions.

>> Violates the SAML 2.0 standard by misusing the persistent nameID format

I apologize, but this was just a copy-and-paste error. And, I thank you for catching it.
The intended format was “unspecified”. I recognize this may raise other concerns, so I’ll explain the reasoning (and where we can change). For the most part, the enterprise community just doesn’t care. It ignores the type. The expected inputs are documented elsewhere. If the wrong input is provided, the federation simply doesn’t work.

Since FastFed is opinionated about requiring the SCIM username as the nameId (I’ll come to that next), we could technically call the format “reassignable”. If that was the only blocker to spec approval, that’s an easy change. But, again, most applications just ignore this.

>> Using email address as a user identifier is a practice that is known to be problematic

There’s some trickiness to this one.  A couple factors to call out:
1/ I’ll note that the SCIM username isn’t necessarily an email, but often is. Hence, that was used in the example. But, username != email with any guarantee.
2/ There is no existing persistent identifier in the enterprise ecosystem that all the parties agree upon. The closest is the SCIM externalID, which is the persistent identifier within the IdP that is optionally passed into the Application. But, than can change if an organization migrates to a new IdP provider.
3/ When it comes to SaaS applications, the majority of apps already use email or phone as the identifier. That ship has sailed.
4/ FastFed needs to support JIT scenarios, as well as scenarios where the user was pre-provisioned prior to the SAML authentication. Just a callout to keep in mind.
5/ FastFed is targeting enterprises, and enterprises recycle usernames less often than a social provider like Yahoo. Nonetheless, FastFed encourages mechanisms such as SCIM provisioning to keep applications in sync should it occur. You’ll see the SCIM profile has recommendations for username recycling.

FastFed threads this needle by doing the following:
* Specifying the SCIM username as the subject. Because, it is the only mutually shared value that was guaranteed to be defined, and could also serve as an identifier. And, in fact, is how most SSO setups operate today in the enterprise space.
* Passing the SCIM externalId in the attribute, for additional robustness by those who support it. That’s the persistent identifier within the given IdP.

Given the constraints of the enterprise landscape, is there a different approach to recommend?  One that also stays within the original tenets?

>> Abuses unspecified NameFormat in mapping attributes from SCIM, does not use the proper official names for these attributes (inetOrgPerson).

This is how the enterprise landscape already operates, and there is not consensus that inetOrgPerson is the proper official name in this ecosystem. FastFed improves the status quo by aligning on SCIM as a shared grammar for user schema and attribute names. The binding into SAML is aimed at the audience who wishes to continue using JIT capabilities they already possess, whereas FastFed highly encourages the use of SCIM provisioning for anything more complicated. But, again, these are profiles for an enterprise audience. Other communities can specify different ones.

>> Claims that SAML doesn’t support provisioning of groups is incorrect.

This is my own fault for unclear language. The intent was to say that the FastFed BasicSaml profile doesn’t allow inclusion of groups (not that SAML doesn’t support it). In this particular FastFed Profile, anyone that wants group memberships must use the SCIM provisioning channels.
If another community wishes to define an alternative profile that supports groups, that’s OK too.

>> “No standard mechanism for an identity provider and application provider to directly exchange metadata required by existing standards” is incorrect.

The following sentence after that clarifies the context. A human being is required to act as a data bus between the providers, downloading/uploading the metadata files between the parties. The key phrase in the sentence is “directly exchange”, as the parties can’t talk to each other directly. Can clarify that language if it’s causing confusion.

>> SAML 2.0 has OpenID Connect/OAuth-compatible identifiers that should be used (admittedly, they are new, but all reasonably well-implemented SAML software should be able to support them if configured to do so)

To be honest, I wasn’t sure how to apply this. And, in the enterprise space, most SAML implementations are not reasonably well implemented : )
Given everything discussed so far about the constraints and tenets that FastFed is operating within, is there a specific recommendation for an alternative identifier?

---------------
I apologize for this long response, but hopefully it helps illuminate some of the choices made. Given everything discussed so far, does it lead to any new questions or alternative  takes on the spec?

-Darin

From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net> on behalf of Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Reply-To: Nicholas Roy <roy.nicholas at gmail.com>
Date: Wednesday, May 20, 2020 at 1:43 PM
To: Andrew Jason Morgan <morgan at oregonstate.edu>
Cc: Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Subject: RE: [EXTERNAL] [Openid-specs-fastfed] FastFed SAML Feedback


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


Thank you for following up, Andy.

If there are other questions, Andy and I, and other from the various SAML groups, can try to answer them.

Best,

Nick

On Thu, May 14, 2020 at 12:33 PM Andrew Jason Morgan <morgan at oregonstate.edu<mailto:morgan at oregonstate.edu>> wrote:
Mike (and others),

I've been participating in several working groups related to SAML deployment with Nick.


Let me quote the relevant documents first.

FastFed Basic SAML Profile 1.0 - draft 02, section 4.1.1 states:
The Subject element MUST contain a NameID with the following properties:

  *   A Format set to "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
  *   A value populated with the SCIM userName.
and gives an example value of "babs at example.com<mailto:babs at example.com>".

The SCIM userName attribute is defined in RFC7643 as:
   userName
      A service provider's unique identifier for the user, typically
      used by the user to directly authenticate to the service provider.
      Often displayed to the user as their unique identifier within the
      system (as opposed to "id" or "externalId", which are generally
      opaque and not user-friendly identifiers).  Each User MUST include
      a non-empty userName value.  This identifier MUST be unique across
      the service provider's entire set of Users.  This attribute is
      REQUIRED and is case insensitive.
SAML Core 2.0 (https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) section 8.3.7 defines the qualities of a persistent NameID as:
URI:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

Indicates that the content of the element is a persistent opaque identifier for a principal that is specific to an identity provider and a service provider or affiliation of service providers. Persistent name identifiers generated by identity providers MUST be constructed using pseudo-random values that have no discernible correspondence with the subject's actual identifier (for example, username). The intent is to create a non-public, pair-wise pseudonym to prevent the discovery of the subject's identity or activities.

babs at example.com<mailto:babs at example.com> cannot be a persistent NameID value because it:

  *   is NOT opaque
  *   is NOT generated from a pseudo-random value
  *   DOES correspond (in fact, is) the subject's actual identifier
I don't think you can reasonably interpret the SCIM userName as meeting the requirements of a persistent NameID.  SCIM mentions that userName differs from "id", and "id" has semantics much closer to a persistent NameID.  Please note that I am not as familiar with SCIM as SAML, so my comments regarding SCIM are only superficial.

As an operator of a SAML Identity Provider, I frequently see requests (mostly from vendors) wanting me to send an email address as a persistent NameID.  I refuse to violate the spec and common sense.  Even if we ignore the other semantics of a persistent NameID, email addresses are not persistent.  At most institutions, email addresses can change for various reasons because they are typically based on a person's name.  When we release persistent NameIDs, they are generated from an internal IAM generated unique id value.

Furthermore, the NameID is a poor choice to convey a user identifier because its use is so constrained.  When crafting the requirements in the SAML V2.0 Deployment Profile for Federation Interoperability (https://kantarainitiative.github.io/SAMLprofiles/saml2int.html<https://kantarainitiative.github.io/SAMLprofiles/saml2int.html>), we considered all the available methods of representing user identifiers in SAML.  We decided to require support for the SAML V2.0 Subject Identifier Attributes Profile Version 1.0 (https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.pdf).  This profile defines 2 SAML attributes that are almost identical to the OIDC identifiers.  See sections 3.1.3 and 4.1.3 of saml2int.

Thank you for the opportunity to participate!

Andy Morgan
Identity & Access Management
Oregon State University

________________________________
From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net<mailto:openid-specs-fastfed-bounces at lists.openid.net>> on behalf of Mike Jones via Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Sent: Thursday, May 14, 2020 8:43 AM
To: Nicholas Roy <roy.nicholas at gmail.com<mailto:roy.nicholas at gmail.com>>
Cc: openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net> <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Subject: Re: [Openid-specs-fastfed] FastFed SAML Feedback


It’s my hope that the working group members will now have a dialog with Nick and the others behind this feedback to figure out how to address the feedback.



I’ll start this off by asking for more specifics on 1.  How is the spec misusing the persistent nameID format and what change would those that wrote this feedback suggest to address this issue, Nick?



                                                       -- Mike



From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net<mailto:openid-specs-fastfed-bounces at lists.openid.net>> On Behalf Of Nicholas Roy via Openid-specs-fastfed
Sent: Tuesday, May 12, 2020 2:57 PM
To: openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>
Subject: [Openid-specs-fastfed] FastFed SAML Feedback



Hi,



I've been asked to provide feedback on the FastFed drafts. The following is a roughly compiled, likely incomplete list, which is the result of review of the FastFed SAML profile by some people within the SAML deployment and standards communities I work with. I am acting as a relay. I've requested that others from these groups also join this list, to enable a dialogue about the issues and their potential resolutions.



1.       Violates the SAML 2.0 standard by misusing the persistent nameID format

2.       Abuses unspecified NameFormat in mapping attributes from SCIM, does not use the proper official names for these attributes (inetOrgPerson). This scheme is not interoperability-safe since it is string-based and not oid-based.

3.       Claims that SAML doesn’t support provisioning of groups is incorrect.

4.       “No standard mechanism for an identity provider and application provider to directly exchange metadata required by existing standards” is incorrect. See: https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html#_metadata_and_trust_management and https://kantarainitiative.github.io/SAMLprofiles/saml2int.html#_metadata_and_trust_management. These methods are currently in use by tens of thousands of Identity Providers and Service Providers globally, just within the Research and Education community: https://technical.edugain.org/status.

5.       Using email address as a user identifier is a practice that is known to be problematic (see also: https://celeretech.com/blog/yahoo-begins-recycling-e-mail-accounts/)

6.       SAML 2.0 has OpenID Connect/OAuth-compatible identifiers that should be used (admittedly, they are new, but all reasonably well-implemented SAML software should be able to support them if configured to do so): https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html

Best Regards,

Nick Roy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20200520/5c6e9d28/attachment-0001.html>

More information about the Openid-specs-fastfed mailing list