Difference between revisions of "GCube-Enabled geo-services"
(→Philosophy) |
(→Architecture) |
||
| Line 17: | Line 17: | ||
=== Architecture === | === Architecture === | ||
| + | The aim of '''gCube-enabled geo-services''' is to intercept incoming http(s) requests under certain conditions, and make them authorized by the underlying geo-service. The chosen approach is to provide a '''filter''' servlet which for every and each request : | ||
| + | * if the request doesn't declare a '''gcube-token''' do nothing. Else | ||
| + | ** Retrieves the credentials ''<CREDENTIALS>'' for that token ( via the [[SDI-Service]]) | ||
| + | ** Does the required operation(s) in order for the incoming request to be authenticated as ''<CREDENTIALS>'' | ||
| + | |||
| + | The picture below describes the architecture of a '''gCube-enabled''' GeoServer. | ||
| + | |||
| + | [[Image:GeoServer Connector.png|frame|center|GCube-Enabled GeoServer]] | ||
== Deployment == | == Deployment == | ||
Revision as of 18:33, 20 November 2017
Contents
Overview
By saying GCube-Enabled geo-services we identify all services involved in an SDI that understand and exploit gcube authorization framework. While dealing with these services, authentication and authorization of http(s) requests rely on the presence of the gcube-token just as like as any other gCube Service, relieving users and applications from dealing with :
- non standard authentication APIs
- specific instance credentials use
Key Features
GCube-Enabled geo-services is a technology provided by gCube offering the following key features on geo-services :
- Automatic geo-service authentication of http(s) requests declaring a valid gcube-token
Design
Philosophy
Geo-services are typically third-party software with no knowledge of gCube technology, thus all of these services implements their own approach in terms of security. gCube-enabled geo-services represents a wrapping layer around geo-services, harmonizing the security level of these technologies with the gCube Authorization Framework. Since Geo-services are used and integrated in other systems that might not be aware of gCube Authorization Framework, it is crucial that the layer introduced by gCube-enabled geo-services is absolutely transparent to non-gCube applications.
Architecture
The aim of gCube-enabled geo-services is to intercept incoming http(s) requests under certain conditions, and make them authorized by the underlying geo-service. The chosen approach is to provide a filter servlet which for every and each request :
- if the request doesn't declare a gcube-token do nothing. Else
- Retrieves the credentials <CREDENTIALS> for that token ( via the SDI-Service)
- Does the required operation(s) in order for the incoming request to be authenticated as <CREDENTIALS>
The picture below describes the architecture of a gCube-enabled GeoServer.
