Project

General

Profile

Actions

Bug #2939

closed

Add ability to access password protected EarthGrid data from within Kepler

Added by ben leinfelder over 16 years ago. Updated about 16 years ago.

Status:
Resolved
Priority:
Normal
Category:
data access
Target version:
Start date:
09/06/2007
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
2939

Description

When using EMLDatasource actor (say, after searching a metacat repository), process all associated dataset access rights to determine which are accessible for the public or the authenticated user.
Likely that only the first one is processed right now.

Actions #1

Updated by ben leinfelder over 16 years ago

Determine individual dataset access rights when using EML datasource actor

Actions #2

Updated by ben leinfelder over 16 years ago

Looks like this will involve changes to the webservices in seek project.
EcogridGetToStreamClient.get() method has no session parameter...
Similarly, EcogridQueryClient.query() method does not include session parameter.
Will also need to extend the configuration of the EcoGridQuery sources to include endpoints for authentication...and integrate that with the AuthenticationManager so that we get appropriate credentials to send to each EcoGridQueryInterface service.

Actions #3

Updated by ben leinfelder over 16 years ago

Here's a look at what I have completed so far on my local workspace:
seek:
-created 2 new EcoGridQuery methods: authQuery() and authGet() that take credential parameters (sessionId)
-created metacat implementations for the new authXXX() methods

kepler:
-created new AuthenticationAction that uses existing AuthenticationManager to log users into selected domain
-added logout/unauthenticate capability via the AuthenticationAction (revokes the ProxyEntity for that domain)
-implemented unauthenticate() for the LDAPAuthenticationService ("SEEK" domain)
-dummy implementation of unauthenticate() for the GAMAAuthenticationService ("GEON" domain)

And here is a preliminary look at what there is still to do:
seek:
-implement "dummy" authXXX() implementations for DIGIR
-pass on the task of implementing authXXX() methods for SRB (Lucas?)
-revisit EcoGridRegLevelOneService...alter the service such that
a) ...something like serviceCluster objects are returned. These would be groupings of associated ecogrid services with a shared authentication domain.
b) or include an authenticationDomain element for each ecogrid service entry.

kepler:
-implement unauthenticate() in GAMAAuthenticationService (for real)
-add mechanism for associating services with each other and/or an authentication domain
-this either depends on or it informs changes to the registry service in the seek project above
-refactor areas in Kepler that interact with EcoGridRegLevelOneService and EcogridRegEntryType objects if that schema does indeed change
-integrate EcogridRegEntryType with existing EcogridRepository objects (there's currently a mismash of resource bundles and config xml files to go along with the services that are looked up in the registry). I might be off-base in thinking they should go under one roof, but they seem quite similar.
-things like the EMLDatasource actor should store something more complex than a plain query service endpoint so that they can access private data using authGet() calls. A complex query service object that has both an authentication endpoint and a query endpoint would be the minimum requirement (but we'd likely want to integrate that into the AuthenticationManager's idea of a "Domain").

I'm sure there are other areas that will be affected by ecogrid service changes, but this is a decent starting point to get things stirred up.

Actions #4

Updated by ben leinfelder about 16 years ago

Changes to the registry (proposed)
I've augmented the existing EcogridRegEntryType with two elements:
-authenticationDomain
-clusterName

The authenticationDomain is a complex element that names and describes (with an endpoint) how to authenticate when using the service with this authenticationDomain.

The clusterName is a string that serves to tie services together as a node or cluster of services. I've assumed that services that share the same clusterName should also share the same authenticationDomain. It may be the case that clusterName is extraneous and that we can simply use the authenticationDomain/domainName to cluster related services together.

an example of the added elements are:

<authenticationDomain>
<domainName>localhost</domainName>
<serviceOperation>serviceOperation</serviceOperation>
<serviceURL>http://localhost:8080/knb/services/EcoGridAuthLevelOneService&lt;/serviceURL>
<serviceClass>org.kepler.authentication.LDAPAuthenticationService</serviceClass>
</authenticationDomain>
<clusterName>localhost</clusterName>

Actions #5

Updated by ben leinfelder about 16 years ago

This has been included with RC1 and the Ecogrid-1.0.0 upgrade

Actions #6

Updated by Redmine Admin almost 11 years ago

Original Bugzilla ID was 2939

Actions

Also available in: Atom PDF