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
