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

  • To: Benno Blumenthal <benno@xxxxxxxxxxxxxxxx>
  • Subject: Re: [thredds] Proposal for handling authorization credentials in thredds....
  • From: Ben Domenico <Ben@xxxxxxxxxxxxxxxx>
  • Date: Mon, 14 Mar 2011 09:24:11 -0600
Hi all,

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

<http://www.opengeospatial.org/projects/initiatives/shibbolethie>-- Ben

On Mon, Mar 14, 2011 at 8:37 AM, Benno Blumenthal <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> 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>>
>> Date: Sat, 12 Mar 2011 07:01:05 -0700
>> To: <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 <3%2F10%2F2011>3/10/2011 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>> 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>).
>>
>> 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>
>> For list information or to unsubscribe,  visit:
>> http://www.unidata.ucar.edu/mailing_lists/
>>
>>
>>
>> --
>> 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   <%28845%29%20680-4450>(845)
>> 680-4450
>>
>>
>> _______________________________________________
>> thredds mailing list
>> 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> For list
>> information or to unsubscribe, visit:
>> http://www.unidata.ucar.edu/mailing_lists/
>> --
>> Scanned by iCritical.
>>
>
>
>
> --
> Dr. M. Benno Blumenthal          benno@xxxxxxxxxxxxxxxx
> International Research Institute for climate and society
> The Earth Institute at Columbia University
> Lamont Campus, Palisades NY 10964-8000   (845) 680-4450
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: