OGC Testbed-13: Security ER

The requirements addressed by this ER are the implementation of access right delegation (OAuth2) plugin for QGIS as an extension to version 2.18.4. These are able to use OAuth2 protected services WMS and WMTS provided by Dutch Cadaster.

The requirement for workflow security is also to document the following use cases, as implemented by 52°North:

The security state before the Testbed 13 was that the QGIS Open Source desktop GIS was capable to connect to OAuth2 protected OGC Web Services, but a manual registration with Authorization Servers was required.

QGIS was not able to connect to OGC Web Services (OWS) protected with version 2 of the Security Assertion Markup Language (SAML). It was also not possible to construct workflows of protected OGC Web Services.

After Testbed 13, the Open Source desktop GIS QGIS can be used to connect to protected services leveraging OAuth2 and the plugin registration is simplified by the use of digitally signed software statements and Dynamic Client Registration. Now, it is also possible to connect to SAML2 protected OGC Web Services that support the SAML2 Enhanced Client Proxy Protocol (ECP). In workflows, different security recommendations (in addition to those exposed in Testbed 12) will enable the construction and execution of workflows comprised of secured OGC services.

This ER has security applicability (implications) to different OGC working groups, as security is a crosscutting theme across the entire OGC domain.

For the OGC Security Domain Working Group (DWG), this ER provides results towards the use of "modern" security solutions like OAuth2 and SAML2 which expands the generally simple authentication, such as HTTP BASIC authentication. It should thereby stimulate the use of modern security in infrastructures to make protected data sets available via OGC Web Services. Beside the technical merit, this should provide new security based business opportunities.

For the OWS Common Security Standards Working Group (SWG), the implementation of the security extension to QGIS will enable testing the described approach of annotated capabilities regarding aspects like 'fit for purpose'. The feedback will be valuable to the SWG in the process of standardizing the interoperability aspects.

The aspects of workflow security may introduce novel approaches to develop and execute workflows of secured services. It should stimulate discussions in the Workflow DWG and the Security DWG regarding the 'fit for purpose' and interoperability aspects.

All questions regarding this document should be directed to the editor or the contributors:

It is expected that this ER stimulates future work regarding the OGC to standardize requirements for client applications to work on modern security aspects and the work being standardized by the OWS Common SWG. More details can be found in section "Conclusions and Future Work".

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.[RFC 6749]

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.[RFC 6749]

Access tokens are credentials used to access protected resources.[RFC 6749]

A Free and Open Source Geographic Information System[http://qgis.org]

The Security Assertion Markup Language (SAML) is a standard of the Organization for the Advancement of Structured Information Standards (OASIS), an alliance partner of the OGC. SAML is concerned with authentication and assertion exchange in trusted distributed systems to support Single-Sign-On and Federated Identity Management.

Many years ago, the OGC Shibboleth Interoperability Experiment conducted a study and prototype implementation of SAML with OGC Web Services. For more information on SAML and how to apply it to OGC Web services, please follow the link to the Public Engineering Report provided in the Bibliography chapter.

First, one should stress what OAuth2 is not about: It is not about authentication and it is also not about authorization.

Instead, the OAuth2 specification describes a framework that enables users to delegate a (controlled) set of rights to an application so that it can access the users' resources. The cool thing about the delegation is that the users must not share their original login credentials with an application. Instead, the users approve the release of a - so called - access token to the application that "carries" the approved set of rights. The application can then present the access token with the actual request to access the user’s resources. The user is the actor in OAuth2 called Resource Owner.

The most dominant use cases concentrate around social platforms like Facebook, Twitter, etc. where the users grant a particular application access to user profile, emails, blogs, etc. It is not relevant who created the application, but it is important that the user trusts the application. As the user cannot establish bi-lateral trust, the OAuth2 specification introduces a 3rd party called Authorization Server.

The Authorization Server is the actor that allows application developers to register and manage their applications. Once registered, the Authorization Server is capable of releasing access tokens to the application once granted by the user. But before the user can approve the release of an access token (which keeps a certain set of rights), the user must authenticate with the Authorization Server. How this authentication takes place is outside the OAuth2 specification. But it is mandatory that the authentication provides the Authorization Server with sufficient information about the user.

The third actor in the OAuth2 framework is the Resource Server. This actor is responsible for authorizing requests from applications to user resources. Basically, the Resource Server must first check if the access token is valid; and if it is, check whether the requested action on the resource was previously approved by the user. OAuth2 manages the associations between different rights and access tokens via scopes. If the request to the resource is involving a scope that is carried by the attached access token, then the resource is returned. In case that the application does ask for an action on the resource which is not covered by the scopes associated with the access token, then the Resource Server returns an error.

From a business perspective, OAuth2 enables a market place where developers can build and register applications that can be run by users to do "cool" things with their resources like pictures, emails, messages etc. Business takes place if a user decides to run an application and either pays money for the use or the application displays advertisements. Either way, it is attractive for developers to register applications with an Authorization Server to make business. The OAuth2 trust model is exactly built for that: Individual developers register applications that can be trusted and run by users to do cool things with their data.

This ER would not be about security if it did not mention the dark side of the things: If the user trusts a malicious application, all kinds of attacks can be thought of that span from remote control to the user’s data to forged (money) transactions in particular in scenarios with one-click-payments enabled.

The OpenID Connect specification is an extension to the OAuth2 framework that enables an Authorization Server to also release user information to the application. For the sake of differentiation, an OpenID Connect compliant Authorization Server is called an OpenID Connect Provider or OIDC Provider (OP). The compliance requires that three requirements are implemented: (i) The OP releases the so-called ID Token, which is a JSON Web Token that contains information about the user that delegates access rights to the application; (ii) the ID Token follows the structure defined in the specification; and (iii) the OP operates the UserInfo endpoint. Without going into details, OIDC also introduces additional flows for how the OP can release tokens to the applications. The default is that the OP releases the ID token with the access token or authentication code. This enables the application to establish a user session from the start of the flow, which can be quite handy as we will see with the example Email Alert Service.

Even though OIDC introduces authentication to the OAuth2 flow, one must keep in mind that it is just an extension and therefore is restricted to the OAuth2 framework and the specified flow. However, the introduction of the hybrid flows provides more flexibility and control to the application when requesting tokens.

An OP can basically release three different types of tokens:

OAuth2 as standardized by RFC 6749 is a (access rights) delegation framework that enables a resource owner to grant (restricted) access rights to the own resources for trusted applications without providing the original access credentials, e.g. username and password to the application. As outlined in the overview section, the user’s trust in the application is essential. As OAuth2 is originally designed for online applications (either running inside the user-agent - aka the web browser - or hosted on a web server), the question arrives whether the OAuth2 framework can be applied to open source desktop applications.

The essential part is how the application and the Authorization Server establish trust. As defined in RFC 6749, this is different for public and confidential clients. The question now is whether QGIS and the OAuth2 plugin qualifies for either the public client or confidential client type.

But what about QGIS as an open source desktop application? What about the redirect URI for the QGIS OAuth2 plugin? Clearly, QGIS does not have an online redirect URL where the Authorization Server can redirect to in order to deliver the authorization code (Authorization Code Flow) or the access token (Implicit Flow). The only similar option would be that QGIS establishes a localhost port to listen on for the redirect. But, this would turn the client machine in a web server type of machine, as it has open port(s) listening to HTTP traffic.

The other option regarding the redirect URI would be that for the QGIS application, a redirect URI based on a custom scheme gets registered with the Operating System. So for example, QGIS could register the scheme "qgis:" with the operating system and then register the redirect_uri to start with this scheme. So for example 'qgis:callback', where the scheme qgis would trigger to start the QGIS application and call the function 'callback' that would then read the authorization code or the access token from the redirect URL.

Assuming even this approach would work on any operating system, it would reset the QGIS application state as it re-starts the application. This is certainly not ideal if the user has multiple services connected and is enjoying a particular view when trying to add an OAuth2 enabled service. Then losing the entire application state would require to "start from scratch".

An alternative approach would be using a generic online URL that can only be used with the Authorization Code Flow to display the authorization code issued by the Authorization Server. With this approach, the user must copy and paste the authorization code from the Web Browser window into the QGIS plugin. This approach would ensure that the QGIS application state can be maintained as the authentication code could be pasted into the configuration window currently used by the user to setup the service connection. This approach also does not require that the client computer must open a listening port. But on the other hand, this is a manual step for the user, requiring a copy and paste action.

It is very important to note that this approach shall not be used for the Implicit Grant as the Authorization Server would return an access token to the generic URL. Also, the Implicit Grant is not fit for purpose, as the Authorization Server does not release a refresh token with the Implicit Grant. Therefore, the plugin would need to initiate a Web Browser interaction each time the access token expires. This is - despite the fact that the access token is exposed in the clear - not user friendly.

Regardless which grant type the OAuth2 plugin is going to be using, the plugin must be registered with the Authorization Server in charge for the Resource Server, before it can obtain token(s). In principle, there are two different options: (i) manual registration and (ii) API based registration.

The normal process is to register the application manually with the Authorization Server. This is typically done by the developer of the application and requires an out-of-band communication with the administrator of the Authorization Server or an admin login. For Web Applications, the developer typically has a login into the Authorization Server that allows the registration of the application. Once the application is online, any user can interact.

But this procedure is not fit for purpose for QGIS as the OAuth2 plugin as each user would have to register the plugin with all the Authorization Servers out there (and that seems to be impractical). Therefore, each user would have to register their own copy of the QGIS AOuth2 plugin with each Authorization Server that is in charge of the protected services hosted at a Resource Server. Given the number of QGIS users and installations, that seem to be an overwhelming number of client registrations for each Authorization Server.

When configuring an OGC Web Service connector to use OAuth2 based authorization, then the OAuth2 plugin should be able to register itself with the involved Authorization Server. At this point, the plugin no longer exists as Open Source but as compiled and executable code. This has an implication to the design of the OAuth2 plugin: It must be able to add this plugin as a compiled module to QGIS, like Apache Web Server modules. Using this approach, the plugin can be compiled independent from the QGIS main application. This is important as the trust with the Authorization Server can be established with the compiling entity of the plugin.

With this trust in place, the QGIS Oauth2 plugin can be registered via an API based registration mechanism, based on digitally signed client metadata - the QGIS OAuth2 plugin software statement. Each entity that compiles the OAuth2 plugin can include into the binary a software statement, that is digitally signed with the entity’s private key. And the associated public key can be made available on the entity’s web server. It is also possible that the entity is using a X.509 code signing certificate that can be used by any Authorization Server to validate the software statement used for automatic registration.

An alternative to the described registration process based on a software statement compiled into the plugin is to import a provided software statement. If the plugin supports the import functionality, a trusted software statement would not have to be compiled into the plugin, but the user could load the trusted software statement instead. Because the software statement is digitally signed, this process is equivalent to using a built-in software statement.

The ability of an OAuth2 Authorization Server or OIDC Provider to support dynamic client registration via an API is defined in RFC 7591. Basically, three options exist to use the API:

For Testbed 13, it was recommended implementing the AS/OP supports dynamic client registration via an open API (rate limit enforced) based on a digitally signed software statement. The AS/OP MUST only accept registration requests based on a valid digital signature on the software statement.

The feature "Dynamic Client Registration" can be implemented by any OAuth2 Authorization Server (and therefore any OIDC Provider) by implementing the RFC 7591.

The actual request for client registration is labeled "C" and includes the client metadata. Two pieces of optional information can be used by the client to commence the registration step: (i) an initial Access Token (obtained from the Authorization Server) and (ii) a Software Statement (the client metadata). If the use of an initial access token is required or whether its possible to use a software statement depends on the actual implementation of the API for dynamic client registration, provided by a particular Authorization Server.

As discussed earlier, open source software prevents that the developer can implement any trust in the OAuth2 plugin itself. For TB13, assume that the Authorization Server accepts a client registration based on a digitally signed software statement. The Authorization Server is able to verify the digital signature on the software statement before accepting the registration request. Following good practice, it is recommended that the public key is bundled to a code signing certificate that enables the Authorization Server to verify the digital signature on the software statement and identify the signing entity. Based on a white listing, the Authorization Server can accept a registration for any trusted entities.

For Testbed 13, the Authorization Server must accept the OAuth2 plugin registration based on a software statement, signed by Secure Dimensions GmbH. Two options exist how to make the software statement available: The first option is to provide it for download from the entity’s web site and the second is to bundle the software statement with the binary build.

For Testbed 13, the QGIS OAuth2 Plugin can leverage the OAuth2 Authorization Code Grant and the Resource Owner Password Credentials Grant. In order to honor each grant type, different software statements are provided.

For the Authorization Code Grant, it is required that the authorization code is returned to the application via a redirect URI. As explained before, this is typically achieved by leveraging an open port on localhost. However, some computing environments may not allow this.

The Authorization Code flow can be split into two sequences to prevent the use of the open port and redirect to localhost. In this case, the Authorization Server does return the authorization code in the user-agent and the user must copy and paste the code into the QGIS plugin. In order to achieve that, the Authorization Server must provide a dedicated URL for just displaying the authorization code. For Testbed 13, the Secure Dimensions Authorization Server provides the following redirect URI for this purpose: https://as.tb13.secure-dimensions.de/oauth/display_code.php

Google’s Authorization Server provides two specific redirect URIs that define a particular way of how the authorization code shall be returned to the user-agent and how the user-agent shall display the code (https://developers.google.com/api-client-library/python/auth/installed-app):

Since QGIS version 2.14, an authentication framework provides an API to configure authentication options for OGC Web Services connectors. This framework already provides authentication methods like BASIC and DIGEST as well as X.509 client certificate authentication.

For the purpose of implementing plugins for additional authentication methods, it is important to understand the class structure. The following figure illustrates in a simplified way the relevant classes and their relationships.

The following figure (Figure 11) illustrates, in a simplified way, the interactions of the authentication framework within the OGC Web Service adapters implemented in the QGIS core.

The trust in SAML is established between entities using SAML metadata. It is therefore not required that the actual application - the QGIS plugin - is trusted. The plugin must implement the SAML2 handshake to broker communication between the trusted entities (i) Service Provider and (ii) Identity Provider.

The actual implementation of the plugin to support SAML2 based authentication is quite straight forward. The plugin must implement the SAML2 Profile "Enhanced Client Proxy" as described in the OASIS standard "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0".

In addition to supporting the ECP protocol, the plugin must also ensure that any subsequent request of QGIS providers (WMS, WFS, etc.) send the session cookie that was created as a result of a successful ECP interaction. This can be implemented by providing hooks into the OGC Web Service Providers as supported by the QGIS Authentication Framework implemented since v 2.14.

The following sequence diagram illustrates the basic interactions between the QGIS application (OWS Provider), the Authentication Plugin and the protected OWS service.

Acting as an OAuth client, the WPS needs access to resources that are provided by OGC W*S services like the WCS. The interaction between the components is shown in the figure below.

Both, the WPS and the WCS need to be registered at the authorization server beforehand. The mapping to access constraints is defined by so called scopes in OAuth. These are previously defined by the user when registering the WCS as resource server at the authorization server. In the Testbed 13 workflow scenario, where the OAuth WPS is utilized, Auth0 (https://auth0.com/) is used as authorization server. Auth0 also provides a powerful Web-based user interface for registering components as clients or resource servers, for defining scopes and also for granting authorization before running WPS processes in the Client Credentials Flow.

To trigger the execution of a WPS process, the WPS client sends an Execute request to the WPS containing inputs that reference coverage data provided by a WCS. The WCS acts as resource server, the owner of the referenced datasets is the user that executes the WPS process. Once the WPS retrieves the Capabilities from the WCS, it encounters that the GetCoverage operation is secured by OAuth. Therefore, a link to the scope listing and the URL of the authorization server are given in the Capabilities as constraints in the operations metadata following the proposal of the currently developed OWS Common Security Extension. With this information, the WPS is able to compose an authorization request, i.e. a URL that is redirected to the user agent (usually a Web browser) containing the client ID and scopes for the requested resource. If the user invokes the request, the authorization server generates a form for providing the user credentials and authorizing the requesting WPS to access the resources. Once the user has authenticated and confirmed authorization the authorization code is redirected back to the WPS and the WPS is then able to retrieve an access token from the authorization server that allows to retrieve the coverage dataset. Since the WCS is acting as a resource server, it needs to verify the access token and check the scopes before returning the protected resources.

If the WPS is an OAuth Resource Server, it is offering its service operations and processes as resources that are owned by users who may provide access for clients or not.

In this case, the WPS needs to check, whether an access token arrives with an Execute request (provided in the HTTP header). Afterwards it will verify the access token and check whether the scopes allows it to execute a process.

The OAuth enabled WPS is implemented as an extension to the 52°North Web Processing Service (52N WPS) implementation. The 52N WPS is implemented in Java and supports both, the WPS 1.0 and 2.0 standard. For implementing the 52N WPS as OAuth resource server, a Security Proxy is implemented that implements the token verification as well as the check of the scopes. In addition, it injects the OAuth-related information needed by clients in the constraints element in the operations metadata. Since Auth0 is used as authorization server and Auth0 is returning JSON Web Tokens (JWT), the tokens can be verified on the client side and scopes are also provided with the tokens. The Java libraries provided by Auth0 are used to implement the token verification and extraction of scopes. The scope check is then implemented in the Policy Enforcement Point (PEP) and can be configured by a configuration file. The Security Proxy is also used for implementing the X.509 certificate authentication and authorization based on access control list in the workflow security use cases. Hence, the proxy is described in more detail in the implementation details of the workflow security (next chapter).

The implementation of the 52N WPS as OAuth client was done by an AbstractOAuthClientAlgorithm that provides an additional endpoint that is used as redirect-URL for receiving authorization grants and access tokens from the authorization server and in turn passing the access token when resolving input references pointing to OAuth Resource servers.

The workflow package in Testbed 13 developed a consistent, flexible, adaptable workflow that will run behind the scenes, is described in the Business Process Model and Notation (BPMN) standard, and can be shared with and executed by other users. In a nutshell, the workflow aims to automate conflation of road datasets and pre-processing steps (coordinate transformation, data quality checks). The processing steps are implemented as WPS processes and the data is passed by reference to data servers (WFS and WCS) between the different processing steps. A detailed description of the workflow scenario and the corresponding implementing components is given in the Testbed 13 - Workflow Engineering Report (OGC 17-029).

When executing geoprocessing workflows consisting of WPS processes and intermediate transactional W*S data services, it must be ensured that differing access rights and security levels can be dealt with. More specific, three major use cases are considered that need to be addressed in the TB13 workflow scenario.

Dominating Privileges: This use case describes the situation when a user has more privileges than the computer system being used. Access control based solely on the computer’s system privileges will result in a security violation.

Tunneling Proxies: If a service runs behind a proxy/firewall, certain security attributes that were sent by the client might not reach the service. As an example, a mutual TLS Authentication between client and service will not work, since the proxy is creating a new connection between the service and the proxy and the client certificate will hence not reach the service.

Identity mediation: Many different forms of Identification and Authorization (I&A) are available. This is of importance for service-based workflows where the I&As used may differ between the workflow services. In this case, a mediation between identity and the different models used for access control needs to be implemented.

The solutions developed to address these use cases are described in the following subsection.

The problem of dominating privileges occurs in the workflow scenario, if the WPS needs to access a protected resource provided by a data server, e.g. a road dataset provided in a WFS. Though the WPS may be authenticated by the data server and may have general access, operations for retrieving resources of a user may still be protected and may require authorization by the owning user. OAuth addresses this issue, since it is made for delegating authorization from the user to applications to access the user’s resources.

In the Testbed 13 workflow, a WPS needs to retrieve a road dataset from a WFS. The road dataset is passed as reference to the WPS. The WPS hence at first queries the WFS providing the dataset. The WPS is authenticated by a X.509 certificate that allows the WPS to retrieve the Capabilities document (managed by an Access Control List), but not to retrieve the actual feature data, which is owned by the user running the whole workflow. In this case, authorization needs to be granted form the user owning resources in the WFS to the WPS. This can either be done beforehand using the Client Credentials flow of OAuth (as shown in the diagram above), where the user has authorized the WPS beforehand to access the roads in the WFS and the WPS can directly use its client credentials to retrieve access tokens. Another option is to utilize the Authorization Code Flow to request the authorization using the authorization server and the user agent. This is described in detail in the section on the OAuth-enabled Web Processing Service above.

To address the issue that a service behind a proxy will not retrieve all client security information, consider the case when the client is authenticated by an X.509 certificate that would be not transferred through the proxy on the protocol level. Instead, the certificate needs to be provided on the application level as illustrated in the diagram below.

The client holds an X.509 user client certificate and sends Execute Request to the WPS. The Execute requests reaches the Proxy at first. The Proxy requires the client to provide its certificate. The Proxy holds two certificates, a X.509 server certificate and a X.509 client certificate that is used to communicate with services behind proxy. After the secured session between client and proxy is established, the client can send an Execute request again. The execute request is now forwarded to the WPS. Again, the WPS asks for a client certificate. On the protocol level, the secured session between Proxy and WPS is established with the Proxy Client Certificate and WPS Service Certificate. But for authenticating the actual client and providing access checking the ACL, the WPS needs the user client certificate.

The solution to the problem is to transfer the client certificate on the application level. A standard that can be utilized is the Web Services Security X.509 Certificate Token Profile that describes how to embed X.509 certificates in SOAPMessageHeaders. Hence, if the proxy client certificate is not allowed to run the actual process execution, the WPS can check, whether a certificate is contained in the SOAPMessageHeader and can then check, whether this client has permission to run the execution. In this case, the execution can be done and the process outputs are then returned.

In this workflow, we consider the requirement that there needs to be a mediation between X.509 certificate authentication with ACL and a road dataset that is available in a WFS running in the amazon cloud. The solution to the problem is to deploy a PEP that translates the identities and maps the attributes to roles for access control as shown in the diagram below.

The user connects to the workflow client and starts the workflow. The client triggers the workflow engine. At some point during the workflow execution, the data quality of road features is checked. A service offering the road data (WFS) is protected by AWS security. The data quality WPS holds a X.509 certificate. A PEP is used as proxy in front of the WFS. A GetFeature request is sent directly to the PEP, along with the certificate. The PEP mediates between the certificate and AWS security. Attribute based access control is mapped to role based access control. The PEP then requests AWS Authorization server for a token. Once it has received the access token, the PEP forwards GetFeature request together with the access token to the WFS and the road dataset is returned. The PEP forwards the features to the WPS. The WPS can then run the data quality check.

For implementing the OAuth Resource Servers and W*S that use X.509 certificates for authentication and access control lists for authorization, 52°North implements a security proxy. The security proxy is implemented as a Java Web Service that can be deployed with OGC Web Services (52°North is providing WPS and WFS for the Testbed 13 workflow subthread).

An overview on the security proxy implementation is given in the figure above. The 52N security proxy acts as a proxy that receives requests for OGC web services, executes security checks, and, if permission is granted, forwards the requests to the OGC web services and forwards the responses back to the clients. As illustrated in the subsections above, OAuth resource servers as well as servers supporting X.509 certificate authentication and access control lists are needed to address the issues in the workflow security use cases. Thus, the security proxy implements two handlers, the OAuth handler and the Certificate/ACL handler.

The OAuth handler has two major tasks:

Since auth0^[2] is used as authorization server and JSON Web Tokens (JWT) are provided as access tokens, the verification is implemented in the proxy using a token verification Java library provided by auth0. This library is also used to extract the scopes and implement the scope checks. The scope itself can be configured in a configuration file.

The Certificate/ACL handler handles requests that include a X.509 certificate for authentication. For authorization, it implements an access control list that defines the rights of the user to access operations and/or resources in the secured service. For the implementation of the X.509 certificate authentication, we are using the Spring Security framework. The access control list can be defined in a configuration file that is read when starting the proxy.

Example of a SimplePermissions policy:

In both cases, the Capabilities injector is used to add the security constraints for the service in the constraints element of the OperationsMetadata section in the Capabilities (see OGC OGC 16-048r1).

Excerpt from a WFS capabilities document describing the access constraints:

Scopes were defined on two levels: (1) operation and (2) feature type/process level. On the operation level, scopes were defined as Execute, DescribeProcess or GetFeature. If a client is authorized for the respective scope, it can call the operation with no limitation, e.g. call Execute on all processes or get all feature types. To allow more fine-grained access control, we defined scopes on feature type/process level. The scheme for these scopes is: Operation/AttributeName=AttributeValue, e.g. Execute/ProcessID=my.process or DescribeFeatureType/TypeName=my.feature.

The first level of scopes works well, as the available operations of a OGC Web services instance rarely change. The second level of scopes works well for a fixed set of feature types/processes. However, adding new feature types or processes (resulting in new scopes) is quite common and this can cause a problem. The client initially requests authorization for a given set of scopes. If new scopes are added within the authorization server, the client will not be authorized to access resources connected to these scopes. It would need to make a new authorization request for each additional scope.

For results on TIEs in Workflow Security, please see ER OGC #17-029 "OGC Testbed 13 - Workflows ER".

For results of TIEs regarding the Secured Client (AB105), please see ER OGC #17-078 "OGC Testbed 13 - Concepts of Data and Standards for Mass Migration ER".

The following table provides an overview about the different TIEs and the components involved.

The following table lists all the conducted TIEs.

The TIEs for the QGIS OAuth2 plugin are all successful.

The TIE results for Workflow can be found in OGC #17-029 "OGC Testbed 13 - Workflows ER".

This ER shows that OGC Web Services can be protected with main stream IT security mechanisms to be consumed with a QGIS plugin but also participate in a secured workflow. For more conclusions on the workflow part, please take a look at that Engineering Report (OGC #17-029).

The work item GE101 was completed successfully. It did not only conclude in a "straight-forward" implementation but raised ground truth questions (and triggered answers) on the legitimate, appropriate and secure use of OAuth2 with open source desktop applications; aka the QGIS plugin for OAuth2. One of the fundamental recommendations of this ER is that the OAuth2 plugin should be registered with Authorization Servers via digitally signed software statements. One obvious reason is to ease the registration part for the user. The standard compliant software statements would be crafted by an admin of the Resource Server - perhaps in conjunction with the Authorization Server - and then published on the website. The publication of different software statements could reflect different access scopes but also require certain OAuth2 flows that are sanitized.

Regarding the applicability of the different OAuth2 grant types with the QGIS plugin, it seems to be best practice not to use the Implicit grant as the plugin cannot request new access tokens, because the flow does not issue refresh tokens. Also, the use of Authorization Code Grant with manual finish was implemented which can be recommended for computing environments where the plugin cannot create a localhost socket. This might be very relevant for restricted computing environments.

OAuth enabled WPS: Using the OAuth2 Client Credentials Flow worked well with the WPS interface standard. Enabling the WPS to access OAuth2 protected resources worked directly and the standard doesn’t need to be changed. Just some work "under the hood" was needed to resolve OAuth2 protected referenced data, e.g. request tokens from an Authorization Server and adding HTTP headers to data-requests. However, access needed to be granted beforehand. The more dynamic Authorization Code Flow also worked with WPS, but some extensions were needed. The redirect-URL (see Authorization Code Flow vs. Client Credentials Flow for details) needs to be made available to the WPS-client. This could be done by extending the GetStatus document or by returning HTTP status code 302 (Found) and HTTP header Location. Both approaches would require changes to the WPS interface standard and their feasibility needs to be discussed in the SWG. Another future work item would be the definition of OAuth2 scopes and the granularity of access control that they should be used for.

Results from the documented work regarding security in OGC Testbed 13 indicates that OGC and main stream IT security approaches work well together. The topics addressed will further stimulate sustainable discussions and uptake in the Security DWG.

Standardization activities in the OWS Common - Security SWG benefit from the results as it is now clearer which annotations to do for an OAuth2 protected service and in how far that would further improve (ease) the plugin registration activity. Furthermore, the results from Testbed 13 indicate that the OWS Common - Security SWG approach on defining a backwards compatible approach is good practice. However, for future work it is very important that security gets built into the standardization effort as early as possible. The new upcoming standardization work with WFS/FES as API provides opportunities that should be followed.

Based upon the results from Testbed 13 but also current standardization activities in the OGC, this ER defines the following different future work topics.

For the QGIS 2.18.4 OAuth2 Plugin, the following TIEs exist:

The TIE as described in table 1.1 is between the OAuth2 QGIS plugin and a WMS secured via an OAuth2 RS where the associated Authorization Server supports the Authorization Code Grant.

The TIE as described in table 1.2 is between the OAuth2 QGIS plugin and a WCS secured via an OAuth2 RS where the associated Authorization Server supports the Resource Owner Password Credentials.

The TIE as described in table 1.3 is between the OAuth2 QGIS plugin and a WMS secured via an OAuth2 RS where the associated Authorization Server supports the Resource Owner Password Credentials.

The TIE as described in table 1.4 is between the OAuth2 QGIS plugin and a WFS secured via an OAuth2 RS where the associated Authorization Server supports the Authorization Code Grant.

For all tests, a Windows 10, 32bit executable for the QGIS QGIS 2.18.4 and the OAuth2 plugin are used. The built "Munich" is provided by Secure Dimensions specifically for the OGC Testbed 13 but based on the Github master for version 2.18.4. This ensures compatibility with the plugin as that is installed as a DLL. The QGIS splash screen reflects that:

The QGIS Plugin provided under OGC Testbed 13 is compiled as a Windows 32bit executable to work with QGIS 32bit build 2.18.4. However, the compiled DLL (oauth2authmethod.dll) does also work with the QGIS 2.18.13 version.

The actual installation of the plugin is quite simple: You just download the plugin from this URL (https://as.tb13.secure-dimensions.de/oauth2authmethod.dll) and put the DLL into the QGIS "plugins" directory. This is usually located under the diretory for the QGIS installation.

For Testbed 13, Secure Dimensions provides a compiled version of the plugin for easy installation (see previous section). But, it is also possible to compile from the sources. This procedure is more difficult (and only suggested for decent QGIS developers) as you need to build a couple of dependencies. It is not our in tension to provide a step-by-step instructions list, but rather provide an overview so that you can go into the details yourself. For that purpose, we describe the build process based on QGIS version 2.18.4 (which was the latest available at the time of B13 start) and a Windows 10 32bit installation.

First, you need to install Microsoft Visual Studio 2010.

Second, you need to build QGIS 2.18.14. How to do this, please follow the detailed description available from OSGeo: https://github.com/qgis/QGIS/blob/release-2_18/INSTALL

Third, you need to obtain the sources for the QGIS OAuth2 Plugin (master) from Github:

https://github.com/securedimensions/QGIS-OAuth2-Plugin

Then, start cmake and use the plugin installation directory as source. You need to create a build directory and use that with cmake. Then select the compiler based on Visual Studio 2010 (use native compiler). The following figure illustrates the CMake configuration. Please make sure to uncheck the "build test app" option.

As you can see, some dependencies exist to the OSGeo installation of QGIS (C:/OSGeo4W and C:/Program Files/Qgis-2.18.4/include/qgisconfig.h). But there are other dependencies that need to be built individually:

Final note: In order for the installation of the DLL to finish with no errors, it is important that you change the permissions on the target directory to allow any access: C:/Program Files/Qgis-2.18.4/plugins. In case you do not change the permissions, the default permissions require administrator privileges that the CMake program does not have.

The OAuth2 plugin for QGIS 2.18.x for Testbed 13 is based on the code from Boundless Geo (https://github.com/boundlessgeo/qgis-oauth-cxxplugin). During the Testbed 13 project, we have made changes to the sources and extended the functionalities to mainly support OAuth2 Dynamic Client Registration via Software Statements, as described in this ER but also to support manual finish of the Authorization Code Grant. The following is a basic list of changes and improvements:

Once the QGIS Plugin for OAuth2 is installed, you need to register it with the Authorization Server that is in charge of releasing access tokens for the Resource Server that is protecting the OGC Web Services that you like to protect.

This OAuth2 plugin is for general purpose use and not specific to a particular use with OAuth2. In this sense, you need to register the plugin with the Authorization Server specifying certain parameters that must be "negotiated" (can be obtained) from the entity operating the Authorization Server.

The plugin supports different methods for registration: (i) you can register the plugin manually with the Authorization Server and then use the manual configuration window to fill in the blanks; (ii) use a software statement released by the operator of the Resource Server that creates proper software features to access a particular service. It is entirely possible that the operator of the Resource Server will provide different access profiles resulting in different software statement. How to obtain these software statement, valid for you, is outside the scope of this documentation.

For making the entire registration more clear, we are going to do this based on the Authorization and Resource Server deployed by Secure Dimensions for demonstration purposes in the context of Testbed 13.

The QGIS Plugin provided under OGC Testbed 13 is compiled as a Windows 32bit executable to work with QGIS 32bit build 2.18.4. However, the compiled DLL (saml22authmethod.dll) does also work with the QGIS 2.18.13 version.

The actual installation of the plugin is quite simple: You just download the plugin from this URL (https://sp.tb13.secure-dimensions.de/saml2authmethod.dll) and put the DLL into the QGIS "plugins" directory. This is usually located under the diretory for the QGIS installation.

For Testbd 13, Secure Dimensions provides a compiled version of the plugin for easy installation (see previous section). But, it is also possible to compile from the sources. This procedure is more difficult (and only suggested for decent QGIS developers) as you need to build a couple of dependencies. It is not our intention to provide a step-by-step instructions list, but rather provide an overview so that you can go into the details yourself. For that purpose, we describe the build process based on QGIS version 2.18.4 (which was the latest available at the time of B13 start) and a Windows 10 32bit installation.

First, you need to install Microsoft Visual Studio 2010.

Second, build QGIS 2.18.14. How to do this, please follow the detailed description available from OSGeo: https://github.com/qgis/QGIS/blob/release-2_18/INSTALL

Third, obtain the sources for the QGIS SAML2 Plugin (master) from Github:

https://github.com/securedimensions/QGIS-SAML2-Plugin

Then, start cmake and use the plugin installation directory as source. Create a build directory and use that with cmake. Then select the compiler based on Visual Studio 2010 (use native compiler). The following figure illustrates the CMake configuration. Please make sure to uncheck the "build test app" option.

As can be seen, some dependencies exist to the OSGeo installation of QGIS (C:/OSGeo4W and C:/Program Files/Qgis-2.18.4/include/qgisconfig.h).

Final note: In order for the installation of the DLL to finish with no errors, it is important to change the permissions on the target directory to allow any access: C:/Program Files/Qgis-2.18.4/plugins. In case the permissions are not changed, the default permissions require administrator privileges that the CMake program does not have.

The main difference of this SAML2 plugin compared to the OAuth2 plugin is that no registration is required. With SAML2 protected services, the plugin must execute the SAML2 ECP. For this protocol it is required that the user provides the IdP to use for login.

As noted from the SAML2 ECP standard, the IdP discovery is out of scope. This means that any implementation choice is acceptable as long it results in an IdP selection. For Testbed 13, we decided to implement a generic approach where the IdP discovery is based on the SAML2 federation metadata for the Service and Identity Provider. The Testbed federation metadata can be found here:

For a URL, provided by the user, the plugin parses the metadata and extracts all available IdPs and presents that list to the user. This simplified approach works best for a small number of IdPs (as currently in Testbed 13) but would not work quite as well with a large federation with many IdPs. Nevertheless, everyone has the freedom to implement their own IdP discovery as they see fit.

The following figure illustrates the simplified configuration of the plugin. For the ECP flow to work, the only input required are the user credentials and the federation metadta. When providing login credentials to the plugin, they will be saved in the encrypted SQL lite database as used by the QGIS authentication plugin. And, it is important to know that the user credentials are not send to the Service Provider!

Once the SAML2 plugin is configured to work with a particular IdP, this configuration can be linked to any OWS, protected via SAML2 in the usual fashion. The following figure illustrates how to do that for a SAML2 protected WMS provided by Secure Dimensions for Testbed 13.