[DAS] Personal genomics/Deploying a DAS server for Dummies/6 Easy steps

[Andy Jenkinson]

On 12 Jan 2012, at 18:08, Dan Bolser wrote:

> On 12 January 2012 17:07, Andy Jenkinson <andy.jenkinson at ebi.ac.uk> wrote:
>> Great stuff Jon!
>> 
>> On 12 Jan 2012, at 15:31, Jonathan Warren wrote:
>>> 
>>> On 12 Jan 2012, at 13:43, Dan Bolser wrote:
>>> 
>>>> I want to be able to specifically grant access to my data by a known third party.
>>> 
>>> We had large debates about how to implement security in DAS at the last couple of DAS workshops. In the end it was decided we would go with BASIC authentication and https requests and responses and people would have to trust DAS clients with their username and passwords.
>> 
>> I believe those providers use (or are migrating to) a common authorisation protocol based on OAuth. This type of authorisation actually only allows you to control which -applications- have access to your data, not which individuals. That means each individual client needs to be configured for this purpose. Really what is needed is an end-to-end solution across both clients and servers, with a common authentication/identification mechanism and across multiple providers. Particularly the authentication part is difficult because, for technical reasons, we can't use OpenID. It'd be great and there are potential solutions, but the "activation energy" and coordination required is quite high.
> 
> AFAIK, using something like the above, you authenticate with the
> client using OpenID, and the client is authenticated to access your
> data via OAuth. You can then build your client to allow various levels
> of sharing with other users in the system, as with FB.
> 
> Would building OAuth into Proserver, then identifying with OpenID be a
> way round the 'technical reasons' you described above? Or is it just
> running in circles?

Originally I wanted to use a combination of OpenID and OAuth as an end-to-end solution. However, OpenID is based around the expectation that you are authenticating with a website using a browser - the protocol uses HTTP redirects, and OpenID providers have to have some way of telling you are logged in - cookies, forms etc. Ideally in DAS, it is the DAS server that needs to check that you are who you say you are, not just the client. For a client like Ensembl, your browser simply never communicates with the DAS server so the DAS server can't get you to authenticate with the OpenID provider.

It would be possible instead to have a system whereby you configure the DAS server to authorise a piece of software via OAuth, and have the client take care of making sure only certain users can access that data source. You are putting the onus of deciding which applications to trust onto the owner of the data, which is not ideal for data like personal genomics (although certainly not worse than handing out passwords). Obviously this has major implications for every client that wants to support it, because it's a whole extra suite of functionality they all need to implement. There would need to be a way for the clients to know who gets to decide who can access the source, though it could be implemented via some DAS-specific way easily I imagine. I think if we were to do it, possibly the best way is actually to have the assignment of who can access the data determined at the DAS server (a list of OpenID identities) which clients can simply query for. That way you're still setting the permissions on the client. You're still trusting the client to honour the list (which includes not caching it), but at least the clients don't need to maintain the access control list. However they still need to implement OpenID. That's a technical requirement but, in the case of Ensembl which already providers user login facilities, it has other consequences. Convincing people it's worth adopting DAS is one thing, but convincing them that they must also use OpenID for their login system is another. All this is why I say it's possible, but there is a significant investment to get it all up and running. I'm also not sure if pure browser-implemented clients like Dalliance can use this method, both OpenID and OAuth involve signing messages with the application's secret key, and it's difficult to do that (and store these keys) without a server of some kind. They'd probably be forced into using one. Still, this is my preferred solution if everybody was on board and had the resources to do it.

Lastly, neither solution works for daemon-style clients (e.g. command-line analysis applications where the user is not present), again because they can't use OpenID. The catch-all solution is to use X.509 certificates (public/private key cryptography) but it is heavyweight and probably too complicated to provide a good user experience. Truth be told, it has proved difficult to discuss this topic amongst the community because it gets technically very complex.

Cheers,
Andy