[Openid-specs-fastfed] FastFed SAML Feedback
Andrew Jason Morgan
morgan at oregonstate.edu
Thu May 14 18:33:23 UTC 2020
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/20200514/eef3d58c/attachment-0001.html>
More information about the Openid-specs-fastfed
mailing list