Add ability to access password protected EarthGrid data from within Kepler
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.
#2 Updated by ben leinfelder about 12 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.
#3 Updated by ben leinfelder almost 12 years ago
Here's a look at what I have completed so far on my local workspace:
-created 2 new EcoGridQuery methods: authQuery() and authGet() that take credential parameters (sessionId)
-created metacat implementations for the new authXXX() methods
-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:
-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.
-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.
#4 Updated by ben leinfelder over 11 years ago
Changes to the registry (proposed)
I've augmented the existing EcogridRegEntryType with two elements:
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: