Introduction
The current implementation of OpenID support for PLFM is restricted to using Google.com as the provider. This is a side-effect of how OpenID support was implemented. The security of the current implementation depended on the OpenID provider to pass along a user's email address as part of authentication because the email address was used to resolve the caller to a Synapse ID.
Since this is not how OpenID was designed to be used, other OpenID providers would not guarantee a users email address. So as long the implementation depends on the OpendID provider to provide the user's email address, only Google can be used as a provider.
Alternative Implementation
An alternative implementation is to allow a user to "bind" any of their OpenIDs to their Synapse account. However, this changes the authentication work flow because the user must first authenticate with Synapse using some other means (like password, or API key) and then bind the OpenID to their account. Once the OpenID is bound to an account the user can log-in using this OpenID.
New OpendID REST calls
| HTTP TYPE | Response | URL | Request | Description |
|---|---|---|---|---|
| POST | Session | /openId/authenticate | QueryString | After completing the OpenID communicatoin with an OpenID provider, the resulting query string is passed to this service. If the signature is valid and the OpenId is bound to a Synpase user the Session token will be returned (200). If the signature is not valid a 401 will be returned. If the signature is valid but the OpenID is not bound to a user a Precondition Failed (412) will be returned. For the latter case, the caller must first authenticate with another method and then bind the OpenID to a user providing both a valid session token and query string from the OpenId provider. |
| POST | String | /openid/bindID | Session, QueryString |