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. 

James

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 NetcdfDataset.java, HttpClientManager.java
>   HTTPRandomAccessFile.java, and NetcdfFile.java.
> 
> 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: 
> http://www.unidata.ucar.edu/mailing_lists/ 

--
James Gallagher
jgallagher at opendap.org
406.723.8663

• Follow-Ups:
  • Re: [thredds] Proposal for handling authorization credentials in thredds....
    • From: philip.kershaw

• References:
  • [thredds] Proposal for handling authorization credentials in thredds....
    • From: Dennis Heimbigner