NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Philip: On 3/11/2011 3:23 AM, philip.kershaw@xxxxxxxxxx wrote:
Anyone have a TDS sever with Shibboleth, that we can use for testing clients against?Hi Dennis, 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.
We have that in the TDS (I think) although we are going to review the implementation.- 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?)
This is a bit bigger in a way because there are multiple clients (Unidata has both a C and Java client) and there are multiple protocols (Http, opendap, WxS, etc). Its possible we could do this all on the Http layer (??)
Could you give a use case you have in mind?
Yes, thats how i works on the server. Im not sure how authorisation works on the client, or OAuth's role.- 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.
In the dynamic scenario, would the opendap server be allowed to cache credentials, or must it just pass through the requester's credentials on each request?- 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.
John
netcdf-java
archives: