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

[Bernat Gel]

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
>