[DAS] Re: DAS security

[James Stalker]

On Tue, Sep 23, 2003 at 12:08:09PM +0100, James Stalker wrote:
> On Tue, Sep 23, 2003 at 11:42:18AM +0100, Neil Walker wrote:
> > Tony Cox wrote:
> > 
> > >Since it has always been an open source/data project we have not
> > >engineered a system for hiding some data form a subset of users.
> > 
> > I had this same discussion with the Mart team last week with regard
> > a distributed Mart.  I think the issue with Ensembl being Open
> > Source is that you can't hack the client code to hide your data from
> > a paricular class of user, as someone can always download an
> > unhacked version from CVS.  
> 
> Well, for the website, the issue is more that you don't provide the
> client, so can't do a thing about it, opensource or not.  It is also
> generally true that you can never trust the client in a client-server
> app.

Thinking about it, Neil, you are correct from the DAS point of view
where the Ensembl website is the client (which is what you were probably
talking about, sorry).  So here we have a fundamental problem - unless
your DAS server is also secure, there is nothing to stop a user setting
up another Ensembl site with a different config, or more practically
just using another DAS client, to look at the secret data.  In this
case, as you point out, a security layer inside the Ensembl server won't
really help.

> > This means security has to be at the server end, as Jonathan Warren
> > implied, and to state the obvious, security can't be in the database,
> > as database security splits "vertically" by database, table or column,
> > and not "horizontally" by row.
> 
> Well, you could of course use views, but that's a discussion for a
> different RDBMS than MySQL.
> 
> > The question therefore is whether config info is client code or not.
> 
> For the website, not.

Or yes, it is, as the case may be... =)

> > Not sure this is relevant, but what we do for gbrowse (thanks to my
> > colleagues Barry Healy and Luc Smink for this info) is that we have
> > multiple databases for e.g. mouse and human data, multiple config
> > files, but only one web interface. At the moment users get a pull down
> > saying which data source (config file) they want, but I guess we could
> > give each class of user access (via links and .htaccess) to just one
> > config file.   We then need to prevent users being able to create their
> > own config files, so if they contain username and password info that
> > the user cannot access - that'd do the trick.

In a within-company scenario, this falls foul of the "the website is
also a client" problem - if you can set up another site that looks at
the same databases, this hasn't really solved anything.

James

-- 
James Stalker
Ensembl Web Project Leader - http://www.ensembl.org