[Openid-specs-fastfed] FastFed SAML Feedback
Nicholas Roy
roy.nicholas at gmail.com
Sun Jun 14 22:49:58 UTC 2020
Hi Darin,
My apologies as well for taking so long to get back to you. My comments are
inline below.
On Wed, May 20, 2020 at 5:24 PM McAdams, Darin <darinm at amazon.com> wrote:
> 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.
>
The enterprise community ignoring parts of the SAML specifications when
convenient is why we're where we are, with a fractured ecosystem which
precludes interoperability. Things might get better if we stopped ignoring
the standard. This is where you'll find a lot of the push-back from the R&E
sector.
>
>
> *>> 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?
>
Yep- not much I can say here except that you're right and it's an
unfortunate situation we find ourselves in with regard to misuse of email
address as an identifier.
>
>
> *>> 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.
>
OK
>
>
> *>> 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.
>
Thanks for the clarification.
>
>
> *>> “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.
>
The point of the way we do federation in R&E contexts is that there is no
need for a human being to be involved. Metadata is automatically
downloaded, cryptographically verified as trustworthy, and used to
configure trusts without a human actor being present. We've been doing it
this way for over 15 years, across tens of thousands of IdPs and SPs.
>
>
> *>> 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?
>
No, given what you've said above about your constraints and use of SCIM as
a primary mechanism, along with SCIM user identifier, I'm fine with this.
>
>
> ---------------
>
> 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?
>
Thanks again - It seems like much of what you intend to do with this
specification could be done with a combination of improved implementations
of existing SAML standards, combined with use of SCIM.
Best regards,
Nick
>
>
> -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> 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".
>
>
>
> 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 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> on behalf of Mike Jones
> via Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
> *Sent:* Thursday, May 14, 2020 8:43 AM
> *To:* Nicholas Roy <roy.nicholas at gmail.com>
> *Cc:* openid-specs-fastfed at lists.openid.net <
> 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> *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
> *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/20200614/8c135db3/attachment-0001.html>
More information about the Openid-specs-fastfed
mailing list