[kepler-dev] [Bug 2939] - Add ability to access password protected EarthGrid data from within Kepler

bugzilla-daemon@ecoinformatics.org bugzilla-daemon at ecoinformatics.org
Thu Nov 29 19:13:16 PST 2007


http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2939





------- Comment #3 from leinfelder at nceas.ucsb.edu  2007-11-29 19:13 -------
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.


More information about the Kepler-dev mailing list