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.
It would be possible instead to have a system whereby you configure the DAS
server to authorise a piece of software via OAuth, and have the client take
care of making sure only certain users can access that data source. You are
putting the onus of deciding which applications to trust onto the owner of the
data, which is not ideal for data like personal genomics (although certainly
not worse than handing out passwords). Obviously this has major implications
for every client that wants to support it, because it's a whole extra suite of
functionality they all need to implement. There would need to be a way for the
clients to know who gets to decide who can access the source, though it could
be implemented via some DAS-specific way easily I imagine. I think if we were
to do it, possibly the best way is actually to have the assignment of who can
access the data determined at the DAS server (a list of OpenID identities)
which clients can simply query for. That way you're still s!
et!
ting the permissions on the client. You're still trusting the client to
honour the list (which includes not caching it), but at least the clients don't
need to maintain the access control list. However they still need to implement
OpenID. That's a technical requirement but, in the case of Ensembl which
already providers user login facilities, it has other consequences. Convincing
people it's worth adopting DAS is one thing, but convincing them that they must
also use OpenID for their login system is another. All this is why I say it's
possible, but there is a significant investment to get it all up and running.
Yes. security isn't cheap it seems :)
I'm also not sure if pure browser-implemented clients like Dalliance can use
this method, both OpenID and OAuth involve signing messages with the
application's secret key, and it's difficult to do that (and store these keys)
without a server of some kind. They'd probably be forced into using one. Still,
this is my preferred solution if everybody was on board and had !
the resources to do it.
So the problem here with OAuth is that pure browser clients need a
secure store for authenticating a user's access to a particular resource
? I don't think there is any way around that either, and I think the
onus to provide this is the hosting page of the client - i.e.
dalliance.org would need to be recognised as a peer on a secure DAS
OAuth network (using the servers own keys). Then, users wanting access
to secure data would log in to the DAS source independently via a secure
session on dalliance.org, which would then allow dalliance to browse the
data from the secure server. If someone wants to set up a Dalliance
browser in their own OAuth trust network, then they would need to have
their own Dalliance hosting server and make it known to the other peers
accordingly.
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.
Jim.
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
