See the Bibliography appendix.

The normative provision of this standard is available by this URL

https://www.opengis.net/doc/IS/security/1.0

All Conformance Classes in this standard are identified by a URI with this base:

https://www.opengis.net/spec/security/1.0/conf/cc

All Conformance Tests in this standard are identified by a URI with this base:

https://www.opengis.net/spec/security/1.0/conf/cct

A URN identifier with this base identifies all Requirements Classes in this standard:

urn:ogc:specification:security:1.0:rc

Requirement Class URN identifiers are used in the <ows:Constraint> element to identify the nature of each constraint. These URNs serve as identifiers only and are not expected to be resolvable.

Requirements Classes in this standard are also identified by a URL with this base:

https://www.opengis.net/spec/security/1.0/req/rc

Requirement Class URL identifiers are used in the <ows:Meaning> element which is a child element of <ows:Constraint>. The purpose of this element is to provide a resource identifier for the Requirement Class.

All Requirements Class Tests in this standard are identified by a URI with this base:

https://www.opengis.net/spec/security/1.0/req/rct

A URL with this base identifies requirements for the service implementation:

https://www.opengis.net/spec/security/1.0/req/sr

A URL with this base identifies requirements for the client implementation:

https://www.opengis.net/spec/security/1.0/req/cr

A URL with this base identifies requirements for the OGC implementation:

https://www.opengis.net/spec/security/1.0/req/mr

All requirements are sequentially numbered as defined in Directive #43 [19.].

The following URI resolves to the Authentication Codelist as specified by this standard:

https://www.opengis.net/def/security/1.0/codelist/authentication

The following URI defines the namespace for the SecurityExtendedCapabilities element defined as WMS 1.1.1 DTD and WMS 1.3.0 schema element:

http://www.opengis.net/security/1.0

The version of this standard can be maintained independent from the version of the Authentication Codelist, a Conformance or Requirements Class. Including the version in the standard URI as well as in the URNs ensures this.

This standard leverages the existing OWS Constraint element to enable the annotation of service capabilities with IA controls present on operation(s) of the service instance. This solution ensures backwards compatibility, as a Capabilities document that includes security annotations is valid against the existing OWS Common schema. For WMS 1.1.1 and WMS 1.3.0, which do not make use of OWS Common, a similar approach is standardized ensuring backwards compatibility.

All approaches ensure that a service endpoint can, independent from anything else, provide service Capabilities with security annotations. Client applications not capable of interpreting the annotations will simply ignore them but will not return expected results. Clients however, that properly interpret the security annotation can use that information to ensure interoperable functioning with secured OGC Web Services.

This is the current standardized use of OGC Web Services – no security. Therefore, there are no implications for this standard.

Services can be discovered through a catalogue that has no security.

The client application can bind to the service instance via the Capabilities document. This reflects common practice for today’s SDIs.

This is another common use of OGC Web Services – no client authentication or authorization is used – only server authentication and a protected communication channel. The server authentication assures the client has the authentic source of the public data. The secure communication channel ensures privacy to the client. Outsiders cannot determine what data the client is receiving.

As server authentication methods are not currently specified in OGC Web Services, there are implications for this standard. In the most common case (HTTPS) server authentication and protected communications is not strictly compliant with existing OGC Web Services standards. This standard corrects that oversight.

The client application can bind to the service instance via the Capabilities document. This reflects common practice for today’s SDIs. The client needs to support the server authentication method while accessing the public data on the server, e.g. support for HTTPS.

For this use case, a public catalogue holds data and service metadata for a protected service. The public access to the catalogue implies that authentication is not required. It is therefore not possible to provide user specific responses. The user can discover service metadata that point to the public version of the annotated Capabilities.

Open data implies that the need-to-know principle does not apply. Therefore, the annotated Capabilities, accessible from a free and open URL, must contain all information relevant for the client application to bind to the service. In particular, this requires that the “content” section of the annotated capabilities list all accessible resources.

Any service that fits the description of use case II should include a “content” section in the annotated Capabilities that lists all accessible resources.

A client application that has implemented all the published security requirements is able to bind to the service and work with the Capabilities document in the usual fashion – likewise to use case 0.

The main difference with use case I is that both user and server are authenticated. Data is open but anonymous access is not allowed.

This use case is similar to use case II with the exception that the service provides access to private data. This must trigger the need-to-know constraint, which implies that the “content” section of the annotated Capabilities is empty or other indications exist from which the client application can conclude that the service is providing private resources. One example is the Defence Geospatial Information Working Group (DGIWG) profile for the WFS Web Service that uses the <AccessContraints> element of the Capabilities to indicate the highest level of classification.

In this case, the client application can only expect that the annotated Capabilities contain the <OperationsMetadata> element. Therefore, the client application is first required to determine its ability to comply with the security requirements outlined in the annotations. In cases where the application is interoperable with the security on the protected service instance, the client must execute the advertised GetCapabilities operation and comply with the security constraints to fetch the full Capabilities that include the “Content” section.

If the annotated Capabilities document does not contain a “content” section (<Layer> element for WMS or a <FeatureTypeList> element for a WFS or a <Contents> element for WMTS, WCS or WPS) or the <AccessContraints> element does not contain the literal “None”, the application shall ^[3] execute the GetCapabilities operation advertised (within the Capabilities document) to fetch the full service capabilities.

This use case assumes that managed access to the catalogue is in place. It also assumes that the user has sufficient credentials to access the catalogue. The catalogue would return sufficient information to enable the client to determine the protected access point and the required security credentials needed to obtain the service capabilities document.

This use case does not build upon the existence of a catalogue service. It is assumed that a client loads the Capabilities instance document stored on a file system to configure access to a protected OGC Web Service. This approach is not recommended as outlined in section “Security Considerations” (see 10), because the integrity of such a document is not guaranteed. As a result, the Capabilities instance document might violate the need-to-know principle, as an arbitrary “Content” section could be included.

From a client application’s point of view, the entire content might have been tampered with. Therefore, it can only be safe to ignore these capabilities. The application should not even request a fresh copy of the Capabilities document from the endpoint contained in the Capabilities document as that endpoint could have also been changed to point to some malicious server.

This use case does assume that a public Capabilities instance document exists that can be loaded by the application. In this case, the client application should fetch a trusted fresh copy from the endpoint of the protected service as outlined in the use the public version of the capabilities document.

Installing the <ows_security:ExtendedSecurityCapabilities> as a valid element into the Capabilities document, it must become a child to the element VendorSpecificCapabilities.

Informative Example: Assuming the following <VendorSpecificCapabilities> exists as illustrated in Table 6.

Then, the security annotated version of the Capabilities should use the following DTD

This standard uses URNs in the name attribute of the <ows:Constraint> element to identify the security control. The use of a URN here is sufficient, because they are used for comparison only.

The URIs are to be registered with the OGC Naming Authority. The OWS Common – Security Standards Working Group (SWG) triggers this action following an approved submission.

Different versions of OWS Common as well as various OGC Web Services standards define slightly different exception handling. The following figure illustrates the exception handling via ExceptionReport as defined in OWS Common 2.0 – OGC #06-121r9, section 8.6, table 28.

OWS Common 2.0 differentiates between an exception that arises inside or outside the service implementation. In the case where the root cause of the error is inside an OGC service implementation, then the HTTP status code and ExceptionReport according to Figure 4 above shall be used. In the case where the root cause of the error is outside the OGC service implementation, then the HTTP status codes – with no ExceptionReport – is to be used. Unfortunately, OWS Common 1.1 – which is the mostly used version – does not differentiate the origin of the root cause. It is also unclear, which HTTP status code is to be used when delivering the ExceptionReport.

In addition, WMS introduces the EXCEPTION/EXCEPTIONS parameter that allows the client to control what the mime type of the exception returned is going to be. This allows including the ExceptionReport into an image.

Regardless of these variations to exception handling, this standard defines a clear separation between the actual OGC Web Services for which exception handling is defined, and the extra exception handling introduced by applying security to a service instance.

OGC web services do not exist in a vacuum. They are built on a set of services and standards, which define the underlying, distributed computing environment as illustrated in Figure 5 below.

Not only do OGC Web Service need to correctly produce and handle exceptions defined in the OGC Standards but they also must correctly produce and handle exceptions in accordance with the standards for each service and protocol layer that the OGC Service is built upon. Therefore, an OGC Web Service which is compliant with this standard must comply with not just the exception handling requirements as defined in this standard, but also with the exception handling requirements of all of the supporting capabilities (protocols and services) which are advertised through the Capabilities document.

Note: For additional information see the OGC CR #388 (http://ogc.standardstracker.org/show_request.cgi?id=388)

Note: The URL provided might be protected and returns a user specific instance of the general access control policy.

The implementation leveraging the URL to fetch the access policy must observe the Content-Type of the response to identify whether the policy is XACML or GeoXACML and which version.

_Note: It is not required that the access control layer at the service actually operates on a XACML or GeoXACML policy. However, to ensure interoperability and the ability of the client to determine the access denied case before executing a service, a standards compliant description is required. A proprietary language must not be used. An example where the client could leverage the obtained policy is before uploading tons of features to a WFS-T. In cases where the client has determined “deny” this would simply conserve bandwidth.

Note: A referenced description may leverage OpenAPI extensions.

The use of OpenAPI for describing an API can also be used to describe the communication protocols used by an interface of an OGC Web Service. We recognize that this description is not a replacement for the Capabilities document.

However, the main driver for using the OpenAPI format is to provide security constraints for the service instance using a format that is well known in mainstream IT. Particularly important is the ability to provide information about existing security controls. The example below illustrates how to provide additional (meta) information for an OAuth2 protected service instance ^[4].

This example from the OpenAPI v3.0 specification ^[5] indicates that the service endpoint requires OAuth2 Access Token released for particular scopes.

The following informative example illustrates the security annotation to indicate that the authentication method client side TLS certificate is in place.

In addition to annotating the authentication method as defined in above, additional information can be provided. For example, the service provider might want to let the client know to which SAML2 federation the service belong. This could be achieved by using the identifier urn:ogc:specification:security:1.0:rc:authentication:saml2

Similar to SAML2, the client does need additional information to start the authentication handshake. For OpenID Connect, this is the metadata of the accepted Authorization Server linked with the secured service endpoint (OpenID Connect Discovery).

For an Authorization Server that is a compliant OpenID Connect implementation, a .well-known description exists as defined by IANA (URL ends with “.well-known/openid-configuration”).

A client can implement support for one or more Requirements Classes as defined by this standard:

Each of these Requirements Classes define the parsing of security annotations by obeying the different structures of the Capabilities document.

A service is already compliant to this standard and has implemented the mandatory Requirements Class HTTPS when all operation endpoints of the service exposed in the Capabilities document are using the URL scheme https. This undoubtedly means that the service is hosted on HTTPS.

According to Requirements Class https://www.opengis.net/spec/security/1.0/req/rc/http-exception-handling

a service instance may advertise its support for HTTP compliant exception handling. According to Requirement <fix me> the default exception handling for a service instance compliant to this standard has to use HTTP status codes. But a client can request a service to react with OWS Common based exception handling by submitting a query parameter as specified by the OWS Common standard applicable to the service instance.

A normative version of the Authentication Codelist is hosted and maintained by the OGC.

For ensuring interoperability with authentication methods implemented on a service instance, this standard defines URNs in an Authentication Codelist. The Authentication Codelist uses the ISO GMX namespace to enable interoperable use within the security annotations of the service capabilities as well as service ISO metadata.

Note: How to use the authentication codes to annotate ISO metadata is out of scope for this standard.

The definition of the authentication code can be resolved from the Authentication Codelist URI via the pattern defined in Requirement 68. The main purpose of the Authentication Codelist Registry is to enable the lookup of authentication code definitions via URL resolving.

As defined in section 7 of this standard, the <ows:Constraint> element uses the <gml:identifier> of the authentication code (urn:ogc:def:security:authentication:ietf:6750:Bearer in the example) to identify the authentication code. For a WMS 1.1.1, WMS 1.3.0 as well as OWS Common v1.1 or v2.0 based Capabilities structure, the <ows:Meaning> allows to fetch the <gml:description> element of the <codeEntry> by specifying the gml:id attribute of the <gmx:CodeDefinition> element.

The recommended URL for resolving an authentication code is to extend the base URI with https://www.opengis.net/def/security/1.0/codelist/authentication/\{gml:id}. For example: https://www.opengis.net/def/security/1.0/codelist/authentication/OAUTH2_BEARER_TOKEN

The mechanism of including security metadata into the Capabilities works well if the client could trust the Capabilities. For the purpose of the security considerations, it is best to differentiate if the Capabilities are used as an XML instance document or as the direct response from the service to the GetCapabilities request.

Would this threat lead to vulnerability? Yes, this threat could cause a client to wrongly submit user credentials to a malicious site!

Assuming that the attacker would be able to modify the URL of the service endpoint and assert that the authentication method were HTTP BASIC Authentication (as an example). This would cause the client to submit user credentials with the service request. This vulnerability must be considered high risk, as the client has no means to identify the attack.

For the future, it seem to be reasonable to request that a digital signature can be applied to OGC encoding documents; e.g. inside a Capabilities instance document to enable enveloped signatures compliant with the main-stream IT approach (either have the Signature element first or last child of document root). But to secure any OGC instance document, like a FeatureCollection, an OWS Context instance document, etc. it would be necessary to provide an optional element to relevant OGC encoding schemas.

This standard defines three Conformance Classes, illustrated in the figure below.

This Level of Conformance Test is responsible for collecting all exposed Requirements Classes annotated via <ows:Constraint> element(s).

There is only one mandatory Requirements Class to be implemented: HTTPS.

All other Requirements Classes are optional. The existence of a Requirements Class assures that the service has implemented the associated requirements. A Requirements Class can identify the implementation of an IA, support for a security feature or the exposure of additional metadata.

In order to be compliant with this standard, the implementation of one or many optional Requirements Class must be inserted into the Capabilities using the mechanism defined by this standard: Use of the <ows:Constraint> element. This standard also refers to such an element as security annotation.

To assure a particular structure of the <ows:Constraint> element, each Requirements Class imports the requirements defined in the Requirements Class “Identifiers”.

Requirements Classes https://www.opengis.net/spec/security/1.0/req/rc/authentication and

https://www.opengis.net/spec/security/1.0/req/rc/cors have dependencies to other Requirements Classes that must be reflected in the tests.

The Requirements Class https://www.opengis.net/spec/security/1.0/req/rc/authentication depends on the Requirements Class https://www.opengis.net/spec/security/1.0/req/rc/http-exception-handling. This ensures that a service endpoint that has implemented HTTP protocol based Authentication (i.e. HTTP Basic) can return a HTTP status code 401 instead of the OWS Common Exception Report in XML as mandated by the OWS Common specification.

The Requirements Class https://www.opengis.net/spec/security/1.0/req/rc/cors depends on the https://www.opengis.net/spec/security/1.0/req/rc/http-methods Requirements Class. This is necessary to ensure that the service endpoint supports required HTTP methods like OPTIONS and HEAD.

The following activity diagram illustrates the sequence of tests that SHALL be applied to determine compliance with a particular set of Requirements Classes. The activity diagram takes under consideration the dependency of Requirements Classes.

Note: The Conformance Test for the mandatory Requirements Class HTTPS is already defined in A.2.

The only mandatory Requirements Class defined by this standard is urn:ogc:specification:security:1.0:rc:https

This test SHALL be applied to determine that the client is capable to accept a service connection via HTTPS.

The Requirement https://www.opengis.net/spec/security/1.0/req/rc/clientParsing defines a mandatory client behavior that is important to be tested.

When a client receives the Capabilities that does not contain the “content” section, the client must send a GetCapabilities request to the endpoint advertised in the Capabilities.

The pass or failure of this test can be verified by a human when executing the client on the test harness that produces Capabilities with no <Content> section. The verification is possible via listing the resources that are included in the <Content> element. If the client does not display any Layers, Feature types, etc. to select from, this test fails.