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
