SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 189 of 233
among other factors, on the cloud coverage. Thus, the tasking request might consume any amount of time before being fully executed.
10.5. Policies for Access Control
The services performing the access control tasks see section 8.3 cover major parts of the abstract access control pattern as introduced in section 6.8.2. In the following some interaction
patterns and methods to use this Access Control Framework are presented.
10.5.1 Patterns for Non Intrusive Access Control
The stateless nature of SOAs causes that in principal no lasting connection between client and service is established. Therefore, each service message has to include the application context.
This is one of a number of reasons why security measures, especially access control, have to be positioned on the message level Kanneganti and Chodavarapu, 2008. Note, however, that
established Internet security measures such as SSL Secure Socket Layer for the encryption on transport layer may be used in addition.
One of the more challenging goals of SOA security is to minimize interference with the actual service communication in order to relieve service designers and developers that are
experts for their particular domain from including security aspects in their work. This property is called “Non Intrusive”.
Flavours of the “Non Intrusive” property in the SOA context are:
-
The protected service remains untouched specification and implementation.
-
The body of the message that is derived from the interfaces of the service content is „not“
modified by security mechanisms.
-
From the viewpoint of the client the interface to the secured service must be unchanged so that it just depends on the access control policy on the server side if an operation is
permitted or not.
Measures towards a “Non Intrusive” access control architecture affect services as well as service messages.
10.5.1.1 “Non intrusive” at service level
The abstract access control pattern explained in section 6.8.2 implies that a Policy Enforcement Point exists for every security enabled service. One implementation pattern is a transparent
service proxy that shields an unsecured Web service and mimics the secured service. For instance, in the SensorSA W3C Web Service platform see section 9.2.1 this means that it
provides the “same” WSDL document as the underlying unsecured Web service.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 190 of 233
Figure 10-10 : Non Intrusive “compatible” Approach
Note: See Figure 10-11 for definitions of m, m‟,r and r‟. WSDL A‟ equals WSDL A, apart
from the service endpoint. A transparent service proxy is a software component that provides the same interfaces as an
underlying service but allows one to offer additional functionality that is transparent to the client. Thus, the SensorSA does not consider it to be an actual service in the sense that it does not
provide operations of its own. Nevertheless, Table 10-1 provides the description of the transparent service proxy in the same description style as the SensorSA services in section 8.3.
Name Service Proxy
Standard Specifications
The following standards are used by the Service Proxy: OASIS Security Assertion Markup Language SAML v2.0
OASIS SAML 2.0 profile of XACML v2.0 Description
The Service Proxy “intercepts” service requests for the proxied service and delegates the requests to the Policy Enforcement Service. The Service Proxy
can be automatically provided by a Proxy Generator. In contrast to the entirely generic Policy Enforcement Service, in addition to the mimicked
service interface the Service Proxy may contain service specific elements. As suggested in OASIS WS-Security standards, the optional security
information encoded in SAML is provided in the SOAP header while the actual service request in the SOAP body remains unchanged.
Interface Proxy The Proxy Interface does not define operations by itself but mimics the interface of an arbitrary
web service. A software component, the Proxy Generator, is used to automatically generate a service specific Proxy.
Comments
The Service Proxy is not to be confused with a firewall. The Service Proxy does not contain any security mechanism on the transport layer level and does
not prevent a service requestor from accessing the proxied service.
Table 10-1: Description of Service Proxy
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 191 of 233
10.5.1.2 “Non Intrusive” at message level
