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

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