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/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 (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.
