Re: [thredds] Proposal for handling authorization credentials in thredds....

  • To: Dennis Heimbigner <dmh@xxxxxxxxxxxxxxxx>
  • Subject: Re: [thredds] Proposal for handling authorization credentials in thredds....
  • From: Gallagher James <jgallagher@xxxxxxxxxxx>
  • Date: Thu, 10 Mar 2011 15:52:17 -0700
I agree with Benno WRT OPenID and OAuth.

I think that you should look at MyProxy - I see you mention proxies but not 
MyProxy spec. - I know that some other groups (UK?) have settled on this 
openid/oauth and myproxy combination. They used MyProxy for  support for 
non-browser clients. 


On Mar 10, 2011, at 2:53 PM, Dennis Heimbigner wrote:

> 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
> (dmh@xxxxxxxx).
> 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
> Unidata
> ------------------------------
> Proposal:
> 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.
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit: 

James Gallagher
jgallagher at

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