[DAS] A case for why we need authentication and login functionality in the DAS specifications

[Gregg Helt]

On Thu, Oct 30, 2008 at 7:47 AM, David Nix <david.nix at hci.utah.edu> wrote:
Hey Gregg, I don't think my summary went out to the das mailing lists.  It
came back last week rejected for lack of permission to post.  Could you
forward it?  -cheers, D

---------- Forwarded message ----------
From: David Nix <david.nix at hci.utah.edu>
Date: Fri, Oct 17, 2008 at 10:34 AM
Subject: A case for why we need authentication/ login functionality in the
DAS specifications
To: das2 at lists.open-bio.org, Gregg Helt <gregghelt at gmail.com>, Tonya DiSera
<tony.disera at hci.utah.edu>, Brett Milash <brett.milash at hci.utah.edu>, Robb
Cundick <robb.cundick at hci.utah.edu>, Ann Loraine <aloraine at gmail.com>,
Steven Blanchard <sgblanch at gmail.com>, Suzanna Lewis <suzi at berkeleybop.org>,
Andy Jenkinson <andy.jenkinson at ebi.ac.uk>

Hello Folks,

Here is a case for why we need authentication/ login functionality in DAS.

Key Functionality: Need a mechanism to tell a DAS server who is making a
particular request.

This will enable tailor-made responses such as:

1) Access to private data (sources, segments, types, etc.)
2) Custom views of the data (investigator view vs clinic view of same data)
3) Restricted write back
4) Support future as of yet undefined personalized responses

How this is implemented is of little concern to me so long as the key
functionality is met.

That said, a couple of considerations for any DAS Server implementation:

1) Web forms/ GUIs should be capable of modifying the users, user
permissions, data views and uploading of new data. Privileged users with no
command line skills (ie biologists/ lab managers) need to be able to
customize their data and who can see it. They shouldn't have to make a
request to a system administrator.

2) The mechanism of passing the user credentials to the servlet should be
platform independent. The fewer barriers to installing a DAS server the
better. A good DAS server should support authentication on WebSphere,
Tomcat, Orion, etc. with little to no modification.

A first stab:

I've build into the current GenometryDas2Servlet a mechanism for
authenticating a client. I tried to follow existing DAS/2 query/ response
styles.

In brief, I created a new DAS command called 'login' that prompts the
servlet to check to see if this server instance is authorizing. If it is not
authorizing (ie contains no restricted sources/segments/types) then an xml
doc is returned with an AUTHORIZED tag set to true. If it is authorizing and
no login parameters are provided with the request then the AUTHORIZED tag is
set to false. If the server doesn't recognize the login request then it's
HTTP ERROR: 400 response also says it isn't accepting authorization.

Thus a login request without parameters basically is asking to see if
authentication is recognized and, if so, enabled.

If 'user' and 'password' parameters are supplied with the 'login' request,
the servlet attempts to authenticate the user, if OK an HTTPSession object
is created for the user, a JSESSIONID is attached to the xml response as a
cookie and the AUTHORIZED tag set to true.

I modified IGB to make a 'login' request to each DAS/2 server listed in it's
igb_pref.xml file upon start up. If the DAS/2 server responds appropriately,
IGB asks the user to enter a login and password.  These are then sent as
plain text parameters (bad, need a better mechanism, https?) with a second
login request. Authentication then proceeds.  If the server doesn't
recognize the login request (throws an HTTP ERROR: 400) or it isn't enabled,
the user isn't prompted and no login information is sent. See the attached
file for some examples of the exchange.


-cheers, David


--
David Austin Nix, PhD | HCI Bioinformatics | Huntsman Cancer Institute |
2000 Circle of Hope | SLC, UT 84112 | Rm: 3344 | Vc: 801.587.4611 | Fx:
801.585.6458 | david.nix at hci.utah.edu |
http://bioserver.hci.utah.edu/BioInfo/