Hi John,
>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?
It was Pauline that told me about this work. I've cc'd her on this so
hope she can pass on some more information.
I'm not sure whether they've used Shibboleth with thick clients or browser
only.
>
>> - 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.
I suppose equally you could have it as an independent filter which
deployers can choose to include or omit. Maybe you have that already.
>
>> - 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?
A number of security protocols pass tokens in the HTTP header e.g. OAuth,
SAML, the Amazon EC2 REST API. It would be hard to cater for all of these
but if you at least provide the ability for the programmer to set custom
headers they will be able to add in header content as needed.
>
>> - 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.
Authorisation can be kept on the server side - the client need only
authenticate and server middleware work out the authorisation based on
that identity. In some other cases, the client may need to pass
authorisation attributes with its request.
For OAuth, the client passes an authorisation token which authorises it to
access a given resource (at the TDS) on behalf of another user (or agent)
for a limited time period.
>
>> - 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?
You could do either. For the Earth System Grid implementation, the
initial request is authenticated via PKI credentials passed in an SSL
handshake. Following this a session cookie is set so that for subsequent
requests, authentication can be based on the cookie alone.
Cheers,
Phil
--
Scanned by iCritical.
