policy attachment to service/service-instance (?)

[Frank Siebenlist <franks@mcs.anl.gov>]

What follows is some rambling about how we could attach policies to services 
with abstraction mechanisms that could help on the administrative side.

Hopefully it can help to incite some more discussion on this topic, which could 
help Tim with his "elliptical" effort to see where policies should/could be 
attached in a services setting.

Note that none of this is really xacml, wspl, or ws-policy specific.

---------------------------------------------------------------------------------

* Attaching policy to type vs instance vs stateful instance

Attaching policy to a porttype/operation/message seems to use a resource on a 
high level of abstraction.

If we translate it to resource attributes, then one could define an 
"svc-type-attribute" for a resource that would be associated with the porttype 
(ignoring the finer grained operation/message for the moment).

An other resource "svc-endpoint-attribute" would be associated with the 
wsdl/port information, i.e. low level network protocol/connection port info 
bound to a particular service instance.

If one wants to support stateful services that could rebind to different 
endpoints over the lifetime, then a "svc-handle-attribute" could be used to 
identify such a unique stateful service instance.

The difference between these resource attributes is that the svc-type-attribute 
is normally a grouping abstraction. There can be many service instances with 
that resource attribute value.

The svc-endpoint-attribute and svc-handle-attribute can be seen as unique 
identifiers within their context.

In theory, the svc-endpoint-attribute value can change over time to service 
different service instances which could even be of a different service type.

The svc-handle-attribute value will not change over time. It will always be 
associated with the same service-type-attribute, while the associated 
svc-endpoint-attribute may change over time.

Within this scheme, the only truly unique identifier for a service instance is 
the svc-handle-attribute.

If we can guarantee that a service instance would always be bound to the same 
connection endpoint, then the svc-endpoint-attribute is essentially equivalent 
to this svc-handle-attribute.

If we only have a single service instance for a service type (singleton), then 
the svc-type-attribute would be the equivalent to the svc-handle-attribute.

One other grouping mechanism that seems useful as a administrative/management 
abstraction, is the grouping of the identities associated with those resources.
A svc-id-attribute could be associated with the resource identity, like 
subject's DN, principal, or raw key.
A svc-group-attribute could provide an aggregation mechanism for these identities.

---

As an example, consider a simple http-like service, which serves web pages 
through a service-interface. A particular page is requested through a parameter 
value - not visible on the service type level.

We could identify two instances of this service: one instance will serve 
sensitive information ("secret"), and the other public info ("public"). The 
associated access control policies for the two services will clearly be different.

If the svc-type-attribute values are the same, then we need to differentiate on 
the other resource attributes to attach the different policies, like 
svc-endpoint-attribute, svc-handle-attribute, svc-id-attribute, or 
svc-group-attribute.

If we want to attach the policy to the svc-type-attribute, then one other option 
would be to "artificially" change the service type (maybe use porttype 
inheritance...), and create singletons to accomodate policy specific attachment.

If we bring the abstraction level up to a level where we like to identify the 
sensitive information by itself, independent of the location/server, then is 
makes sense to attach policy to a svc-handle-attribute.

As an alternative, one could define a role/group of identities that only serves 
sensitive information, and use that as a differentiator of the target to attach 
the policy. In that case, the svc-type-attribute together with a 
svc-group-attribute could be used.

---

I don't believe that one can mandate a particular scheme, which would imply that 
   one should be able to attach policy to "all of the above".

Food for thought.

Regards, Frank.

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory