Registry metadata of individual secured services

Security requirements of science services

When we have secure web services (very soon now, hopefully), we will need some way to note in the registry that they require their request messages to be signed. Clients that can't sign (no credentials, or no code for signing) will avoid these services. Clients that can sign will get in first time (instead of, say, having an unsigned request rejected and working out from the SOAP fualt what should have been done).

The registry-data-model team has drafted changes to the Interface element in the resource metadata that express the security needs. A secured web-service should write its interface like this:

  <vr:interface xsi:type="vs:WebService">
  <vr:accessURL>http://address.of.server:8080/context/path/to/service</vr:accessURL>
    <vr:securityMethod standardID="ivo://ivoa/standards/SSO-methods#digital-signature"/>
  </vr:interface>

The vr:securityMethod names the required security operations via its standardID attribute, and standardID is defined to take a URI. I've used an IVO-ID as a unique, formal ID for the digital-signature profile, but any fixed, agreed URI would do. This is all that's needed since the digital-signature standard doesn't need or allow variation between services.

If we later find that we need to revise the digital-signature standard, making version 1.1, say, then we may need a service that supports both v1 and v1.1. We can express this in this way:

  <vr:interface xsi:type="vs:WebService">
      <vr:accessURL>http://address.of.server:8080/context/path/to/service</vr:accessURL>
    <vr:securityMethod standardID="ivo://ivoa/standards/SSO-methods-v1.0#digital-signature"/>
  </vr:interface>
  <vr:interface xsi:type="vs:WebService">
    <vr:accessURL>http://address.of.server:8080/context/path/to/service</vr:accessURL>
    <vr:securityMethod standardID="ivo://ivoa/standards/SSO-methods-v1.1#digital-signature"/>
  </vr:interface>

i.e. two identical interfaces, with the same endpoint, that differ only in their security arrangements. In this case, the two interfaces will be inside the same Capability, and will therefore be implied to have the same semantics in the service itself. I.e., they do the same thing once the request gets through the security checks. Therefore, a client finding multiple interfaces assumes that they are equivalent and uses any one that it knows how to drive.

At the moment, the security-methods document allows only one method for any given interface. Suppose, in a later version, that we allow multiple methods, e.g. signature and encyption. We can then write

  <vr:interface xsi:type="vs:WebService">
  <vr:accessURL>http://address.of.server:8080/context/path/to/service</vr:accessURL>
    <vr:securityMethod standardID="ivo://ivoa/standards/SSO-methods#digital-signature"/>
    <vr:securityMethod standardID="ivo://ivoa/standards/SSO-methods#xml-encryption"/>
  </vr:interface>

where the existing of securityMethod elements as siblings means that all the methods are required in each request; they are not alternatives.

The delegation service

We agreed to support Globus-style delegation of credentials (and possibly to copy the delegation code from Globus or its derivative tool-kits). For web-services, this means that there is a SOAP endpoint associated with a science service by which proxy credentials can be passed to the service. This endpoint has a distinct pair of SOAP operations to move the credentials; the delegation protocol can't be added as extra parameters to the existing operations of, say, SkyNode. The delegation service may be merged in on the same endpoint as the science service, or it may be on a separate endpoint. There may be a separate delegation service for each science service at a site or all science service may share one delegation service. The implementor chooses how to arrange the services (Globus uses one shared delegation-service per site on a dedicated endpoint).

Thus, in the general case, the delegation service needs to be registered as a separate interface to the science interface, because it may need its own endpoint. The recent work of the registry-data-model team proposes that services with mutiple capabilities be registeredwith multiple Capability elements. We can write

 <vr:Capability xsi:type="some science capability">
   ...
   <vr:interface xsi:type="vs:webService">
      ...
   </vrInterface>
   ...
 </vr:Capability>
 <vr:Capability standardId="ivo://ivoa/delegation-service/">
   <vr:interface xsiType="webService">
      <vr:accessURL>http://address.of.server:8080/path/to/delegation/service</vr:accessURL>
   </vr:interface>
 </vr:Capability>

Note that the second capability doesn't have an xsi:type. It doesn't need one as its sementics are fully fixed by the standardId attribute and it has no metadata beyond the basic Capability type.

Note also that the interface to the delegation service doesn't have a securityMethod. This interface isn't secured by digital signature in the manner of the science interface. Instead, the signed credentials are part of the request method to the delegation service.

The MyProxy service

We have chosen to use NCSA MyProxy as the means by which clients retrieve credentials. Each site where users log on to the IVO (NVO calls then User Authentication Services; AstroGrid calls them Community services) has to run a MyProxy service. Clients need to be able to find these services, so they must be registered.

(There may be a difference of approach here. NVO favours web portals, and such a portal could, possibly, have a hard-coded list of UASes. AstroGrid favours desktop clients and explictly requires to find Community services through the registry. Therefore, in the general case, the MyProxy services must be registered.)

Following the new models of services-with-capabilities, a UAS/Community is one logical service in which MyProxy is one of its Capability blocks. We can write

 <vr:Capability standardId="ivo://ivoa/MyProxy-service/">
   <vr:interface xsiType="vr:webBrowser">
     <vr:accessURL>myproxy://address.of.server:7512</vr:accessURL>
   </vr:interface>
 </vr:Capability>

I've assumed that MyProxy needs no special metadata other than its endpoint. Therefore, I've used the standard Capability type.

The type of interface is a problem. I've used vr:webBrowser to avoid defining a new type and therefore needing a schema for MyProxy; nothing else needs a special schema and I prefer to avoid making one. However, calling MyProxy a web-browser interface isn't really correct; and myproxy:// isn't a commonly-used scheme for URIs. If we decide that we need a custom Capability-type for Myproxy, then we should take the chance to define a MyProxy interface-type. We might then use separate address and port elements instead of an accessURL.

Warning about URIs for standards

The URIs denoting standards in the sections above are just for illustration. It would not be appropriate to use these particular URIs in resource documents.

-- GuyRixon - 12 May 2006