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

Mon Jan 16 18:34:51 UTC 2012

I agree with this. Security through obscurity should never be presented as "private". We should continue to implement some form of authentication but we should keep it simple to start with.

On 16 Jan 2012, at 17:20, Bernat Gel wrote:

> Hi all,
> 
> I agree with Manuel (and I think Andy) that without a real demand for
> private DAS sources implementing some complex authentication scheme might
> be an overkill. However, I think that a key thing with security is that if
> it's done, it has to be weel done. Somehow, a false sense of privacy (such
> as the cryptic URLs in easyDAS) might be a bad thing if the user is not
> aware of its weaknesses and end up unkwowingly sharing data deemed to
> remain private.
> 
> So, unless a DAS sourceis really private and secure, it should be made
> clear that it is public (although maybe difficult to find).
> 
> Bernat
> 
> On Mon, Jan 16, 2012 at 18:10, Manuel Corpas <mc at manuelcorpas.com> wrote:
> 
>> 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
>> 
>> _______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>> 
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das