Hi Philip:
On 3/11/2011 3:23 AM, philip.kershaw@xxxxxxxxxx wrote:
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.
Anyone have a TDS sever with Shibboleth, that we can use for testing
clients against?
- 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.
We have that in the TDS (I think) although we are going to review the
implementation.
- 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?
- 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.
Yes, thats how i works on the server. Im not sure how authorisation
works on the client, or OAuth's role.
- 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.
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?
John
