[DAS] Personal genomics/Deploying a DAS server for Dummies/6 Easy steps

[Jonathan Warren]

Hi

I'd be against using OAuth because it will probably suffer from the  
same limitations that OpenId suffered from. 1) It will be the in thing  
for a while with support for certain programming languages or  
environments (such as browsers) but will soon go out of fashion when  
something else with a cool sounding name comes along :)
2) It takes us away even more than we already are from the principle  
that the DAS system should be simple.
3) If it's complicated it can be difficult to change your application  
if the environment that you are running your application in changes or  
other factors make you change it (e.g. when the sanger web site no  
longer supported sticky sessions I had to try and rewrite the openID  
code for the registry which turned out to be dependent on normal in  
memory Java sessions, so I had to change code that I didn't really  
understand, thus introducing security holes, so I ended up turning to  
good old username and passwords).
4) Everybody understands username and passwords boxes in an user  
interface whereas if we start going on about OAuth authentication and  
using their facebook accounts people will get frightened off - I'm  
also not sure I won't my gmail or facebook accounts to log me in to  
the DAS registry automatically and start distributing my contact  
lists ;)

My preference and I think most other peoples when we have been on this  
discussion before (3rd time around??) is to use basic https security  
that has been around for years. I also prefer the option of sending  
the username and passwords for every request for a secure data source  
as the server then remains in one state (the registry sends them in  
the headers, MyDAS currently sends them in the xml  - we need to  
decide which to use). This would be in preference to an amazon S3 type  
system where tokens are given for a limited period of time to the  
client/user (the S3 type system would be my second option). These  
would be a good balance between ease of development/understanding and  
security. If specific clients and servers wanted to add extra security  
they could add IP restrictions so they know the client is hosted at a  
specific place.

Cheers

Jonathan.


On 16 Jan 2012, at 23:16, Dan Bolser wrote:

> Heh... it doesn't work:
>
> https://github.com/dbolser/TwitterBot---nowlistening-Perl-script-for-xmms
>
> Not sure what I'm doing wrong.
>
>
> On 16 January 2012 21:12, Dan Bolser <dan.bolser at gmail.com> wrote:
>> On 16 January 2012 18:31, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>  
>> wrote:
>>> I rather suspect this is a purely mental exercise, but that's fine  
>>> for me ;)
>>
>> <snip (too mental for me ;-)>
>>
>>> OAuth is entirely based upon the notion that the server with the  
>>> data (e.g. Google Contacts) can trust the application (e.g. the  
>>> Android Contacts app) to do the right thing with the data. There  
>>> is no requirement that the person who owns the data, or any other  
>>> person, has to be present, and the application doesn't have to  
>>> prove that this will happen. It just has to get the user to agree  
>>> that the application can be trusted. It's up to us therefore to  
>>> provide a secure link between OpenID and OAuth.
>>
>> Right, the person who 'owns' the data (i.e. a list of contacts hosted
>> on a Google account) explicitly grants the third party 'app'
>> permission to access the data (via the account) in a specified way  
>> (as
>> defined by the Google APIs). That app can then email all your  
>> contacts
>> in the middle of the night while you're sleeping, but you trust that
>> that won't happen when you click the 'grant' button.
>>
>> i.e. I (the verified me) can grant Ensembl permission to access my  
>> SNP
>> genotype data from 23andMe (hah), and I trust Ensemble not to do
>> anything nasty with that data when I log off.
>>
>> Although it's a bit of a pain to set this up, the point is that
>> literally thousands of app developers (including me) have done it
>> before, and there are hundreds of docs. Here is where I started  
>> when I
>> built a command line twitter bot:
>> https://dev.twitter.com/docs/auth
>>
>>
>> I'm not trying to say its quick and easy to do and everyone should do
>> it like this, I just thought I'd provide the above encapsulation,
>> which hopefully isn't too far from how it could be done.
>>
>>
>> Cheers,
>> Dan.
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das

Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314









-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.