Hello everyone,
Version 0.9.8 of the openid4java library is now released.
The main update is a security-related enhancement that concerns OpenID
Providers. See below for a more detailed description of the issue.
-----------------------------------------------------------------------
Shared vs private server association stores:
A significant number of active OpenID Providers are configured with the
same association store for both the private and shared associations for
their ServerManager instances - this allows an attacker to forge OpenID
assertion responses and hijack user accounts at Relying Parties.
OpenID4Java's default in-memory association store implementation and
configuration are safe, however the API documentation did not clarify
that clients wishing to use alternative store implementations must
provide different instances for the two stores.
Documentation was updated and a check was put in place to ensure that
direct verification is rejected if the supplied association handle (that
should exist only in the private store) is also found in the shared
association store.
The following test framework can be used to verify if an OpenID Provider
exhibits this vulnerability:
http://testid.net/OP/CheckAuthSharedSecret.aspx
For OpenID Providers that are vulnerable to this attack openid4java will
start rejecting all direct verification requests after upgrading to
version 0.9.8 and until the configuration is fixed by providing
different instances for shared/private associations to the ServerManager.
-----------------------------------------------------------------------
The new version is available for download from the project's home page:
http://code.google.com/p/openid4java/downloads
and can also be easily included in your projects using maven:
http://code.google.com/p/openid4java/wiki/MavenHowTo
-----------------------------------------------------------------------
Notable changes since the previous version:
Updated API documentation for private/shared association stores.
Add flag and check that shared associations are not accepted as private
in direct verification requests.
Don't mandate that a separate userSetupUrl must be provided to the
ServerManager, fall-back to the OP endpoint URL.
Shuffled ServerManager.authResponse processing to only raise (some)
errors when they affect the response.
Allow specifying a preferred alias when adding an extension.
-----------------------------------------------------------------------
Thanks again to everyone who contributed, either directly or with
feedback and bug reports!
Johnny