It's great to be gathering input on this. A few things I would raise:
- I'm aware of work securing TDS deployments with Shibboleth - with the
Australian Access Federation I think. It would be great if some testing
could be done there.
- You mention basic password credentials for the client side: would this
be using HTTP Basic Auth?
- On the server side, I would keep a clean separation and have any
security code as independent middleware. That way deployers can decide
what they want to support.
- Likewise on the client side, if there was some kind of API to enable
developers to add their own security hooks this could be useful. E.g. The
ability to pass custom HTTP header content (maybe you can do this already?)
- I would draw the distinction authentication/authorisation: for almost
all cases I think you would be passing authentication credentials over the
request channel. Authorisation would be orthogonal. Something like OAuth
would be an exception.
- On the Global vs. Dynamic, I know we've discussed this already: dynamic
is really important to us and I'm sure others too. It opens up the
possibility of OPeNDAP services for use with the Grid security paradigm:
services in workflows with user credentials delegated to the different
services along the chain.
On 11/03/2011 09:55, "Jon Blower" <j.d.blower@xxxxxxxxxxxxx> wrote:
>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.
>[mailto:netcdf-java-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Dennis
>Sent: 10 March 2011 21:54
>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.
>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.
>netcdf-java mailing list
>For list information or to unsubscribe, visit:
Scanned by iCritical.