t Conceptual Building blocks for “Plug-and-Measure”

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 95 of 233 service request r + t à ß service response p AP Subject Service PEP PIP PAP PDP IdP r à authentication request for t authentication response authorisation decision authorisation request for

r,t

request policy for

r,t

policy t ß ß ß ß ß ß request ticket t ß ß ß p Figure 6-12: Abstract Access Control Pattern 6.8.3 Access Control Tasks The major tasks of access control comprise - Profile Management section 6.8.3.1, - Identity Management section 6.8.3.2, - Authentication section 6.8.3.3, - Authorisation section 6.8.3.4 - Policy Enforcement section 6.8.3.5 and - Policy Management section 6.8.3.6 In the SensorSA, these tasks are supported by a set of services that are designed for an evolving heterogeneous environment and offer a high level of flexibility. Each of these tasks is defined in the following sub-sections. Their position in the abstract access control pattern is illustrated in Figure 6-13. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 96 of 233 AP Subject Service PEP PIP PAP PDP IdP ß Ide ntity Ma nag eme nt Au the ntica tion Po licy Ma nag eme nt Po licy En force me nt Au tho risa tion PP Pro file Ma nag eme nt Figure 6-13: Abstract Access Control- Pattern and Access Control Tasks 6.8.3.1 Profile Management Profile management is an essential basis of a sound security architecture. The major objective of profile management in the SensorSA context is to map a real world user to a representation in a sensor service network user registration. This representation is called a profile. A profile represents an acting entity which may be a human user or software component like a service. In order to support multiple authentication mechanisms simultaneously and to keep authorisation irrelevant information out of the access control mechanism, profiles and their identities aka principals are separated. The concept of an identity constitutes the key entity on which an authorisation decision is mounted, regardless of the underlying access control mechanism. In contrast to that, a profile provides information on the real world entity. The relation between profiles and identities is reflected in the profile and identity model specified in section 7.4. The main functions covered by Profile Management are the creation, update and deletion of instances of profiles and related information in particular references to identities.

6.8.3.2 Identity Management

An identity is the core information required to realize access control. To interlink access rules and acting entities subjects, access rules refer to identities and associated properties attributes, issued by an identity provider and verified by an authentication provider. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 97 of 233 The main functions covered by Identity Management are - management of identity related information e.g. credential management, identity attribute management, and - definition and management of identity groups.

6.8.3.3 Authentication

According to SOA-RA, 2008, authentication concerns the identity of the participants in an exchange. Authentication refers to the means by which one participant can be assured of the identity of other participants. When applied to the SensorSA profile and identity model as introduced in section 7.4, the participants are profiles of real world entities that are represented by their identities. Authentication in the SensorSA is the process of verifying the identity of a certain profile. During the authentication process an entity proves that it is allowed to act with the corresponding identity. This proof normally depends on the acting entity‟s credentials that can be, for example, what somebody has e.g. key, smart card, what somebody knows e.g. password, what somebody is e.g. biometrical data, the place somebody resides e.g. a certain computer or the skills of somebody e.g. a handmade signature. The SensorSA uses the term ticket to denote the result of an authentication process. Note: Synonymous terms for ticket are assertion e.g. in the context of SAML, see section 7.4.6.1, session as a temporarily valid ticket or token. The issuer of an assertion acts as delegate for all service providers accepting assertions from this authentication authority. In this way an acting entity is not forced to present its credentials e.g. a secret at each service call and authentication can be done centrally. Assertions can be verified and are used for all actions that require proof of identity. In general, an assertion encompasses all identity related information that is required to perform an authorized request. Moreover assertions may contain information about the authentication provider, expiry date, etc. The main function covered by Authentication is the verification of identity related information

6.8.3.4 Authorisation

According to SOA-RA, 2008, authorisation concerns the legitimacy of an interaction. Authorisation refers to the means by which an owner of a resource may be assured that the information and actions that are exchanged are either explicitly or implicitly approved. When applied to the SensorSA access control information model section 7.4, authorisation is the process of determining whether an identity is allowed to have specified types of access to a particular resource. This is done by evaluating applicable access control information mainly consisting of an authorisation request and a policy. This information is used by the authorisation service to determine an authorisation decision. Usually, SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 98 of 233 authorisation is carried out on the basis of successfully authenticated identities that are part of an authorisation request.

6.8.3.5 Policy Enforcement

Policies or access rules can be expressed in many ways from simple access control lists to complex statements in policy languages like the OASIS eXtensible Access Control Markup Language XACML OASIS 2005. The actual application of access rules is performed through the combination of Authentication section 6.8.3.3 and Authorisation section 6.8.3.4 and the actual enforcement of access control decisions.

6.8.3.6 Policy Management

Access control tasks include the provision of means to manage access rules. The main functions covered by Policy Management are - creation, update and deletion of instances of policies, - definition and management of policy templates for certain frequently used access control patterns, and - distribution of policy templates.

6.8.4 Access Control Service Architecture

As illustrated in Figure 6-13, access control in the SensorSA is accomplished through the interaction of services, each of which fulfils one or more of the access control tasks described above: - The Profile Management Service see section 8.3.2 manages profiles and their relations to identities. - The Identity Management Authentication Service see section 8.3.3 is responsible for the management of identities, their authentication and the management of credentials. An instance of the Identity Management Authentication Service acts as both authentication provider AP and identity provider IdP. - The Policy Management and Authorisation Service see section 8.3.4 supports the management of policies, acting as policy administration point PAP as well as policy information point PIP. Moreover, as an instance of the authorisation service interface it acts as policy decision point PDP - The Policy Enforcement Service see section 8.3.5 handles the necessary interaction authentication authorisation to obtain the required access control decision and is independent of the controlled service generic. - The Service Proxy mimics the controlled service and delegates the service request to the Policy Enforcement Service. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 99 of 233 Ide ntity Ma nag eme nt Au the ntica tion Po licy Ma nag eme nt Po licy En force me nt Au tho risa tion Pro file Ma nag eme nt Identity Management Authentication Service Profile Management Service Service Proxy Policy Enforcement Service Policy Management Authorisation Service Figure 6-9: Abstract Access Control- Tasks Services In addition to the access control service infrastructure, the profile and identity model see section 7.4 as one vital part of the underlying information model, plays a key role in the access control service architecture and enables the separation of concerns. As an example, the support of different authentication methods, without compromising the whole service architecture, is made possible due to the decoupling of profiles and identities as well as the management of identities in different instances of the Identity Management and Authentication Service, each possibly supporting a different authentication method. Based on the Abstract Access control Pattern section Figure 6-12 the workflow involving relevant services can provide non intrusive access control i.e. realisation with a minimal impact on existing software components for all services specified in the SensorSA service viewpoint see section 8.3. Implementation options for non intrusive security on service and data level are described in section 10.5.1.

6.9. Conceptual Building blocks for “Plug-and-Measure”

The SensorSA aims at supporting a plug-and-measure type of operation. Plug measure hereby refers to the degree of capability to add a new sensor to a sensor network, register it in a sensor service network and access its observations through sensor services in all functional domains of a sensor service network without additional manual intervention. Together with self-healing and self-configuration characteristics of sensor networks, plug-and-measure is an application of the re-configuration capability of a sensor network that has effects upon all functional domains of a sensor service network as defined in section 6.2. Version 1 of the SensorSA offers the following basic conceptual building blocks in order to support dynamic reconfiguration of sensor networks and sensor service networks: SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 100 of 233 - naming principles for resources see section 6.5.3, - automatic discovery of resources based on a modular meta-information schema see section 6.6.3, - monitoring of sensors and service instances that access sensors see section 6.6.2 to detect sensor failures, - transactional interface to the Sensor Observation Service see section 8.2.2 to enable the registration of a sensor with the SOS and to insert observations, - sensor planning capabilities to influence the behaviour and the configuration of sensors see section 6.6.4, and - inclusion of events and their processing in the sensor service architecture see section 6.4. Section 10.12 explains the use of these building blocks and specifies typical plug-and- measure scenarios based on the SensorSA capabilities. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 101 of 233

7. Information Viewpoint

7.1. Overview

The Information Viewpoint of specifies rules and guidelines about how to define SensorSA meta-information models. These provide the structure of the information that is being accessed and exchanged in a service network. Principal guidance is given by the meta-model for information defined in RM-OA, 2007 as an extension of the ISO 19109 General Feature Model GFM. The following sections define the information model that is specifically defined to be used for the services of the OGC Sensor Web Enablement initiative. These services are described in the Service Viewpoint in section 7.

7.2. Information Model for Observations Measurements OM

The SensorSA basically adopts the specification of the Observations and Measurements OM model as defined in Cox, 2007. This information model is of core relevance for the access and interpretation of the data provided through the Sensor Observation Service. It defines an observation as “an act associated with a discrete time instant or period through which a number, term or other symbol is assigned to a phenomenon”. The phenomenon is a property of an identifiable object, which is the feature of interest of the observation. The observation uses a procedure, which is often an instrument or sensor but may be a process chain, human observer, algorithm, computation or simulator. The key idea is that the observation result is an estimate of the value of some property of the feature of interest, and the other observation properties provide context or meta-information to support evaluation, interpretation and use of the result. The model for OM describes the semantics of the observation and its related feature of interest from a user view point. In contrast, sensor-oriented models emphasise a process or data provider viewpoint. The OM model is illustrated in Figure 7-1. It defines pre-defined feature types and their relationships, thus extending the ISO 19109 General Feature Model GFM. Note: The SANY Information Viewpoint also supports further extensions of the GFM as specified in the meta-model for information of RM-OA, 2007. The key concept of the OM model is the pre-defined feature type observation and its related feature type process. These pre-defined feature types are to be used as building blocks of project-specific application schemas. An observation has the following characteristics: - An observation is modelled as a feature type whose instances are created at a specific time point or time period, the samplingTime. An observation may have been processed after sampling. The resultTime reflects the time when the result of the observation was produced. Observations may be members of ObservationCollections. - The key properties of an observation modelled as association roles in Figure 7-1 are its featureOfInterest, observedProperty, procedure and result: