Re: policy attachment to service/service-instance (?)

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

A few more additions that hopefully help to clarify some of the introduced concepts:

* service endpoint information is not a very warm-body friendly attribute to 
attach policy on. You probably want to minimize the exposure of protocol and 
network-addresses/port-numbers in higher level admin tools.

* there can be multiple bindings for the same service instance - e.g. the 
service can listen for requests over http/soap as well as a MQ/soap.
This implies that the svc-endpoint-attribute will uniquely identify a service 
instance, but a service instance may not uniquely identify a single 
svc-endpoint. This would be an other argument for a higher level concept like 
this svc-handle-attribute.

* webservices doesn't really have a notion of a service "instance", which would 
be the equivalent of an object in corba speak, and so no easy way to refer to 
them. For that reason, ogsa has introduced these service handles as instance 
identifiers.

* service handles are not warm-body friendly either, and not suitable for use in 
admin tools directly. Most use that we see is for dynamically generated policy. 
For example, the creator of a service instance becomes the owner with associated 
rights, and who can assign access rights to others.

* in ogsa, service instances have so-called service data which is instance 
specific. This could be used to classify certain instances of the same service 
type, which again could facilitate the attachment of policies and policy 
expressions.

* for our grid applications, we want to bring the abstraction a service instance 
down to the database row level.
End point information could be "virtual". The physical endpoint information of 
network-address/port could be a part of the whole endpoint info, and point at a 
hosting environment that hosts multiple service instances and multiplex their 
access to the outside. (Note that most corba implementations did not really 
support such fine-grained objects very well, and were more geared towards 
coarse-grained "objects".)

* If neither svc-endpoint-attribute nor svc-handle-attribute can be used 
directly in human admin tools, we need to find alternative strategies through 
the use of friendlier svc-type/id/group-attribute or others.

* by attaching policy to a svc-type-attribute, one essentially "overloads" the 
service type name with a policy meaning (which may be perfectly ok).
For example, one could define a "secure-acme-svc" from a "public-acme-svc", 
which essentially would have the same operations, and the purpose of the 
difference in name is only to accomodate appropriate policy attachment to these 
service types.

* Note that a single identity can be associated with many service instances like 
in a services hosting environment, but a service instance should be associated 
with a single identity.
This complicates the idea of using the grouping of service instances through 
their associated identities for policy expressions/attachments.


-Frank.


Frank Siebenlist wrote:

> 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