Bug #68205
closedOpenID services uses incorrect priorities to check returned data
100%
Description
OpenID servers return several identifiers that can be used for user authentication. According to the speciciation openid.claimed_id is authoritative for authentication if it is set. openid.identity can be used but openid.claimed_id is more authoritative.
Usually those two identifiers are the same. But some OpenID servers (namely UNINETT AS server) provide different values for these identifiers. In such cases preferred value is in the openid.claimed_id as defined by the specification. However the code in the OpenID service fails to properly test that because of wrong priorities during checks.
Excerpts from the specification:
---------------------------------------------Claimed Identifier: An Identifier that the end user claims to own; the overall aim of the protocol is verifying this claim. The Claimed Identifier is either:
- The Identifier obtained by normalizing the User-Supplied Identifier, if it was an URL.
- The CanonicalID, if it was an XRI.
OP-Local Identifier: An alternate Identifier for an end user that is local to a particular OP and thus not necessarily under the end user's control.
---------------------------------------------
Section "Positive assertions" (http://openid.net/specs/openid-authentication-2_0.html#positive_assertions):
---------------------------------------------
Positive assertions are indirect responses with the following fields:
...
openid.claimed_id
Value: (optional) The Claimed Identifier. "openid.claimed_id" and "openid.identity" SHALL be either both present or both absent.
Note: The end user MAY choose to use an OP-Local Identifier as a Claimed Identifier.
Note: If neither Identifier is present in the assertion, it is not about an identifier, and will contain other information in its payload, using extensions.
openid.identity
Value: (optional) The OP-Local Identifier
Note: OpenID Providers MAY assist the end user in selecting the Claimed and OP-Local Identifiers about which the assertion is made. The openid.identity field MAY be omitted if an extension is in use that makes the response meaningful without it (see openid.claimed_id above).
---------------------------------------------
Document “Open ID 2.0 to OpenID Connect Migration” (http://openid.net/specs/openid-connect-migration-1_0.html#ImplementationConsiderations) makes a note in the “Implementation consideration section”:
---------------------------------------------
There are OpenID 2.0 libraries that use openid.identity instead of openid.claimed_id to link to the user account at the RP. This is a bug as openid.identity may be recycled. However, there are not many OpenID 2.0 Providers that use different values for openid.identity and openid.claimed_id. Yahoo! and Yahoo! Japan seem to be the only large scale providers that fall under this category. In their case, by stripping out the fragment from the openid.claimed_id, you can get openid.identity. For implementations that are using these buggy OpenID 2.0 libraries, they can adopt this strategy to link Yahoo! and Yahoo! Japan users to their local accounts.
---------------------------------------------
Section 11.5 (https://openid.net/specs/openid-authentication-2_0.html#identifying) of the specification says:
---------------------------------------------
11.5. Identifying the end user
The Claimed Identifier in a successful authentication response SHOULD be used by the Relying Party as a key for local storage of information about the user. The Claimed Identifier MAY be used as a user-visible Identifier. When displaying URL Identifiers, the fragment MAY be omitted.
---------------------------------------------
So all references say that we should use claimed id, not identity.
To follow the specification, fix the issue and preserve the compatibility with any other existing implementation, we should swap checks inside the OpenID service.
Updated by Gerrit Code Review about 9 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41406
Updated by Gerrit Code Review about 9 years ago
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41578
Updated by Dmitry Dulepov about 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 64c67d69ff8dd5a8d8fc0886ff5e17902cf5fded.
Updated by Riccardo De Contardi almost 7 years ago
- Status changed from Resolved to Closed