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

[Andy Jenkinson]

I rather suspect this is a purely mental exercise, but that's fine for me ;)

On 16 Jan 2012, at 16:44, Jim Procter wrote:

> On 14/01/2012 01:03, Andy Jenkinson wrote:
>> 
>> 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.

It is similar, and the solutions we are discussing are similar. As I say, there are solutions but they require some coordination.

> 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

CORS is what allows Dalliance to avoid having to communicate with DAS servers using a server in the middle (as Ensembl does). I'm saying that if a server is required to do the authentication bit (as I suspect it would be), I hope there is no technical block to having the user's computer send the signed token to the DAS server (i.e. via CORS) rather than the "Dalliance authenticator proxy". It is a slightly different model so I can't say it would definitely work.

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

CORS really isn't an issue - the server either allows CORS or it doesn't (in which case it is not supported by Dalliance) - it does not interact with the security side of things in any problematic way. You can use HTTP authentication in combination with CORS just fine, but we are discussing OpenID + OAuth. I am assuming that CORS is enabled on the DAS server because if it is not then Dalliance will not work. What I am talking about is the fact that Dalliance is a JS application. That is, all its code is completely editable by anyone who cares to open the Developer console, Firebug etc. There is no advantage to using OpenID+OAuth over HTTP authentication (which is what I have implemented in ProServer already so it works with Dalliance as-is) if the user can just disable the bit of the code that authenticates you. Thus we would have to ensure that the Dalliance JS only gets access to an OAuth token if an externally verifiable set of conditions is met. This is what, for me, means that there must be a server component rather than it all being done in JS.

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

I think we're talking crossed purposes. CORS is not a way of securing servers, it's just a way of lifting the restriction placed on Javascript by browsers that it can't request URLs outside the domain of the webpage the Javascript came from. An authenticated cross-origin request (in CORS language) simply means a regular HTTP digest or HTTP basic authenticated request that happens to be setting the headers that are needed to get around this restriction. The potential for misuse is not from misusing the CORS request (indeed interfering with CORS is not possible by fiddling with the javascript). A cross-origin model is completely standard for DAS, indeed it is the whole point of having a distributed system. Nor is the misuse I am worried about to do with faking an authentication. It is simply making a trivial change in a trusted client to manipulate it into accessing secured data by bypassing the need to do the authentication step at all.

OAuth is entirely based upon the notion that the server with the data (e.g. Google Contacts) can trust the application (e.g. the Android Contacts app) to do the right thing with the data. There is no requirement that the person who owns the data, or any other person, has to be present, and the application doesn't have to prove that this will happen. It just has to get the user to agree that the application can be trusted. It's up to us therefore to provide a secure link between OpenID and OAuth.

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