Eco Grid Auth Design

This is version 4. It is not the current version, and thus it cannot be edited.
[Back to current version] [Restore this version]

In order to allow access to private or protected EarthGrid data (via Kepler, for instance) some of the services have been modified.

New search and retrieval methods

EcoGridQuery

authQuery
authGet

These methods take an additional credential parameter. The credential should be returned by a successful call to the EcoGridAuthLevelOneService login method.

Modified Registry Entry records

Currently there is not a good way to associate services that are in the Registry as related to each other. For example, there is no way to explicitly say that "authenticationService123" should be used to authenticate before querying "queryService345". It would be nice to group services that are deployed on the same node as a cluster. A proposed change to the EcogridRegEntryType (xsd):

add 'clusterName' element to each registry entry. It would then be the responsibility of any consuming app (Kepler) to group those for use with a shared authentication service (just another service that is part of the cluster).

Kepler and the Registry

Kepler has an AuthenticationManager feature that uses a notion of "authentication domains" to manage authentication for EarthGrid services (and, I believe, other authentication tasks yet TBD). There's talk of using the registry to also store these authentication domains, but there exists some overlap with the service definitions and the authentication domain definition (endpoints, essentially).
One approach would be to embed an authenticationDomain element within each Ecogrid service defined in the registry. This would tell Kepler exactly how (and where) to authenticate before using the methods that require authentication credentials. But it's somewhat redundant to have the authentication domain included for every service listed in the registry (not to mention super kepler-specific). There is a meeting scheduled for 01/16/2008 1 pm PST where more concrete decisions can be made about these authentication modifications.
A snippet of what an embedded authenticationDomain would look like in a Registry entry is below:

<?xml version="1.0"?>
<reg:EcogridRegEntry
	xmlns:reg="ecogrid://ecoinformatics.org/ecogrid-regentry-1.0.0beta1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="ecogrid://ecoinformatics.org/ecogrid-regentry-1.0.0beta1 EcogridRegEntryType.xsd ">
	<authenticationDomain>
		<domainName>localhost</domainName>
		<serviceOperation>serviceOperation</serviceOperation>
		<serviceURL>http://localhost:8080/knb/services/EcoGridAuthLevelOneService</serviceURL>
		<serviceClass>org.kepler.authentication.LDAPAuthenticationService</serviceClass>
	</authenticationDomain>
	<clusterName>localhost</clusterName>
	<serviceName>Dora's Metacat EcoGrid QueryInterface</serviceName>
	<wsdlURL>http://localhost:8080/knb/schema/EcoGridQueryInterfaceLevelOne/EcoGridQueryInterfaceLevelOne.wsdl</wsdlURL>
	<serviceType>EcoGridQueryInterface</serviceType>
	<endPoint>http://localhost:8080/knb/services/EcoGridQuery</endPoint>
	<serviceClassification>Query Level One Class</serviceClassification>
	<description>EcogridServiceRegistry</description>
	<provider>dora</provider>
	<documentType>
		<namespace>eml://ecoinformatics.org/eml-2.0.1</namespace>
		<label>Ecological Metadata Language 2.0.1</label>
	</documentType>
</reg:EcogridRegEntry>

Go to top More info... Attach file...

This particular version was published on 16-Jan-2008 09:32:14 PST by uid=leinfelder,o=NCEAS.