Use cases
A number of cases have arisen in which an external application needs to access user data in Synapse.
1) OneMind Portal
The OneMind Portal is a web-based aggregator of applications, one of which is Synapse. One goal is single-sign-on, such that users can sign on with any of a variety of web-based identities, and automatically be signed on to each of the aggregated applications. The OneMind Portal uses Janrain, which allows users to sign-on with any of Google, LinkedIn, Twitter, etc., and to "link" their accounts together so that, for example, logging in with Twitter causes them to also be logged in to LinkedIn and Google. The missing piece is to allow a OneMind Portal user to "link" their Synapse account, so that logging in with Janrain causes them to be logged into Synapse.
2) Shiny integration
Shiny is a web-based generator of web-viewable R content, e.g. interactive graphs. Synapse allows Shiny content to be embedded in its web UI. To generate content, an Shiny app may need to access data which is private to a user. So the Shiny app needs a way to be authorized to access the relevant user data, without having all of the user's authority. This is a classic OAuth scenario.
2a) IBM whole cell parameter estimation (WCPE) challenge
The WCPE Challenge is working to implement a way for participants to interactively build up a set of files that they will be granted access to by the Shiny widget. Ideally, this would require the Shiny app to know, via some authentication method, exactly who the user is that is visiting the embedded application. Currently, the work around will be to pass the principalId of the user, but not the sessionToken. This is a sufficient work around for this one use case, but further integration with Shiny (see below) will warrant full auth cross-talk.
2b) Fred's use case
In this case, a visualization of a patient's genomic profile (via Shiny) is to be displayed to the research team. Since this visualization contains sensitive (private) information, the web app needs to be locked down to specific users. A shared auth system would be ideal for this scenario.
3) IBM whole cell parameter estimation (WCPE) challenge: This is not an immediate need, but in discussion about the challenge the use case came of how a 3rd party app could get a user's Synapse principal ID. One way is to give the app the user's session token (or API key, or password), but this is too powerful.
4) Galaxy Integration
Our UCSC contacts mentioned that we might integrate Synapse with Galaxy such that from Galaxy someone can connect to Synapse and retrieve data. UCSC has done similar integration work with Galaxy in the past. http://wiki.galaxyproject.org/Learn/UCSC%20Galaxy%20Integration
Possible Architectures
The following is a survey of identify providers and the protocols/architectures they use to allow third party integration.
| Identity Provideer | Architectural Approach / Protocol | Comments |
|---|---|---|
OpenID, OAuth 2.0 | Synapse currently uses OpenID to authenticate with Google. | |
OAuth https://developers.facebook.com/docs/reference/dialogs/oauth/ | ||
OAuth | ||
| Yahoo | OpenID, OAuth, and OpenID-OAuth Hybrid | |
| Flickr | Home grown: | The authentication service is similar to that which we have recently added to the portal. Flickr's approach suggests security improvements, e.g. requiring the relying party to use an API key to identify itself. |
| Blogger (Google) | OAuth 2.0 https://developers.google.com/blogger/docs/2.0/developers_guide_protocol#Authorizing |
It seems like the consensus is that OAuth is the way to go.