On Thu, Oct 30, 2008 at 7:47 AM, David Nix <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Date: Fri, Oct 17, 2008 at 10:34 AM Subject: A case for why we need authentication/ login functionality in the DAS specifications To: [EMAIL PROTECTED], Gregg Helt <[EMAIL PROTECTED]>, Tonya DiSera <[EMAIL PROTECTED]>, Brett Milash <[EMAIL PROTECTED]>, Robb Cundick <[EMAIL PROTECTED]>, Ann Loraine <[EMAIL PROTECTED]>, Steven Blanchard <[EMAIL PROTECTED]>, Suzanna Lewis <[EMAIL PROTECTED]>, Andy Jenkinson <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | http://bioserver.hci.utah.edu/BioInfo/ _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
