SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 192 of 233
-
What is the level of trust that can be established between a service chain and its elements?
-
What is the authentication method for all services involved chain elements? For the following we assume that a service chain is encapsulated by service e.g. a WPS,
that could be implemented as a BPEL process. In practice we find variations of two different approaches.
10.5.2.1 Delegate Anonymous Service Chain
A Delegate Service Chain is considered to act on behalf of the subject invoking the service chain. A Delegate Service Chain therefore does not necessarily possess an identity; instead
identity information of the invoking subject is presented to every service chain element. Thus, the service requestor has to provide identity information that has the necessary privileges for
each element of the service chain.
Service 1 Service 3
Subject
Service Chain
Service 2
ID
ID ID
ID
Figure 10-12: All elements accept identities ID from one IdP
In the case that all elements accept request from single IdP the overhead of maintaining the various policies lies in the responsibility of the respective service provider.
In the case that all elements accept requests from different possibly their own IdPs the overhead of acquiring the proper identities lies in the responsibility of the subject.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 193 of 233
Service 1 Service 3
Subject
Service Chain
Service 2
ID 2 ID 1
ID 3
ID 1 ID 2
ID 3
Figure 10-13: All elements accept identities from different IdPs 10.5.2.2 Identifiable Service Chain
In this approach a Service Chain is considered a subject and therefore has its own set of identity information. By using this pattern the service chain will not forward the service requestor‟s
identity. Instead, a dedicated service chain identity is presented on every request. This approach is in line with the philosophy of the SensorSA Access Control Framework, however it implies a
somewhat higher level of trust between Service Chain Elements and the Service Chain as the actual subject invoking the service chain may remain transparent to service.
Service 1 Service 3
Subject
Service Chain
SC ID
Service 2
ID
SC ID SC ID
Figure 10-14: All elements accept identities from one IdP SC ID = service chain ID
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 194 of 233
If all elements accept requests from a single IdP, the overhead of maintaining the various policies lies in the responsibility of the service provider.
Service 1 Service 3
Subject
Service Chain
ID
Service 2
ID 1 ID 2
ID 3
Figure 10-15: All elements accept identities from different IdPs
In the case that all elements accept request from different possibly their own IdPs, the overhead of acquiring the proper identities lies in the responsibility of the service chain.
10.5.2.3 Applicability for Ad Hoc Service chains
