OGC Testbed-14: Security Engineering Report

The motivation behind this ER resides on the prevalent disconnect between security standards and current OGC standards. It is necessary to analyze the needs of Spatial Data Infrastructure (SDI) regarding securitization, taking also into account how it affects usability and interoperability.

This ER acknowledges the complexity of this task and focuses on performing a complete analysis of these needs (taking into account workflow and federation aspects of security) and lays out the groundwork for a complex architecture that fulfills as many of those needs as possible.

Therefore, the requirements addressed by this ER are to:

Security discussions prior to Testbed 14 were often focused on specific solutions that solved only a handful of security requirements and were limited to custom-built systems.

On the integration of OGC standards and definition of best practices for integration, the OWS Common Security Standards Working Group recently issued an OGC Web Services Security Standard candidate (OGC 17-007r1) that aims to standardize the security aspects of current Web Services Standards while providing backward compatibility and interoperability. On 13th August 2018, the OGC Technical Committee (TC) voted to recommend approval of the OGC Web Services Security specification as a new OGC standard. The OGC® Web Services Security standard was published on the 28th January 2019.

On the other hand, security discussions prior to this Testbed included concerns regarding Federated Identity Management, but these were not specifically addressed in enough detail.

This situation highlights the need for a general approach to security architectures that utilize the current state-of-the-art standards and takes into account Security Standard Candidates while providing a set of best practices on the integration of security on Federated Clouds and Workflows.

As a result of activities performed during this Testbed, the analysis and implementations documented on this Engineering Report serve as an initial step towards a complete high-level architecture that addresses the identified limitations of current standards when applied to SDI.

Using this ER as a reference, a more general solution to security requirements is proposed (including workflow and federated clouds concerns), making it easier to further discuss and implement complex security architectures with clearly identified components that any Security Environment (in the context of Access Management) or Administrative Domain (in the context of Federated Identity Management) should have.

As a result of the work performed during this Testbed, several future work points have been identified:

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

Contacts

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.

There are four main standards that need to be taken into account:

Several gaps can be identified on current Authentication, Authorization and Accounting services such as those made available to science users and application developers on exploitation platforms. Nowadays, most of the security environments use the SAML standard for solving the authentication and Single Sign-On requirements.

Some of the security environments use XACML (eXtensible Access Control Mark-up Language) for authorization, managing it at application/service level but require a lot more effort in order to have centralized trace of user access that allows accounting. This effort is also passed to developers of client applications which usually are more used to Authentication and Authorization schemes that tend to be JSON-based.

Most of the security environments of the industry consist of either a single point of entry to a restricted system that allows access to all services without any kind of discrimination, or a conglomerate of services with different authentication and authorization schemes. Both of these solutions have an impact on the usability of the system, as well as their ability to scale up easily.

Some of these environments are already making use of identity providers by means of SAML, solving the Single Sign-On requirements that smooth the usability issues on the user side, but fail to address more complex technical requirements such as the use of distributed and aggregated user claims, session timeouts, gathering of user consent to share their personal data and the most important of them: the ability to extend the standard to provide new functionality.

Protocols such as OpenID Connect and UMA 2.0 can be used in combination with or aggregated to OAuth2.0 to provide the means of solving more complex technical needs without extensive development effort. OpenID Connect acts as the counterpart for SAML, and can be combined with UMA in order to fulfill all the requirements of Accounting for current services.

Another key aspect is that development and integration of new systems will not be as complex as the systems previously mentioned thanks, for example, to the Representational State Transfer (REST) Application Programming Interfaces (APIs) that will be made available to all the components in the infrastructure. These components will be able to make use of these APIs to leverage authorization without user interaction, also allowing secure interactions between components.

During this Testbed, OpenID Connect and OAuth2.0 were used taking into account that there is a need to reduce the development and integration impact on applications, services and users while also allowing centralized authentication and authorization with Single Sign-On.

When using OpenID Connect, the main advantage over OAuth2.0 is that the client has the possibility of acquiring user information from the Authorization Server (and this can enable federation as shown in section 9). Additionally, several ways of authenticating users and clients are made available with Each of them having a specific purpose and a best use scenario.

Knowing what these scenarios are in advance can be useful to find a compromise between usability and security. It is also important to take into account the main weaknesses and strengths that each of these methods imply, and adjust the security architecture accordingly. There are four main credential grants that make use of the following endpoints:

Available grants are:

It is known that OAuth2.0 does not really provide authentication capabilities [3] and that can be solved using OpenID Connect (which proves the identity of a user). But more interestingly, OAuth2.0 does not provide Authorization itself as well, but just the means of acquiring a set of access rights with no policies or rules attached. This functionality gap needs to be solved by either extending functionality on the client side, or implementing an extension of OAuth that enables authorization, and choosing one of these two solutions depends on the use cases.

Security is not only about authenticating, authorizing users and having a trace of every action a user does. The security of communication channels must always be taken into account as well, especially when performing these procedures of authentication. This raises a valid concern when releasing tokens that could leak user information if intercepted by someone else.

In this case, OAuth2.0 (which is a layer of implementation behind OpenID Connect) manages these security concerns by relying on TLS (also called HTTPS/SSL) which is universally implemented on clients, servers and web browsers. This automatically requires that any endpoints made available through an Authorization Server need to be locked on HTTPS.

Additionally, releasing user information can be further securitized with OpenID Connect standard JSON Web Token (JWT) data structures. These can be used when claims that belong to a user need to be signed, generating signed JSON Web Tokens (JWS) and when their contents need to be obfuscated, in that case using encrypted JSON Web Tokens (JWE). Signing and encrypting this information with a public key and forcing the receiver to use a private key (similar to TLS foundational architecture) avoids interception of sensible information.

Using this JSON Web Token approach makes OpenID Connect dramatically easier for developers to implement, and in practice has resulted in much better interoperability, while also defining a JSON schema that avoids malicious or unauthorized data transfers [4].

Given that the Authorization Server needs to be compliant with OAuth2.0 and OpenID Connect (References), there is not much design effort to be made regarding its API endpoints, but it might be interesting to take into account further needs (such as federation) and interactions.

In essence, the authorization server adds registration and management capabilities (that populate the LDAP service) on top of the authorization endpoints and makes information about the service available by means of an OpenID Connect Discovery document that lies on a commonly used relative path (/.well-known/openid-configuration).

The Basic Authentication Service is made available for potential use on profile management, and can either use LDAP credentials or utilize the authentication and authorization scheme. The end-users can then interact with clients to retrieve tokens and access services.

Although all grants (section 5.2) are made available using this Authorization Server, only the Implicit Grant will be used to provide authentication and authorization capabilities to workflows. This is due to the fact that the client implementation that will interact with workflows is purely based on JavaScript, which does not allow one to effectively authenticate the client in addition to the end-user (client credentials would be readable even if obfuscated).

Using the Implicit Flow will result in a token being passed between Testbed components. This token effectively contains user information since it can be used on the User Info Endpoint (section 5.2), making it a potential security flaw even if the communications between components are performed on a private network. In order to solve this issue, it is necessary to define the implementation of a different OAuth2.0 grant and the inclusion of encryption as future work.

During Testbed-14, several deliverables require interaction with the service described in this section (D151 Authorization Server). These deliverables can be either clients or services:

Each of these implementations benefit from the Authorization Server by either acquiring tokens using one of the available grants, or validating tokens and extracting user information. The main flow is depicted in Figure 4 as an example for a Web Feature Service:

This figure shows two crucial points for:

The result generated by this infrastructure, applied directly to a client-service architecture, is a simple and fairly secured access to service based on user authentication.

Implementation on the side of the service requires less implementation effort to be functional, but should also take into account the advertising of the service as secure. This aspect of secured web services is depicted in the OGC Web Services Security Standard that recommends the use of additional constraints to facilitate the discoverability of security requisites imposed on OGC Web Services [5] that are expected to be deployed over HTTPS.

This problematic association with the discoverability of service capabilities is also covered in D021 - Next Generation Web APIs/WFS 3.0 ER (OGC 18-045), that also delves deep into OpenAPI capabilities in this regard. During this Testbed, WFS 3.0 services had to understand the requirements and steps for implementing OAuth2.0 and OpenID Connect workflows and how to publish these requirements through OpenAPI documentations which became an addition to the current development status of the services themselves.

This also raised a specific need for web services that provide HTML support and would also require the definition of dedicated clients on the Authorization Service, which means that some WFS 3.0 services developed during this program eventually had to identify themselves not only as services but also as "front-end" clients.

On the other hand, clients that consume these services had no unified mechanism to access protected resources and this particular situation forced them to understand the security criteria required for each service provider prior to their interactions. During this Testbed, the clients' main goal was to traverse the learning curve for OAuth2.0 and OpenID Connect leveraging of APIs, given that one of the first identified needs was to be independent of third-party implementations that could be harder to maintain. The interaction between the Authorization Server and client application developers has resulted in an extensive integration guide (Annex I) that aims to ease the learning curve.

Finally, when it comes to the resulting Security Environment enabled by the Authorization Server, the adoption of OpenID Connect has been a key factor that enables the automation of the discovery steps that need to be performed on the client side. The ability to parse discovery documents, coupled with the use of OpenAPI and constraints on the describe documents of OGC services allows clients to understand which are the security requirements for a given service and to dynamically generate clients that are fit for use.

The main points of identified future work for Authorization Servers reside on these topics:

The mediation service needs to provide the means of authentication to users that belong to different security environments, enabling federation and populating the internal user database with the information that these external environments grant access to.

As an ideal scenario, a mediation service should support the following standards:

This Testbed focuses mainly on OpenID Connect and mutual authentication needs, leaving SAML integration out. In any case, the Mediation Service can only enable "inbound" authentication. This means that what this service accomplishes is mainly allowing access to users coming from other security environments (under predefined restrictions) and the rational behind this is explained in section 9. This service is unable to grant "outbound" access, but it is implied that external identity providers could also implement the same solution, allowing what is known as "two-way federation".

The preliminary analysis for this functionality provides several solutions, each of them raising different issues.

During this testbed, the architecture proposed on section 6 needed to be modified to adjust to the requirements of the Mediation Service based on passport solutions. The final architecture includes the component and its interactions.

The inclusion of this component also has an effect over the sequence diagram in Figure 4, modifying the sequence of the interactions with the client resulting in Figure 9 which gives more detail to Figure 8.

The impact that these changes have on the clients that interact with the Authorization Server and the functionality that becomes available is discussed in the following subsections.

The Mediation Service has been proven to be unable to act as a WPS since it requires end-user interaction which would not allow complete automatization (automatic HTTP redirections and end-user input would be necessary if state of the art methods are to be used). But this testbed has established that the remaining options are:

Both options do not really solve the issue, but Testbed 14 has further developed the security understanding of SDI, especially when it comes to workflows. The usage of Dynamic Registration (based on OAuth2.0) and OpenAPI advertising of security requirements will allow for automation of workflows that have secure services requirements.

In order to do so, a CSW Service and a completely new service (separate from the Mediation Service) are necessary. This new service would have to access the CSW catalog containing references to services and their OpenAPI documents. Assuming this OpenAPI document includes references to a security environment and that the referenced authorization server has dynamic client registration capabilities, this new service will be able to dynamically generate a disposable client for each service in a workflow. None of these operations require user interaction or a web browser, and that would allow this component to be a WPS.

The only remaining issue would be traceability of the requests to the end-user, allowing authorization on the service side. That would mean that user authentication and information need to be acquired independently from this new service. The additions to the workflow would be:

This solution still raises some issues regarding governance of the data stored on the CSW service, encryption, and signing of JSON Web Tokens and trust relationships between all components on a workflow.

There are several points that need to be clarified during this Testbed in order to properly design security solutions for workflows and these are:

In the case of this Testbed, all components belong to the same security environment, which simplifies the issue of discoverability, and relaying of outputs and user information (Figure 9).

In the case of discoverability, the usage of extended constraints on the services to identify which Security Environment the service belongs to (combined with the usage of a CSW service that catalogs references to all services) allows one to determine when a service expects a security token.

Using the information extracted from security constraints, it is possible for the BPMN engine to decide if a security token will be sent to the service (by encoding it on the BPMN document only in the specific requests), allowing external services from other security environments to be accessed without concern of sharing user information unintentionally.

In the case of diverging security requirements from specific resources this Testbed raised some concerns on specific use cases that involve chaining unsecured services with secured services, mainly when outputs from a secure service are not meant to be shared with unsecured services (or just services outside the Security Environment). To solve this issue, there are several possibilities to be analyzed:

Figure 11 shows an example of the interactions described on the first point. This would be the best option in terms of governance, meaning that the centralized authority would still be the authorization server, but at the same time requires services to authenticate themselves in order to access outputs from other services and this would result in increasingly complex development work.

This methodology would require any services to also act as clients that acquire tokens to extract outputs that come as references, but could also be against best-practices for OGC services and workflows.

Trusting the workflow manager (or a mediation service) would be essential in order to apply the second option, meaning that each workflow manager would have to be clearly authenticated and authorized to execute workflows. In order to do this, secured services would expect a way of authenticating the workflow manager itself in addition to the end-user authentication and authorization that is already taking place. This interaction is shown on Figure 12, assuming that the business logic behind the chain is valid when considering the security constraints. It would only require the Workflow Manager to be authenticated (act as a client) instead of having external services be modified in order to be compatible.

Any of these solutions can be further extended with the usage of business logic on the BPMN validation phase, as explained on the Workflows ER.

In the topic of Security, several domains can be identified that usually cover all needs required by any organization or individual. While this Engineering Report has focused mainly on Access Control mechanisms, there is a wide variety of topics (such as Risk Assessment or Threat intelligence, User Education…​) that are usually considered important aspects of security. Although this Testbed does not cover all of them (focusing more on Security Architecture), the concept of Cloud Security and Federated Identity are nevertheless mentioned in several Engineering Reports.

In that aspect, Federated Identity becomes a strong relationship that can be perceived between Federated Clouds and the Security Architecture. During this Testbed, the Federated Clouds ER (OGC 18-090) offers a more formal approach to the topic.

On the other hand, this ER offers a technical approach that is not meant to follow best practices or to conform with the current state of the art extracted from federated clouds architectures. This ER instead serves as a starting point that can be analyzed, modified and extended in order to adjust its technical capabilities to the needs identified during this Testbed.

Initially, the combination of both D151 Authorization Server and D147 Mediation Service establishes what is known as a Centralized Federation figure that allows other Administrative Domains to populate its persistence systems with information from external users.

At the end of this Testbed, this centralized federation is connected to another centralized federation making them both act together as a distributed federation that requires a series of discovery policies and governance solutions in order to become feasible outside the scope of the Testbed.

The architecture proposed for this design is basically the one depicted in Figure 8.

This system allows users from several domains to access Testbed services using their domain credentials instead of credentials stored inside the Authorization Server. The amount of user information collected by the Authorization Server is restricted by the Authorization services that reside in the external Administrative Domain and needs to be agreed upon when configuring the Mediation Service.

With this solution, the authentication of end-users is delegated to external entities, but authorization for the access to the internal service must be performed utilizing the aforementioned user information.

When another instance of the current Testbed architecture is equipped with a Mediation Service that also allows delegation of authentication on its side, it is possible to define a custom client on each side that serves as a relay between both environments.

Each of the environments has the capabilities of defining which scopes (and corresponding attributes) can be requested by the client defined in the opposite Security Environment (enclosed on an Administrative Domain) and it can also define its own client to persist only relevant data or to map an already existing user to an authentication request coming from outside of the Administrative Domain.

The federated solution proposed in this Testbed utilizes current state-of-the-art technologies such as OAuth2.0 / OpenID Connect combined with Passport solutions in order to provide a simple federation mechanism with specific constraints.

Although this architecture serves as a way of providing governance over user information, it lacks the ability to define discovery governance and policies for the services that reside on the Administrative Domain itself.

The main solution to this requirement is to extend OAuth2.0 capabilities so services can act as end-user entities that can register and protect its own resources. For this specific purpose, the UMA standard (User Managed Access) allows the definition of an additional OAuth2.0 flow that specifies how these kinds of transactions can be performed and how different access policies can be enforced on granular sets of resources.

Additionally, it is important to understand the difference between a Security Environment (exercised during this Testbed) and an Administrative domain. The latter is widely explained in the Federated Clouds ER (OGC 18-090) and serves as a wide understanding of what a Security Environment requires in order to comply with the most common governance and discoverability issues when performing federated identity management.

Given the interactions mentioned in Section 6.2, the following Testbed TIE components perform security interactions:

The following Security TIE tests have been performed:

For further detail on TIE experiments, including multimedia samples and a matrix per component, the following sources can be consulted: