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

Mon Jan 16 17:10:29 UTC 2012

Hi guys,

why not just trying to do something *really* easy that could be
implemented in a couple of weeks rather than trying to engineer the
perfect solution all at once? We don't really know how much demand
there is for authenticated DAS sources, so we may end up spending a
lot of effort for something that might be underused.

The truth is that currently all DAS sources are public. Some "private
sources" available are those provided by easyDAS with its long
"cryptic" urls. That alone I think is already something. Any
improvement on the ability to keep sources private, whatever small,
would be a step in the right direction.

My two cents.

Manuel

Manuel Corpas, PhD
Tel:      +44.122349.2372
Web:    http://manuelcorpas.com/about/
Twitter: @manuelcorpas

On 16 January 2012 16:44, Jim Procter <jprocter at compbio.dundee.ac.uk> wrote:
> 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.
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das