--=======12D69E9======
Content-Type: text/plain; x-avg-checked=avg-ok-3416747B; charset=us-ascii;
format=flowed
Content-Transfer-Encoding: 8bit
Hello All,
We faced a similar issue for our federated system, a possible solution
could be to develop a de-coupled "security manager" component as front-end
of the "catalogue manager" component. Practically, each THREDDS
request/response is mediated by the "security manager" component
before/after being processed/returned by the "catalogue manager" component.
Hence the "catalogue manager" component doesn't change its behavior and
THREDDS clients don't have to implement any new functionality.
The "security manager" component is in charge of implementing different
security policies, reading opportune metadata which characterizes datasets
returned by the "catalogue manager" component. For lightly restricted
policy, the "security manager" component caches the dataset information
returned by the "catalogue manager", instead it returns to user an HTML
form; this form asks user for policy acceptance; cached dataset information
is returned only after the form is returned duly filled. In future, this
components could be used to manage distributed authorisation issue, as well.
Loosely coupling of the "catalogue manager" and "security manager"
components can be achieved by means of web-services technology.
---Stefano
>Hello Benno / All-
>I have just started to address this same problem here at NCDC- with some
>of the NCEP model input datasets such as EU obs, and aircraft data sets.
>My latest solution (I've not started serving these data yet) is the web
>page solution. Not at all the best- since the whole DODS thing is a
>wash. I would be open to other solutions but for now am forging ahead
>with a separate link to restricted (WMO40) datasets and the users must
>click to "accept" the terms.....
>
>So yes- NCDC/NCEP would be users of something more in line with
>distributed access methods.....Glenn
>
>Benno Blumenthal wrote:
>
>>John Caron wrote:
>>
>>>thats an interesting issue. i suppose we can add an optional attribute
>>>to the documentation element, like mustNotify="true" which means to
>>>clients that they should pop up the contents of the documentation
>>>element and have the user press "Accept". Do you think that would suffice?
>>
>>
>>
>>I want to say yes, something like that would work, but that supposes,
>>
>>1) all THREDDS clients would do the right thing, and
>>2) all DODS/OPenDAP/WCS/ADDE clients would display the restrictions in
>>the THREDDS catalog.
>>
>>
>>1) is possible at this stage of THREDDS, I think, but 2) seems pretty
>>unlikely. It would really take a communal commitment to this sort of
>>thing to make it work, and I am not sure the interest is really
>>there. The alternative is for me to set up user names and passwords so
>>that I (as the original server) can take care of challenging the user
>>using HTTP and then allowing the user to use the data. Not my favorite
>>solution, but at least it works.
>>
>>
>>Benno
>>
>>
>>>I realize THREDDS is mostly about freely exchanged data, and restricted
>>>data is OK too because the underlying data server is responsible for
>>>restricting access to the data. But there is another class of data
>>>which required display of some agreement as a condition for use.
>>>
>>>The classic example is WMO40, the key phrase being "must provide this
>>>same notification" ,e.g.
>>>
>>>*The following data and products may have conditions placed on their
>>>international commercial use. They can be used within the U.S. or for
>>>non-commercial international activities without restriction.
>>>Re-distribution of these data by others must provide this same
>>>notification. A log of IP addresses accessing these data and products
>>>will be maintained and may be made available to data providers. *
>>>
>>>*For details, please consult: *
>>>
>>>*http://www.wmo.ch/web/ddbs/jen/AdditionalData&Products/AdditionalData&Products.html
>>>
>>><http://www.wmo.ch/web/ddbs/jen/AdditionalData&Products/AdditionalData&Products.html>
>>>
>>>
>>>*
>>
>>
>
>
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.587 / Virus Database: 371 - Release Date: 12/02/2004
--=======12D69E9======
Content-Type: text/plain; charset=us-ascii; x-avg=cert;
x-avg-checked=avg-ok-3416747B
Content-Disposition: inline
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.587 / Virus Database: 371 - Release Date: 12/02/2004
