>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.
Yes, we did this work in conjunction with Earth System Grid. Identity
Providers in the federation support dual methods for single sign on:
OpenID and MyProxy. The first for browser based access, the second for
thick clients. The TDS is configured with middleware which can consume
either kind of authentication request and is in fact agnostic to which it
receives.
That said, the authentication mechanism at the TDS is not specific to
MyProxy. It uses SSL client based authentication so will accept any PKI
based credentials: you could potentially authenticate with a server
certificate just as well as a short term user credential issued by MyProxy.
We currently only support End Entity Certificates in the ESG Federation
but I have configured and tested PyDAP + mod_wsgi + Apache based services
to accept proxy certificates. It should be fairly straightforward to
alter Tomcat's SSL engine config to do the same. This of course opens up
OPeNDAP based services to the Grid based delegation and its use in
workflows.
Cheers,
Phil
>
>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
>
>_______________________________________________
>thredds mailing list
>thredds@xxxxxxxxxxxxxxxx
>For list information or to unsubscribe, visit:
>http://www.unidata.ucar.edu/mailing_lists/
--
Scanned by iCritical.
