[DAS] Fwd: Using HTTP authentication for DAS/2

[Gregg Helt]

More background on recent discussions regarding DAS security and
authorization.

---------- Forwarded message ----------
From: Ann Loraine <aloraine at gmail.com>
Date: Fri, Sep 26, 2008 at 9:01 AM
Subject: Re: Using HTTP authentication for DAS/2
To: Steven Blanchard <sgblanch at gmail.com>
Cc: Tonya DiSera <tony.disera at hci.utah.edu>, David Nix
<david.nix at hci.utah.edu>, nicol.john at gmail.com, Brett Milash
<brett.milash at hci.utah.edu>, Robb Cundick <robb.cundick at hci.utah.edu>


I'm not sure if I understand the various technical aspects here - my
apologies! I'm also getting up to speed on this particular issue :-)

Do I understand correctly?

If a lab were to set up its own private DAS site to serve unpublished
or preliminary lab data, it sounds as though they could right this
moment use the technique Steven demo'd in his first email. But if they
also wanted to serve free and open data (for example, as a companion
to a published article) then they would need to set up and run an
entirely new instance of the DAS servlet.

One of our big goals in the Loraine group is to deliver a DAS server
to TAIR and possibly iPlant, which would ultimately serve free and
open data. But I would also want for individual labs to be able to set
up their own private resources. In those cases, users would want to
access the public data (e.g., the foundation TAIR8 annotations)  and
view these foundation annotations alongside their unpublished data
sets, e.g, Arabidopsis tiling array data.

TAIR = www.arabidopsis.org

-Ann

On Thu, Sep 25, 2008 at 12:21 PM, Steven Blanchard <sgblanch at gmail.com>
wrote:
> I have not gotten as far as thinking about your second point
> (authorization).  I am still working on just authentication.  My
> official statement is that HTTP authentication will support mixed
> authenticated/unauthenticated access just fine.
>
> That being said, my previous email glossed over the separation of the
> DAS/2 specification and our DAS/2 server implementation.  If we use
> HTTP authentication, we do not have to specify any authorization model
> in the DAS/2 specification.  If we add our own authentication into the
> DAS/2 specification we will also need to add authorization to the
> specification.  I like the ability to leave the authorization details
> to server implementers as one authorization model may not work for
> everyone.  On the client side, as long as a it supports HTTP
> authentication the client will 'do the right thing' when a server
> requires authenticated access.
>
> My other emails cover implementation details related to supporting
> HTTP authentication, so I will not rehash them here.  Now all we need
> to do is decide on whether to add the current
> authentication/authorization model to the specification or to switch
> to HTTP authentication and decide on an implementation strategy.
>
> Thanks,
> ~Steven
>
>
> 2008/9/25 Tonya DiSera <tony.disera at hci.utah.edu>:
>> Hi Team -
>>
>> I'm just getting familiar with this project, so I apologize if I am
>> covering issues already thought through.
>>
>> David, Brett, and I recently devised a security model for our GNomEx
>> application that allows for both public and private access to
>> experimental data. At first glance, DAS would seem to benefit from a
>> similar security model architected at two levels:
>>
>> 1)  A basic access layer, permitting either public access (guest access,
>> no authentication) or private (login) access.  The trick here is that we
>> want the servlet to be accessed both in an authenticated mode and a
>> non-authenticated mode.  I've devised an implementation that relies on a
>> "gate keeper" servlet that I can expand upon if we find this to be an
>> important consideration.  Steve, it sounds like you have a good handle
>> on the HTTP authentication model.  Is there a way we can rely on this
>> standard implementation, permitting both authenticated and
>> non-authenticated access to the servlet?
>>
>> 2)  A data access layer governed by user/group permissions assigned to
>> specific data sources.  This layer would be implemented by servlet
>> application code that would filter data sources based on the user/group
>> permissions assigned to each data source and the scope of visibility set
>> on the data source.  For example, some data sources would be marked as
>> "public" by the submitter and would therefore be visible to all users.
>> Data sources marked as "private" would be visible to only those users
>> belonging to groups permitted to view this data.
>>
>> Thanks,
>>  Tony Di Sera
>>
>> -----Original Message-----
>> From: Steven Blanchard [mailto:sgblanch at gmail.com]
>> Sent: Wednesday, September 24, 2008 5:00 PM
>> To: David Nix
>> Cc: Ann Loraine; nicol.john at gmail.com; Brett Milash; Tonya DiSera; Robb
>> Cundick
>> Subject: Re: Using HTTP authentication for DAS/2
>>
>> When I was testing, I had only password protected one entire genome of
>> the two that were on the server.  Password protecting only particular
>> annotations would be a bit more complex.  Instead of relying on
>> path-based controls, I think that the DAS/2 servlet could generate the
>> 401 Authorization Required internally and force clients to
>> authenticate when necessary.  If the DAS/2 servlet can generate the
>> 401--which I see no technical reason it can not--it would allow a web
>> admin page to modify permissions on the fly instead of having the
>> systems administrator mucking about with the web.xml.  Again, I will
>> need to test to make sure that this is the case before we decide to
>> commit to this path.
>>
>> ~Steven
>>
>> 2008/9/24 David Nix <david.nix at hci.utah.edu>:
>>> Yes, this is slowly coming back my apologies.
>>>
>>> I did look into using the http authentication the problem is the
>>> granularity.  I believe they provide all or nothing access to the
>> servlet.
>>> Thus each lab would have to have their own servlet instance with
>> pointers to
>>> their data. (We've got a growing list of 20 labs with private and
>> public
>>> data.) Most servlet containers explicitly avoid multiple instances and
>> work
>>> with a shared instance.  I looked into running multiple instances and
>> or
>>> multiple tomcat servers and it got rather ugly.
>>>
>>> Is there a way of allowing everyone to access the servlet but passing
>> to it
>>> the credentials from the http authentication?  That would be a good
>>> solution.
>>>
>>> -cheers, D
>>>
>>>
>>> On 9/24/08 2:52 PM, "Steven Blanchard" <sgblanch at gmail.com> wrote:
>>>
>>>> Apologies this rambles a little:  I wanted to get it out while
>>>> everything was still fresh in my mind.
>>>>
>>>> The three types of HTTP authentication I know about are Basic,
>> Digest,
>>>> and Negotiate.  Basic and Digest authentication are the most common.
>>>> Basic authentication sends usernames and passwords across the wire in
>>>> clear text.  Digest authentication uses an MD5 digest of the password
>>>> instead of the actual password itself but can not be used with some
>>>> back-end authentication databases.  Negotiate authentication is
>>>> designed to enable Kerberos and other similar authentication schemes,
>>>> but is not well supported.  The advantage I see to using HTTP
>>>> authentication is that a server administrator can leverage any
>>>> authentication mechanism supported by the servlet server.
>>>>
>>>> As a test, I used basic authentication to  password protect a genome
>>>> on our DAS/2 server.  I chose to use HTTP Basic authentication backed
>>>> by our LDAP directory.  The configuration I created allowed anyone in
>>>> the 'admin' LDAP group to access the password-protected genome.  Note
>>>> that this configuration does transmit passwords in the clear.
>>>>
>>>> When I accessed the protected genome using IGB, it created a login
>> box
>>>> asking for the user to authenticate to the server which worked as
>>>> expected.  The dialog box was created by Java itself: I did not
>> change
>>>> a single line of code in IGB or the DAS/2 servlet.
>>>>
>>>> If we were to adopt HTTP authentication as the offical access control
>>>> method for DAS/2, the following modifications would be required:
>>>>  - Fix the labels on the HTTP authentication dialog box (blank site
>> and realm)
>>>>  - have IGB properly handle 403 Forbidden responses which may be the
>>>> result of failed login attempts (tons of exceptions)
>>>>  - Determine if IGB's browser cache needs fixing (uses cached file if
>>>> it exists and the current authentication attempt failed)
>>>>  - Modify the DAS/2 servlet to manage access control instead of the
>>>> web.xml (Should be possible, but not certain)
>>>>
>>>> The tomcat context.xml (called das2.xml) and web.xml I used are
>>>> attached. A screen capture of the password dialog box presented by
>> IGB
>>>> is also attached.
>>>>
>>>> Please let me know if I need to clarify anything.
>>>>
>>>> Thanks,
>>>> ~Steven
>>>
>>>
>>
>