OGC Testbed-14: Authorisation, Authentication, & Billing Engineering Report

The primary motivation behind this ER is to tackle user’s authentication and subsequent authorization concerns in terms of process deployment and execution within a pool of Thematics Exploitation Platforms (TEP) and Mission Exploitation Platforms (MEP).

Additionally, this ER addresses quotation mechanism and associated billing aspects of existing processes exposed through a secured OGC Web Processing Service 2.0 endpoint.

In Testbed-13, the Security Engineering Report (ER) covered topics related to the implementation of authentication and authorization plugins for the QGIS open source desktop GIS client and the implementation of a secured workflow. The present ER covers more specifically the authentication and authorization mechanism applied to EMS and ADES.

Billing and Quotation have been introduced within Testbed14 and are currently not addressed by OGC standards.

The OGC WPS 2.0 standard was already a key part of the work done in Testbed-13 and continued to be so in Testbed-14. Indeed, given that one of the core aspects of Earth Observation Exploitation Platforms is the data processing, WPS is a natural fit. At the same time, not only in Testbed-13 but in general, variations and possibilities related to WPS, such as the Transactional extension (WPS-T) and the reliance on REST bindings and JSON encoding, are of increasing interest and popularity as they bring the OGC and WPS in particular closer to the mainstream web and technological realms.

Given that a significant amount of effort in the EOC thread of Testbed 14 has been dedicated to experimenting with these WPS variations and possibilities, this work is expected to be of high interest to the WPS 2.0 Standards Working Group (SWG). In coordination with the WPS 2.0 SWG, several smaller (or one or two larger) Change Requests can be prepared so as to start the standardization path for WPS-T and the WPS REST/JSON work.

For OGC, the work described in this Engineering Report, which makes the case for how OGC standards are helpful in such a densely populated ecosystem of very heterogeneous entities, technologies and implementations such as the Exploitation Platforms one, is deemed extremely relevant in satisfying the needs of the ESA as one of its Strategic Partners.

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.

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

The sequence diagram below presents an overview of the authentication/authorization sequence between the different components involved in Testbed 14 in the case of a call to an execute service.

Usually, the authentication of users is delegated to an Identity Provider (IdP) while the authorizations occur at the resources/services providers level (i.e. EMS and ADES).

In Testbed-14, users authenticate through the Web client using the OpenID Connect protocol 1.0. Other protocols can be used for authentication (e.g. shibboleth, EduGain, etc.). However whatever the implementation and the authentication method chosen, the IdP should provide to the Client an access_token that can be used to request End User claims through a UserInfo Endpoint.

In summary, in Testbed-14 the following assumptions are made:

On successful End User authentication, the Web Client stores the access_token. The access_token that is provided for each request is issued from the Client to the resource server (i.e. EMS) and propagated in a subsequent request (i.e. from EMS to ADES).

From a security point of view, the access_token credentials must be kept confidential in transit and storage, and only shared among the Web Client, the IdP and the EMS/ADES. Indeed, anyone in possession of a valid access_token can get the corresponding user’s profile without any verification.

As a consequence, to minimize the risk of exposing the access_token, all exchange between the Web Client, the IdP and the EMS/ADES must use the https protocol.

In the initial scenario, Alice can deploy a process and Bob can only execute the process. Once Alice deploys her process, the process is effectively deployed on EMS and is made available for Bob.

When Bob launches a job to execute the process, the EMS decides on which MEP(s) the process should be executed deploys an ADES accordingly. This raises an authorization issue: to deploys ADES on MEPs, EMS must provide a user’s access_token that give rights to deploy process on ADES. Since the execute request is sent by Bob, the EMS has access to the access_token from Bob and not from Alice.

To solve this issue, we are considering two solutions:

In the previous example, we choose the first solution i.e. as "member", Bob can deploy on ADES. However, this discussion is not closed and could be adressed in future work.

Usually processing platforms provide pay-per-use services where customers are charged when they use the service. Thus, in the case of processing services, it may be interesting to have an estimate of the cost of processing before it is launched.

The quotation model has been discussed for that reason. Prior to executing a process, a user asks the resource server (e.g. EMS) for a quotation. The quotation service takes the same input as the corresponding execute service – basically it’s like executing the process without actually executing it.

Upon reception of a quotation request, the EMS analyzes the request and subsequently propagates it to all ADES that would be involved in the final processing request. Finally, the EMS aggregates the quotation results from all ADES and provides to the user a consolidated quotation result based on the sum of ADES quotations results (including eventually an overhead from EMS itself).

Optionally, the quotation results can contain alternative quotations to the default quotation. For instance, these quotations can propose different prices based on different Quality-of-Service (lower or higher processing time, etc.).

The sequence diagram below presents an overview of the quotation process call.

Each resource server (EMS and ADES) that conforms to the quotation service should provide the endpoints described in this chapter.

A full description of these endpoints is available within the ADES WPS-T OpenAPI description.

In the following, we suppose that Bob is authenticated and get a valid Access Token aka Th34cc3ssTok3nForBob.

With the following POST data

The response is an HTTP 201 "Created" with a Location property containing the url to the getQuotation endpoint

The quotation is considered as completed when the status property is set to "complete". Otherwise the quotation process is not finished and the request must be sent again (i.e. polling strategy)

Billing is very specific to each platform. Therefore the scope of this chapter is limited to the association of a bill identifier to a processing result and considers the relationship between billing and quotation.

On the latter, it would seem legitimate that the price displayed on the bill would be the same as the price provided during the quotation process. From the discussion on the cost estimate in the previous chapter, the billing should not be based on the real use of each platform but on the estimated use of each platform computed during the quotation task.

Each resource server (EMS and ADES) that conforms to the billing service should provide the endpoints described in this chapter.

A full description of these services is available within the ADES WPS-T OpenAPI description.

The response is an empty HTTP 201 "Created" with a Location property containing the url to the getStatus endpoint

With the following result .Listing executeProcessResponse (JSON)

The url to the bill for this job is provided as an hypermedia link with rel="bill"

with the following result