[DAS] Re: DAS security

[James Stalker]

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.

> 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.

> 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.

I'm not sure how appropriate this is for the problem in question.  The
issue is to have the same "core" data displayed (i.e. from all the
Ensembl databases) for everyone, but only show certain DAS tracks to
certain users.  There isn't anywhere to put .htaccess files - the
dataspace shown is all virtual.  

I think the most failsafe point at which to place the security check is
probably in the DAS drawing code itself, as Tony mentioned, before the
DAS source is queried.

Cheers,

James

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