48
Copyright © 2015 Open Geospatial Consortium.
8.4 Support for Common Security in typical modern Web Browser based applications
Obviously, a Web Browser application is able to leverage general and in particular security related functions provided by the executing container; the Browser. In addition,
the execution inside a Browser introduces limitations caused by the security sandboxing to prevent content injection attacks leveraging cross-site scripting. Even though it is
outside the scope of this ER to go into details, two dominant limitations exist: i Same Origin JavaScript related functions are limited to call content from “same” domains and
ii Mixed-content is either blocked or flagged in the browser application that was loaded via HTTP uses content loaded over HTTP. The implementation has to overcome
these and other Browser constraints. There is no explicit guidance or standardization required from OGC.
Modern Web Bowser usually support HTTP RFC 2616, HTTP over TLS RFC 2818, HTTP Authentication RFC 2617 and HTTP Cookies RFC 2965 which already enables
to implement Common Security based on HTTP as outlined in sections 4.4.1 and 4.4.2.
Important is also the built-in support of general processing functions that are simply available when implementing a client application to run as a Browser app:
1 JavaScript provides a wide spectrum of important processing functions. 2 Processing of XHTML content with support for automatic handling if JavaScript
is enabled 3 Processing of HTTP status codes and HTTP Cookies
4 Validation of SSLTLS certificate when using HTTP+TLS connections, with the option of checking CRLs
5 Support for minetype specific execution of external applications Observing the general functions of a Web Browser unveils that XML processing support
is not available.
8.5 Support for Common Security in desktop Applications
In contrast to web applications that run inside a Web Browser, a desktop application is executed on the Operating System. This implies that there is no pre-existing skeleton of
communication and processing functions to leverage. Any function must be integrated by importing the right library. Further, the proper use of the library must be enabled. One
non-trivial example among many is the proper validation of HTTPS connections with support of HTTP cookies over HTTP redirects.
Therefore, logically OGC standardization should mandate a particular set of HTTP communication: general and security specific IT functions that are to be implemented
Copyright © 2015 Open Geospatial Consortium.
49 with a client that is capable to interact with an OGC Web Service that offers Common
Security. Contrary to applications that run inside a Web Browser, the extensive processing of XML is usually part of desktop applications. In that sense, it seems
reasonable to believe that these clients should be able to support Common Security implemented using SOAP + WS-.
Desktop applications should be able to support different implementations of the Authentication framework. In particular, an implementation shall support RFC 2617
HTTP Authentication, RFC 6749 OAuth2 Tokens, RFC 5246 TLS mutual and SAML ECP. The support for SAML as a federated authentication solution is according
to the Gardner Group gaining momentum for enterprises to interconnect, independent from security domains. Some requirements:
Validation of SSLTLS certificates is required. Support HTTP Cookies RFC 2965 to maintain a security context across requests
is required. Desktop client use of HTTP status codes and processes OGC specific XML
encoded exceptions is required. The latter can usually be limited to display the content of the exception to the user rather than programmatic actions.
9 Conclusion, Recommendations to OGC standardization and future work
