Kepler

Determine individual dataset access rights when using EML datasource actor

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.

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.

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>

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

Original Bugzilla ID was 2939