The shortness of the OAuth chain worried me, it is nice to know there is an
alternative.
Could you let me know when your proof-of-concept project works? Or even
before then, once it is clear what a third-party data processor needs to do
in order to implement access ? As a third party, am I running a MyProxy
service, or merely using it? Needless to say, I do not yet get it.
Benno
On Mon, Mar 14, 2011 at 11:53 AM, <philip.kershaw@xxxxxxxxxx> wrote:
> Hi Benno,
>
> I was hoping there were others who had been doing work with OAuth! :)
>
> The WMS client mentioned in the presentation did indeed share the same
> domain as the WMS. It worked but obviously not a satisfactory solution for
> accessing secured services across multiple sites. I'm working on a short
> proof of concept project now where we are using the 'classic' Grid-based
> solution for delegation with proxy certificates. The ESGF security model
> already supports authentication with PKI credentials – standard X.509
> certificates. It's a small change to enable support for proxy certificates
> and thus enable full delegation capability.
>
> The scenario is, a user signs in at a portal with OpenID. A special
> MyProxy service is then used to do a credential translation from the OpenID
> to PKI based credentials. The portal can use these on the behalf of the
> user to access other ESGF-security aware services be they WMS or OPeNDAP
> based. With proxy certificates you can have a longer chain: the portal
> calls a WPS which executes a job which itself retrieves data from secured
> OPeNDAP services.
>
> OAuth could be a viable alternative but for the moment proxy certificates
> have the most straightforward approach.
>
> Cheers,
> Phil
>
> From: Benno Blumenthal <benno@xxxxxxxxxxxxxxxx<mailto:
> benno@xxxxxxxxxxxxxxxx>>
> Date: Mon, 14 Mar 2011 10:37:33 -0400
> To: Philip Kershaw <philip.kershaw@xxxxxxxxxx<mailto:
> philip.kershaw@xxxxxxxxxx>>
> Cc: <thredds@xxxxxxxxxxxxxxxx<mailto:thredds@xxxxxxxxxxxxxxxx>>, <
> caron@xxxxxxxxxxxxxxxx<mailto:caron@xxxxxxxxxxxxxxxx>>
> Subject: Re: [thredds] Proposal for handling authorization credentials in
> thredds....
>
> 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 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 (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
> --
> 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
