Re: [netcdf-java] Proposal for handling authorization credentials in netcdf-java

Hi Dennis,

This looks good to me - I think you've captured the scenarios well.  I'm 
copying this to Phil Kershaw in case he has any comments.

Best wishes,

-----Original Message-----
From: netcdf-java-bounces@xxxxxxxxxxxxxxxx 
[mailto:netcdf-java-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Dennis Heimbigner
Sent: 10 March 2011 21:54
To: netcdf-java@xxxxxxxxxxxxxxxx
Subject: [netcdf-java] Proposal for handling authorization credentials in 

I am in the process of refactoring the
remote data access functionality for
thredds. This currently will affect
opendap, but others may occur in the future.

My goal for this initial message is to solicit
comments about the following proposal to make
sure I am not missing any. Please post comments
on this newsgroup or send them directly to me

Additionally, I do not have access to
servers that use the auth mechanisms
listed below. I have ESG, but not the others.
If you are game, and can provide me with an
account on your server, so I can do testing,
it would be much appreciated.

=Dennis Heimbigner


The primary issue here is providing various kinds of authorization
credentials (broadly construed) to servers by clients.

Currently, I have identified the following scenarios that must be
supported (pardon me if I am a bit loose with terminology).

1. client-side credentials:
     - basic password credentials
     - java keystore for ESG credentials
     - OPEN-ID credentials (probably restricted
       to web-browser access only).

2. server-side credentials support:
    - currently basic and keystore are already supported
      in apache httpclient-3.
    - OPEN-ID support will require additional server-side code.

3. Proxy support
     - providing password access to get through proxies.

There is an additional factor.  It is desirable to support both "global"
and "dynamic" credentialing.

Global - this means that a single set of credentials is set globally and
          is adequate for all code running within a single program
          (i.e. linux or windows process).

Dynamic - this means that each connection to a server may have a
           separate set of credentials. Further, it must be guaranteed
           that no connection is re-used to avoid inadvertent access to
           some other set of credentials.

My refactoring involves the following changes:

1. wrap the HttpClient class within a new class called HTTPSession to
    give better control over the parameters for the HttpClient objects.
    Methods are also wrapped using an HTTPMethod class.

2. Remove all static HttpClient (HTTPSession) class variables.  This so
    far is affecting,, and

3. Modify the api's of the above classes to provide an extra parameter
    to pass in authorization information.  The authorization information
    is passed using an instance of the HttpConnectionParams class so that
    it can hold arbitrary (key,value) pairs.

4. The authorization information is passed along ultimately into where
    it is needed, namely the HTTPSession object, the HTTPMethod object
    and into the SSLProtocolFactory.


netcdf-java mailing list
For list information or to unsubscribe, visit: 

  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: