SAML V2.0 Subject Identifier Attributes Profile V1.0 Draft 02

[Tom Scavo <trscavo@gmail.com>]

The following comments apply to Draft 02 of the SAML V2.0 Subject
Identifier Attributes Profile Version 1.0 (Document ID:
saml-subject-id-attr-v1.0-csprd02).

EXECUTIVE SUMMARY

Beyond the relatively minor suggested edits listed below, I have three
major suggestions regarding the current version of this profile:

1. Add a new “Security Considerations” section that stresses the
importance of authorized scope values

2. Standardize the related but proprietary <shibmd:Scope> metadata
extension element

3. Profile the use of these scoped attributes with the <saml:NameID> element

See the following section for detailed discussion regarding these suggestions.

SUBSTANTIVE COMMENTS

This profile includes an excellent summary of lessons learned (lines
37–47) but it lacks a candid discussion of the potential pitfalls
associated with scoped identifiers. In particular, scoped identifiers
require some type of explicit scope authorization. Failure to do so
may result in access control errors.

This profile intentionally overlooks the use of scoped identifiers in
conjunction with the NameID element. While this may be good advice in
general, I don’t think this profile is the right place to discourage
the use of the NameID element. Doing so renders scoped identifiers
irrelevant for those SAML implementations that lack the ability to
produce or consume SAML Attributes.

The following subsections discuss each of these shortcomings in the
context of this profile.

Security Considerations for Scoped Identifiers

The advantages of scoped identifiers are well documented in this
profile (lines 48–50, 79–80, 221–226) but the disadvantages are mostly
ignored. I think a deployer needs to understand both, especially since
the use of scoped attributes forces an extra layer of security
considerations.

Lines 48–50. “Another requirement perhaps more common to education and
research is the ability for different asserting parties to issue the
same identifier. This is facilitated by ensuring the scope of an
identifier is part of its value and not implicit in a
protocol-specific construct specific to an asserting party.” Scoped
attributes are in fact a double-edged sword. If the SP consumes an
identifier with an unauthorized scope at runtime, the consequences can
be quite serious, that is, an unauthorized user may gain access to a
protected resource.

Consequently, authorized scope values can not be self-asserted (by the
IdP). Either the SP authorizes scopes directly (by appropriately
configuring its SAML software) or authorized scopes are accepted from
a trusted third party (such as a federation operator). In practice,
the SP owner often does both by initially accepting scopes asserted by
a trusted third party while configuring exceptions on a case-by-case
basis.

I think a section entitled “Security Considerations” is needed. This
new section should stress the importance of authorized scope values,
which boils down to this requirement: A relying party MUST NOT accept
unauthorized scoped attributes from a given Identity Provider.

Lines 79–80. “Success with DNS domain-based scoping of values and
managing policy around their use in SAML.” In higher education at
least, the authorization of scoped identifiers currently has an
implicit dependency on a proprietary SAML metadata extension called
<shibmd:Scope>. This metadata extension should probably be
standardized by this profile, otherwise the profile will end up being
specific to higher education. Put another way, if you want this
specification to be relevant outside of higher education, you need to
standardize the <shibmd:Scope> metadata extension.

(If you do standardize the <shibmd:Scope> metadata extension, please
do not allow scope matching by regular expressions in whatever
extension you define.)

Lines 221–226. “This Attribute is a direct replacement for the
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent NameID Format
defined in SAML…” This comparison between the SAML V2.0 Persistent
Identifier and this new pairwise identifier Attribute is accurate as
far as it goes but it is overstated. Scoped identifiers have their own
issues, as noted above.

NameID Considerations

Line 93. “This profile defines a pair of SAML Attributes...” Some SAML
relying parties require the SAML NameID element to hold a long-lived
identifier. Presumably those relying party implementations do not have
the ability to consume arbitrary SAML Attributes. By profiling the use
of SAML Attributes only, this specification becomes irrelevant to a
significant number of SAML deployments.

Lines 280–281. “Tthis specification does not define any syntax by
which the SAML Attributes defined within would be used directly within
the NameID construct.” That may turn out to be a mistake. As mentioned
above, some SAML relying party implementations are simply not capable
of consuming SAML Attributes. Without a well-defined syntax to assert
these identifiers in the SAML NameID element, an IdP deployer will
have no leverage to motivate a relying party to move away from the
SAML V2.0 Persistent Identifier or email address, which are two common
(and suboptimal) NameIDs in use today.

SUGGESTED EDITS

Line 60. s/factually untrue, assumption/factually untrue assumption/

Line 124. s/1 to 127 characters, all either alphanumeric or the equals
sign (ASCII 61) or hypen (ASCII 45)/1 to 127 ASCII characters, each of
which is either an alphanumeric ASCII character, an equals sign (ASCII
61), or a hyphen (ASCII 45)/

Line 126. s/1 to 127 alphanumeric, hyphen (ASCII 45), or period (ASCII
46) characters/1 to 127 ASCII characters, each of which is either an
alphanumeric ASCII character, a hyphen (ASCII 45), or a period (ASCII
46)/

Line 247. s/a relying party MUST express/a relying party
implementation MUST be able to express/

Line 280. s/Tthis/This/

Lines 285–286 s/configured to produce the two identifier
Attributes/configured to produce both identifier Attributes/

Lines 288–289. s/configured to consume neither, either, and
both/configured to consume either or both/

NOTES

For implementers, here is a regular expression for scoped identifiers:

[0-9A-Za-z][0-9A-Za-z=-]{0,126}@[0-9A-Za-z][0-9A-Za-z.-]{0,126}