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

[Andy Jenkinson]

On 13 Jan 2012, at 13:04, Jim Procter wrote:

> Hi. I see the dreaded secure DAS session topic as risen its head again.
> 
> On 13/01/2012 00:42, Andy Jenkinson wrote:
>> 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.
> But Ensembl *does* need to know who you are in order to request data that you are allowed access to. In the OAuth model, you would have to allow Ensembl to access privileged data from the third party DAS server, and that would be achieved by the Ensembl browser presenting you with an OpenID login and redirect to subsequent access control pages from the third party server.

Not sure I follow. The problem with the above model isn't with Ensembl it's with the DAS servers. DAS servers can't verify the user that is sitting at his machine (i.e. use OpenID) because they don't communicate with his machine. They only communicate, and can thus verify, the client (i.e. using OAuth). It would be better if the DAS server had some way to check the user directly (the client would be like a proxy for the user) but it is not possible with OpenID under Ensembl's current architecture (or at least it wasn't when I was investigating). So that means you have to do one of the below options instead (including having only Ensembl do the authentication).

>> 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 s!
> et!
>>  ting 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.
> Yes. security isn't cheap it seems :)
>> 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.
> So the problem here with OAuth is that pure browser clients need a secure store for authenticating a user's access to a particular resource ?  I don't think there is any way around that either, and I think the onus to provide this is the hosting page of the client - i.e. dalliance.org would need to be recognised as a peer on a secure DAS OAuth network (using the servers own keys). Then, users wanting access to secure data would log in to the DAS source independently via a secure session on dalliance.org, which would then allow dalliance to browse the data from the secure server. If someone wants to set up a Dalliance browser in their own OAuth trust network, then they would need to have their own Dalliance hosting server and make it known to the other peers accordingly.

Basically yes, I would have thought there'd have to be some server-side Dalliance script doing most of the work, with it hopefully being possible to pass the signed token to the browser so that the user's machine is still the one issuing the DAS request. However, I just saw this, which is a potential solution (for OAuth at least):
http://derek.io/blog/2010/how-to-secure-oauth-in-javascript/
I'm not sure it helps however, as we need to ensure that Dalliance will only issue an authorised request to the DAS server if it has proof that the user has been authenticated and is on the access control list. With JS being editable on the client side, that check cannot be in JS.

>> 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.
> I'd be very much in favour of people who *need* to achieve this spending some time during the developer days with an invited expert (with special anti-trolling skills to counter folk like me) in a closed session, in order to identify components that would enable both browser and non-browser based clients to work with OAuth, and set up a trial OAuth DAS source network for testing. There are libraries that support OAuth (http://oauth.net/code/) both for providers and consumers, but DAS client libraries will need extension to allow secure negotiation and signed DAS HTTP interaction, and their APIs will need additional parameters/methods to allow session management.

I have no objections to participating in principle, but I remain to convinced it is worth the effort (i.e. that HTTP auth is insufficient and that OAuth would be adopted).

> Jim.
> 
> 
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das