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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > http://lists.open-bio.org/mailman/listinfo/das > > _______________________________________________ > DAS mailing list > [email protected] > http://lists.open-bio.org/mailman/listinfo/das > _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
