Threat Mitigation in RESTful Environment

Copyright © 2010 Open Geospatial Consortium, Inc. 93 The suggested approach for the security implementation within a REST service is either 2-way SSL or HTTP Basic Authentication over 1-way SSL. This will provide point-to- point or transport level security. There are no specific standards for implementing security in a RESTful web service, although there are common practices. Table 38: Realization of security measures in a RESTful environment Security measure Realization Authentication In two-way SSL authentication mutual authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL- client application. Two-way SSL authentication is also referred to as client authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client. Either self-signed certificates or certificates released by a trusted CA such as VeriSign can be used. In any case it is important to check the certificate for validity, including validation of revocation lists and the trusted root certificates. In the context of web browser clients, the use of the SAML 2 Web Browser SSO Profile can be used to create a security context that is typically maintained in secure cookies cookies that are only transmitted via HTTPS connections. Http Basic Authentication over one-way SSL enables the application operating as the SSL client to verify the identity of the application operating as the SSL server. The server can implement or use an existing identity management system API, such as SAML, OpenAuth or OAuth, to verify a users identity. This would require the users of the service to have an account with the third party - the Identity Provider. Authorization In an SSL implementation, either one-way or two-way, the digital certificate can contain information about a user including their role. The web service could authorize access to data based on the user’s role. Authorization could also be achieved via custom code implemented inside the service that would allow an administrator to configure access to individual users or a group of users. A developer could leverage existing third party identity management system APIs and data stores, such as an LDAP repository, to determine access controls on their service. 94 Copyright © 2010 Open Geospatial Consortium, Inc. Security measure Realization Non-repudiation In a two-way SSL authenticated system, if both sides use digital certificates generated by a trusted certificate authority CA, such as VeriSign, to do their auditing of interactions, then both parties are protected. With Basic HTTP authentication with one-way SSL, only trusted audit at the service side is possible. This audit log needs to be confidential and integrity protected to both the client and the service party to ensure trustworthiness. Data confidentiality Confidentiality of the information being passed is the main purpose of the SSL and TLS protocols. SSL is a secure way of transferring information between two points on the internet using encryption. When data is being passed between the client and the server on a network, the SSL responses are encrypted so that the data cannot be deciphered by a third party and the data remains confidential. Data integrity When data is being passed between the client and the server on a network, SSL helps guarantee that the data will not be modified in transit by that third party. Availability Responsibility for availability is placed on the server. Availability is slightly addressed with SSL since secure communications prevent malicious users from having direct access to the system. Privacy SSL provides privacy. It is provided through encryption, which scrambles traffic so that it is incomprehensible to a potential eaves dropper. Communication security SSL technology allows web browsers and web servers to communicate over a secure connection. In this secure connection, the data is encrypted before being sent, and then is decrypted upon receipt and before processing. Both the browser and the server encrypt all traffic before sending any data.

8.2 Reliability

Reliable delivery of notifications is a feature that is required in mission critical systems. Usually, additional technology is put in place to realize it. For SOAP, WS-ReliableMessaging [2] is such a technology. It enables the following delivery assurances: AtLeastOnce , AtMostOnce , ExactlyOnce and InOrder . Service providers may indicate which assurances they support using policy statements. Likewise, clients can request certain assurances using policies. Copyright © 2010 Open Geospatial Consortium, Inc. 95 A more detailed discussion of reliable messaging technology for SOAP and RESTful bindings is provided in chapter 8.8.1 of OGC 09-032. 9 Event filtering In this chapter, various aspects that are relevant for event filtering are discussed. The first section elaborates the pitfalls that exist when filtering at an Event Service. The second section discusses languages for filter processing events. Finally, spatial filtering of events is investigated in more detail.

9.1 Potential Pitfalls

This section briefly discusses some of the general pitfalls that need to be avoided for doing useful filtering with an Event Service.

9.1.1 Boolean Result for Filter Statement

An Event Service matches events that it generates or that it receives from some publishers against the existing subscriptions. The service needs to decide whether a given event matches a subscription’s filter criteria or not. Therefore, the filter used in the subscription needs to evaluate to a boolean value. A filter language needs to define very clearly how such a result is computed. For example, an XPath expression may have a set of XML nodes as result. If no further rules are defined how the Event Service should handle the result of the XPath expression, it will produce an exception. Further details on how XPath expressions should be handled are provided in section 9.2.2. Here, the following observation is important: in order for a filter language to be usable in an Event Service, either the language itself clearly defines how to achieve a boolean result out of a filter statement encoded in that language or the Event Service defines the required rules. In the case of XPath, the Event Service could for example apply an implicit boolean function call to the results of an XPath expression – see section 9.2.2 for further details. If a subscription does not use a filter language but some form of processing language to identify the events that are of interest, the requirement to have a boolean result does not apply. The processing language then defines the results that are sent to a subscription’s consumer endpoint. The Event Pattern Markup Language is such a processing language see section 9.2.3.

9.1.2 Event Wrapper

Another problem to perform filtering processing at an Event Service may arise if the service is instructed to or automatically applies a wrapper format to an event before a filter is applied to it. If the service does not indicate the exact behavior in this situation, then subscription filters may not work as expected. In cases where the Event Service implementation uses a wrapper that is only a message container for multiple events, it should apply content based filtering on each of the events contained in the wrapper. The WS-Notification Notify message represents such a container.