| At line 10 added 3 lines. |
| + The Metacat implementations of these new methods have been coded and are ready to be committed to the SEEK project. Placeholder 'implementations' have been added for SRB and Digir as well. These placeholders ignore the authentication credential parameter and call the existing service implementation methods that do not require authentication (query() and get()). |
| + |
| + |
| At line 14 added 38 lines. |
| + |
| + !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> |
| + }}} |
| + |
| + If the authenticationDomain element were omitted from registry service entries, and the registry listing included both an entry for the authentication service (with type {{<serviceType>EcoGridAuthInterface</serviceType>}}) where the clusterName tied this authentication service to an {{EcoGridQueryInterface}} type service we'd be close to solving the clustering problem. BUT...we would need a place to specify the authentication domain {{<serviceClass>org.kepler.authentication.LDAPAuthenticationService</serviceClass>}} element. Kepler uses this to present the user with the correct interface to login using the Ecogrid service. |
