Re: [thredds] Proposal for handling authorization credentials in thredds....

Hi Ben,

I'm not sure I'm answering your question …

Please forgive me for posing a newbie question, but I'm wondering how the 
authorization services under discussion are related to shibboleth.  In 
particular, there was a recent shibboleth interoperability experiment in the OGC

http://www.opengeospatial.org/projects/initiatives/shibbolethie

Yes - I've heard about ongoing work with OGC services and Shibboleth but I'm 
not aware of any work using Shibboleth with OPeNDAP based services apart from 
in Australia.   Shibboleth would normally only support browser based clients 
but I believe there has been/is ongoing work with Shibboleth/SAML for thick 
clients.  This could be important for how any changes are made to the NetCDF 
client.

Cheers,
Phil


On Mon, Mar 14, 2011 at 8:37 AM, Benno Blumenthal 
<benno@xxxxxxxxxxxxxxxx<mailto:benno@xxxxxxxxxxxxxxxx>> wrote:
Hi Phil, John,

As I was about to tell John, this is all triggered by the work Phil is doing, 
namely

http://www.allhands.org.uk/2009/09/Kershaw89AccessControlForCMIP5PhilipKershaw.pdf

and Phil is definitely the one to talk to.

My immediate problem is that in CMIP3 there was a THREDDS/OPendap service of 
aggregated datasets,

http://esgcet.llnl.gov/dap/ipcc4/?thredds


which my opendap web client converts to a set of webpages that allows analysis 
of the data

http://iridl.ldeo.columbia.edu/SOURCES/.WCRP/.CMIP3/

Because security is Basic Authentication, my client uses the security on the 
original data to protect the derived pages/analyses, i.e. userids/passwords are 
from the original site, not my web server.


CMIP5 is a different story, because if/when it becomes available as a 
THREDDS/Opendap service, it will be protected by OpenID (near as I can tell 
from the outside, anyway). My understanding is that this requires something 
like MyProxy for standalone opendap clients.  OpenID works for a browser 
directly interacting with a CMIP5 Federation server, but my understanding is 
that, in order for a third party (like my opendap web client) to access the 
data, something more is required.  My efforts to understand the implications of 
what Phil has done lead me to see that OAuth is designed to solve that 
three-legged problem -- how well, remains to be seen.

So Phil, It seems to me that  already you have a WMS client accessing the CMIP5 
data, but my guess is that that client is within the same openid security as 
the data.  If you separated the WMS client and the data server into different 
security domains, then you would have the three-legged problem that I have, 
i.e. your WMS server accessing data on another machine in the federation.  Is 
that what you were referring to?

So yes, I am working on OAuth, but what you are doing is crucial (and it is all 
your doing, anyway).  It does not seem like much of a change for you to handle 
OAuth -- it is a longer, three-way conversation with a series of tokens along 
the way, but it ends up with a AuthorizedAcessToken to access the data, which 
must be about the same as what you have already done.  But maybe you have done 
that already for WMS?



Benno




On Mon, Mar 14, 2011 at 4:04 AM, 
<philip.kershaw@xxxxxxxxxx<mailto:philip.kershaw@xxxxxxxxxx>> wrote:
Hi Benno,

I'd be very interested to hear if you've done work with OAuth too.

I've looked at it for a particular project recently but this option hasn't got 
past the design stage, instead we are going for a solution using proxy 
certificates.  Interesting what you say about discovery.  That's something that 
really has to be resolved.

For Earth System Grid we have leveraged OpenID to enable discovery of 
additional Identity Provider services via the XRDS document retrieved with 
Yadis: when you HTTP GET the user's OpenID URL it returns an XRDS document 
containing a list of service endpoints.  It doesn't help in the OAuth scenario 
though as far as I can see because you want to discover services at the 
resource being protected.

There was also work with OpenID/OAuth in a recent OGC interoperability 
experiment.

Phil

From: John Caron 
<caron@xxxxxxxxxxxxxxxx<mailto:caron@xxxxxxxxxxxxxxxx><mailto:caron@xxxxxxxxxxxxxxxx<mailto:caron@xxxxxxxxxxxxxxxx>>>
Date: Sat, 12 Mar 2011 07:01:05 -0700
To: 
<thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx><mailto:thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx>>>
Subject: Re: [thredds] Proposal for handling authorization credentials in 
thredds....

thanks Benno, we'll check out OAuth. are you currently implementing it?

On <tel:3%2F10%2F2011> 3/10/2011<tel:3%2F10%2F2011> 3:23 PM, Benno Blumenthal 
wrote:
I am pretty sure the essential scheme is OAuth -- authorizing a third party to 
access data on the user's behalf -- though the primary implementation would be 
OpenID with OAuth extensions.   Unfortunately OAuth 2.0 is still being hammered 
out, so we are stuck with OAuth 1.0, which does not have any real discovery in 
it, i.e. you cannot figure out from the denial what to do, but that will get 
fixed in 2.0.  At least, they are arguing about it.  But at least you (we) can 
get the pieces into place.

Benno

On Thu, Mar 10, 2011 at 4:53 PM, Dennis Heimbigner 
<dmh@xxxxxxxxxxxxxxxx<mailto:dmh@xxxxxxxxxxxxxxxx><mailto:dmh@xxxxxxxxxxxxxxxx<mailto:dmh@xxxxxxxxxxxxxxxx>>>
 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<mailto:dmh@xxxxxxxx><mailto:dmh@xxxxxxxx<mailto: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<mailto:thredds@xxxxxxxxxxxxxxxx><mailto:thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx>>
For list information or to unsubscribe,  visit: 
http://www.unidata.ucar.edu/mailing_lists/



--
Dr. M. Benno Blumenthal          
benno@xxxxxxxxxxxxxxxx<mailto:benno@xxxxxxxxxxxxxxxx><mailto:benno@xxxxxxxxxxxxxxxx<mailto:benno@xxxxxxxxxxxxxxxx>>
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000   <tel:%28845%29%20680-4450> (845) 
680-4450<tel:%28845%29%20680-4450>


_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx><mailto:thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx>>
For list information or to unsubscribe,  visit: 
http://www.unidata.ucar.edu/mailing_lists/

_______________________________________________ thredds mailing list 
thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx><mailto:thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx>>
 For list information or to unsubscribe, visit: 
http://www.unidata.ucar.edu/mailing_lists/
--
Scanned by iCritical.



--
Dr. M. Benno Blumenthal          
benno@xxxxxxxxxxxxxxxx<mailto:benno@xxxxxxxxxxxxxxxx>
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000   (845) 
680-4450<tel:%28845%29%20680-4450>

_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx>
For list information or to unsubscribe,  visit: 
http://www.unidata.ucar.edu/mailing_lists/

--
Scanned by iCritical.



  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: