Copyright © 2009 Open Geospatial Consortium, Inc. 137
For the implementation of trusted Audit and Alarms, it is also relevant to have a PKI in place and trusted third parties that undertake and guarantee the correctness and
confidentiality of audit information.
13.2 Services shall support SOAP and WS-Security
In simple architectures that are based on transparent chaining, only direct communication links exist between the client and many services. Here, the use of HTTPS can be
leveraged in order to secure the communication and the security context information that is exchanged between the client and the secured service.
But in a more generic architecture, where a translucent or even opaque chaning of services shall be possible, the use of SOAP based interfaces leveraging WS-Securtiy for
securing the communication is recommended. Depending on the security model that is to be supported, X.509 certificates or other types of tokens must be created. This requires
naturally the existing of the associated infrastructure.
13.3 Describe security constraints for the service using WS-PolicySecurePolicy
Whenever a secured service, e.g. a Sensor Web Service, is provided, it is important to give the caller client or another service relevant and sufficient information to
understand the security constraints in order to execute the service. It is recommended to use WS-Policy or WS-SecurityPolicy to describe the constraints of the service. The link
to such a policy document can be hooked into the WSDL description of the service.
13.4 Protect Transient Handles
Whenever a client hence operator of a sensor web has to achieve a particular takes, it typically involve to call different interfaces of either the same service or of different
services. As the services are stateless, the relevant state information must be stored on the client side. This is done by so called transient handles. As the undertaken evaluation has
shown, it is extremely important to protect these handles towards tampering and unauthorized reading as the effect can have different consequences on the asset.
For example, the SAS returns a PublicationID, SubscriptionID and an XMPP MUC URI; the SOS returns SensorID, AssignedSensorID, ObervationID, ObservationTemplateID;
the SPS returns sensorID and taskID to the client. Transporting these transient handles in clear text creates the vulnerability that they can be read by an attacker and used in the
context of another request. It is therefore necessary to protect this part of the message in a specific way. We thing that the use of SAML profiles is a sound approach, but we also
thing that further investigations are relevant to proof this.
13.5 Support AssetIdentity based Access Control
In general, all interface operations except the GetCapabilities operation should be protected by access control. But as we have shown in the evaluation sections of this ER,
the access is not simply to be regulated for registered users. Instead, the Discretionary Access Rights Management must be used to regulate the access. For example, upon a
successful Submit operation with the SPS, the created task is owned by the caller. And
138 Copyright © 2009 Open Geospatial Consortium, Inc.
therefore, only the owner – or all identites to which the owner has granted rights to – can
call Cancel or Modify for that task. Any other user will receive deny.
13.6 Support Single-Sign-On and Identity Management Federations
