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

[Jim Procter]

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.
> 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 set!
>   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.
> 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.

Jim.