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

[Jim Procter]

Hi Andy, and anyone else still reading :)

On 14/01/2012 01:03, Andy Jenkinson wrote:
> 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.
Bother! am I feeding troll(s) again ? ;)
> 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).
I'm not sure how different this is from the 3D security challenge from 
your bank/credit card company that opens in an iframe after you put your 
credit card details in to a secure shopping site and hit the confirm 
button. Authentication still has to happen in order for a transaction 
(in our case one involving a DAS request/response session) between the 
DAS server and the Ensembl server, before it renders the result in the 
page sent to your browser.

As for dalliance and secure servers:
> 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.
it won't actually be happening that way - take a look at this: 
http://www.biodalliance.org/cors.html
> 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.
Interesting angle. I'm not actually sure what happens if the page from a 
server allowed to contact another server via CORS has been edited after 
it arrived in the browser sandbox - but I don't think it is really that 
much of an issue either way.

There are two situations worth considering:
1. an honest user wants to access secure data. In which case, they must 
authenticate via the dalliance host page with servers providing secure 
data in order to grant dalliance access via an authenticated 
cross-origin request from a specified server on the trusted CORS list.
2. a black hat attempts to gain access to secure data. In which case 
they must fake an authentication. We then have to rely on the 
authentication framework detecting cracking attempts.

The case when a (probably) honest user with valid credentials misuses 
the cross-origin request by messing with the javascript on the page is 
no different to having a user in a secure intranet who brings a virus in 
via a physical device or over a VPN. Since DAS is rather limited in its 
scope for exploits, I don't think there will be a problem with someone 
fiddling with the javascript, assuming, of course, the servers hosting 
the authenticated sources actually secured their server properly and 
have un-DOSable data providers at the back end...
>>> 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).
>
understood, and I agree, with the caveat that I'm not even sure how 
familiar we all are with HTTP(s) auth styles, and personally, would 
appreciate it if there was a practical session or tutorial on the ins 
and outs of authenticated DAS for those who need to do it. This could 
cover how different styles of authenticated DAS sources work with the 
existing clients (e.g. do I really have to authenticate against every 
secure das source every time a request is made?!). It could also involve 
a tutorial on setting up a secure DAS source using various schemes. For 
example, a tutorial on SSO systems such as Shibboleth2 as used by the UK 
access management federation could be useful if people needs to give 
specific UK academics access to a DAS source.

Of course - nothing in this email constitutes me volunteering to give 
such a tutorial ....
Jim.