On Apr 2, 2013, at 1:27 PM, Kevin Manross wrote:
>
> Thank you very much, Nathan (as well as Dennis and Bob). This is terrific
> information.
>
> The JDBC Realm info is something I'm digging into. I'll need to discuss with
> our working group whether certificates are an option or not.
>
> Nathan, you mention "once you have your credentials (session cookies) then
> the client should be able to return the cookie to Tomcat with subsequent
> requests". Is this all done "under the hood" with clients that can handle
> cookies?
I think the answer is yes, with the caveat that to get the client to behave
this way there may be some extant configuration issues...
> Can you provide an example of an opendap client that handles/uses cookies?
>
> I may have mentioned previously that we have a utility to allow users to
> obtain a cookie file and then they can send that cookie with wget or curl.
> Is there any such mechanism for any opendap client that you are aware of, or
> should I let go of this concept?
>
I may be way off base here but I thought that all the clients that are based on
the java netCDF "client" library (Panoply, ToolsUI, etc) did this by default.
Maybe someone from UNIDATA that actually knows about this can jump in here?
Again - I don't see this as a DAP issue insofar as it's an issue between the
client and the server that happens out-of-band from the DAP transaction. It is
a DAP issue in that the clients may or may not provide reasonable facilities
for performing and "persisting" authentication states which may result in some
clients being locked out of some resources.
> Thanks again!
>
> -kevin.
>
> On 4/2/13 1:18 PM, Nathan Potter wrote:
>>
>> Kevin,
>>
>> I made a number of comments below. I think I got the facts right and II am
>> hoping that James jumps in if he sees a mistake.
>>
>>
>> Nathan
>>
>>
>> On Apr 2, 2013, at 9:38 AM, Kevin Manross wrote:
>>
>>
>>> Thank you all for the feedback!
>>>
>>> Since I've already handled authentication for browser based logins, I'm
>>> concerned with other (command line or plugin) opendap client login.
>>>
>>> Jeff mentioned using Basic Authentication for clients like RAMADDA and IDV.
>>> If I understand correctly, this requires maintaining the user list in the
>>> tomcat-users.xml file. If this is correct, I don't think is not a viable
>>> option to maintain our 9000+ users which we currently maintain in a mysql
>>> database. (I would be very happy to learn that I don't have a proper
>>> understanding of the tomcat basic authentication process, so please correct
>>> me if needed.)
>>>
>> Tomcat can use a number of existing external authentication services (for
>> example LDAP) for identifying users:
>> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html
>>
>>
>> I imagine that it would be possible to utilize the JDBCRealm to conduct your
>> user authentication.
>>
>> As far as authorization goes you might need to do something more - if you
>> already have something like the notion of "groups" in your user-base you
>> might already be thinking of translating those into different (tiered)
>> levels of access and that might be done along with the authentication step
>> by creating tomcat "roles" that parallel the "groups".
>>
>>
>>> I could envision writing a filter that parses the BA-style url syntax to
>>> obtain the user/pass and then access our mysql users database to verify.
>>> However, when testing our gribcollection best time series with the IDV
>>> (without restriction), the volume of requests to obtain the subdomain of
>>> data was relatively large. My concern is how much overhead there would be
>>> to verify each request via mysql when sent in rapid succession like that.
>>>
>> I don't think that would be required, once you have your credentials
>> (session cookies) then the client should be able to return the cookie to
>> Tomcat with subsequent requests - up to the point the cookie expires or is
>> invalidated by the server. If the command line clients can't cope with that
>> then you might have to look at using certificates issued to the users - I
>> believe that once a certificate is correctly installed and identified to
>> (most of?) the DAP2 client software implementations that they already know
>> how to feed it to a server and make the authentication step.
>>
>>
>>
>>> If I understand John correctly, clients technically can send a cookie over
>>> the HTTP protocol, but there is no guarantee that a client has this
>>> capability. It would be great if there was something akin to wget's
>>> --load-cookies option for opendap clients. All of this is for the current
>>> (3.7, I believe) version of opendap.
>>>
>> To be clear - while the DAP2 protocol is tied to HTTP the DAP2 Protocol
>> pretty much does not address the issues of authentication and authorization.
>> These are assumed to be handled elsewhere
>>
>>
>>> So it sounds to me that my best course of action may be to pursue the
>>> filter option(?) - unless anyone can correct my understanding above or
>>> offer another way to think about this.
>>>
>> If you're doing something custom then I would say a filter is the way to go.
>> I think that this is an area where we anticipate receiving some funding and
>> that we have been engaged in active but low bandwidth discussion of this
>> topic over the last several months. We should keep communicating about this
>> it may be that we may find places to work together for a general solution.
>>
>>
>> N
>>
>>
>>
>>> -kevin.
>>>
>>>
>>> On 4/1/13 5:34 PM, John Caron wrote:
>>>
>>>> Hi kevin:
>>>>
>>>> Cookies are part of standard HTTP, and are passed (both ways) in the HTTP
>>>> header. Opendap is built on top of HTTP, and so any opendap client has a
>>>> mechanism for passing cookies. Whether they do so or not depends on the
>>>> client. I dont think they are required to (?).
>>>>
>>>> Cookies are used to maintain session state on the server. This can mean
>>>> that the server only has to authenticate once for a session. That is
>>>> mostly just a performance issue, but in the worst case, the client could
>>>> pop up a user login window for each request, of which there are often many
>>>> for any given dataset access. But the client could also cache the
>>>> authentication header and send it each time. So cookies arent totally
>>>> necessary, whats really important is that the client does something
>>>> reasonable.
>>>>
>>>> There is also a subtle (and usually rare) problem on datasets that can
>>>> change while being accessed, when you dont manage state, blogged about
>>>> here:
>>>>
>>>>
>>>> http://www.unidata.ucar.edu/blogs/developer/en/entry/indexed_data_access_and_coordinate
>>>>
>>>>
>>>> My own opinion is that state is necessary, though perhaps evil. Web
>>>> servers like apache and tomcat do all the heavy lifting, so i think
>>>> its not a huge burden on server writers. If I was king of opendap i would
>>>> specify that clients must return cookies.
>>>>
>>>> I think if you follow standard HTTP practices, and an opendap client
>>>> misbehaves, its up to the client to improve or risk becoming obsolete.
>>>> There are plenty of robust HTTP libraries in all languages, so there is
>>>> really no good excuse for clients not to do something reasonable.
>>>>
>>>> John
>>>>
>>>> On 4/1/2013 11:04 AM, Kevin Manross wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> To server our data, we set a cookie once the user successfully logs in
>>>>> to our website. We check for that cookie upon return to the website. I
>>>>> have successfully written a filter for our experimental TDS and it seems
>>>>> to handle web browser interactions by checking for cookies and
>>>>> redirecting to our login if need be. My next step is how to handle
>>>>> opendap requests.
>>>>>
>>>>> I have been reading up on the various ways to authenticate opendap
>>>>> requests (primarily via THREDDS), many of which refer to the server
>>>>> setting a session cookie upon successful login. My question is, how is
>>>>> the session cookie checked upon subsequent requests by opendap clients
>>>>> like IDL, Matlab, IDV, pydap, etc.?
>>>>>
>>>>> We have a mechanism to allow users to obtain and store cookie
>>>>> information for use in non-browser-sessions like scripts. These scripts
>>>>> usually involve wget which has a way to load cookies. Do opendap
>>>>> clients have any such way to send a cookie?
>>>>>
>>>>> This is a major hurdle for our service and any feedback is greatly
>>>>> appreciated!
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -kevin.
>>>>>
>>>>> --
>>>>> Kevin Manross
>>>>> NCAR/CISL/Data Support Section
>>>>> Phone: (303)-497-1218
>>>>>
>>>>> Email:manross@xxxxxxxx <mailto:manross@xxxxxxxx>
>>>>>
>>>>> Web:
>>>>> http://rda.ucar.edu
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> thredds mailing list
>>>>>
>>>>> thredds@xxxxxxxxxxxxxxxx
>>>>>
>>>>> For list information or to unsubscribe, visit:
>>>>> http://www.unidata.ucar.edu/mailing_lists/
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> thredds mailing list
>>>>
>>>> thredds@xxxxxxxxxxxxxxxx
>>>>
>>>> For list information or to unsubscribe, visit:
>>>> http://www.unidata.ucar.edu/mailing_lists/
>>> --
>>> Kevin Manross
>>> NCAR/CISL/Data Support Section
>>> Phone: (303)-497-1218
>>>
>>> Email:manross@xxxxxxxx
>>>
>>> Web:
>>> http://rda.ucar.edu
>>>
>>> _______________________________________________
>>> thredds mailing list
>>>
>>> thredds@xxxxxxxxxxxxxxxx
>>>
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/mailing_lists/
>> = = =
>> Nathan Potter ndp at opendap.org
>> OPeNDAP, Inc. +1.541.231.3317
>>
>>
>>
>>
>>
>
> --
> Kevin Manross
> NCAR/CISL/Data Support Section
> Phone: (303)-497-1218
> Email:manross@xxxxxxxx
> Web:http://rda.ucar.edu
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
