Optima authentication system

The HTTP addresses of the web services exposed by various modules of Optima are subject to authentication. The authentication system ensures that requests made ​​by clients have the necessary authorization to access these web services.

How the authentication works

From a technical point of view, OptimaWSI is located in-between the client and the server, either by a servlet filter or by the functionality of the HTTP proxy.

In case a request results to be invalid, OptimaWSI responds to the client with the HTTP status code “401 Unauthorized”.

The relationships between the resources protected and the related security controls that verify authorizations at runtime are stored in the Optima database. The authentication rules are stored in the module and updated at preset time intervals. If authentication rules are modified, the modification takes effect after the preset time interval has passed (→ Managing authentication rules).

User authentication systems available on Optima

User authentication on Optima through Optima DB is always enabled.

Furthermore, Optima can perform user authentication with:

For the necessary configuration related to LDAP settings, see → OptimaWSI configuration > OptimaAuth section.

The mapping between the objects of the authentication system and the tables in the Optima database is as follows:

Object Table Description
Resources AUTH_METHODS A resource represents an URL to be protected by the authentication system. If OptimaWSI receives a request for a URL that has not been defined in this table, the request is rejected.

URLs are expressed as regular expressions.

The resources are ordered by descending priority and by ascending IDNO. The first regular expression that matches the URL is evaluated.

With the field skip_auth you can exclude a particular URL from the authentication system.
Objects AUTH_OBJECTS An object consists of one or more resources. The authentication rules are defined on the basis of the objects. OptimaWSI uses resources to identify which object is to be considered for the intercepted request.
Conditions AUTH_CONDITIONS A condition is a rule that is evaluated for a given request. The condition represents the element that determines whether the request can be approved.
Actions AUTH_OBJECTS_ACTION An action is a special condition associated with an object. Each authentication rule refers to an action. The actions are used to identify the type of request sent to the module (example: read and write access).
Permissions AUTH_PERMISSIONS A permission is a condition that is associated to a value to be tested. Permissions are in a logical AND relationship to each other. If permissions are of the same type, they are in a logical OR relationship to each other.
Permission groups AUTH_PERMISSIONS_GROUP Permissions are combined into permission groups. The permission groups are in a logical OR relationship to each other.

The next image shows the relational pattern between the tables contained in the database:

The following table lists the objects and their actions for the standard configuration of Optima.

Object Actions

Traffic
Supervisor

Traffic Supervisor.

Action Code

Description

login

TS-Login

All basic interactions that are front-end related, including websocket communications.

Dashboard

Administation dashboard.

login

Datex2

Represents the DATEX II Interface.

Action Code

Description

getPublication: Access the DATEX II feed that contains active system events.

get Datex II Publication internal requests

No login required for requests from the local host.

get Datex II Publication external requests

Login required for requests from the external host

setPublication: Receive an event feed in DATEX II format.

 

set Datex II Publication internal requests

No login required for requests from the local host.

set Datex II Publication external requests

Login required for requests from the external host.

Configuration

 

DATEX2 administration internal requests

No login required for requests from the local host.

DATEX2 administration external requests

Login required for requests from the external host.

OptimaTDE: Permission inside SISTeMA.

OPTIMA

Internal Web services.

TS-Create: Create an event through the Traffic Supervisor user interface.

TS-Datex2-Create

N.A.

TS-Delete: Delete an event from the DB (a finished event is not deleted from the DB).

TS-Datex2-Delete

This group is to delete an event/scenario and other front-end-related services.

TS-Read: Display the attributes of an event through the Traffic Supervisor UI.

 TS-Datex2-Read N.A.

TS-Update: Update the attributes of an event through the Traffic Supervisor UI (the termination of an event coincides with this permission).

TS-Datex2-Update

N.A.

Datex1_2

Action Code

Description

TS-Crud

TS Datex new event create

N.A.
LayerTS

Represents the layers exposed to the Traffic Supervisor interface and accessible separately via WFS and WMS requests.

Action Code

Description

GetCapabilities: Access the tabular representation of the elements of a layer.

AggiungiLayer

Allows for the addition of aTS layer.

GeoLayer-Insert: Add an element to a layer.

 

 

 

Creazione Path

Layer element values:

  • webcam
  • path_resu
  • path_resu_link
  • filters
  • filter_conditions

N.A.

Controller Insert

Layer element values:

  • controller_command

N.A.

Scenario Insert

Layer element values:

  • simu
  • simg
  • sims

N.A.

GeoLayer-Update: Update the attributes of a layer element.

Aggiornamento Path

Layer element values:

  • path_resu
  • path_resu_link
  • filters
  • filter_conditions

N.A.

Count Locations Update

Layer element values:

  • cloc

N.A.

Scenario Update

Layer element values:

  • simg
  • scen

N.A.

GeoLayer-Delete: Delete the attributes of a layer element.

Eliminazione Path

Layer element values:

  • path_resu
  • path_resu_link
  • filters
  • filter_conditions

N.A.

GeoLayer-Read: Read the elements of a layer.

Example: events map visualization.

 

TS-Read-AllLayers Path

Layer element values:

All logged users have read access to ANY layer.

Read-Hyperpath-layers

Layer element values:

  • events
  • parking
  • strt
  • trasffic_lasthour_hier
  • tstp

Non-logged users have access to the selected layers from the hyperpath workspace.

Geoserver

GeoServer module.

Action Code

Description

Geoserver-admin: Access the administration panel of GeoServer

Geoserver admin

N.D.

OptimaControl

Action Code

Description

OptimaControl-Admin: Access the administration panel of GeoServer

Optima Control administration

N.D.

RouteMatcher

Action Code

Description

RouteMatcher-request

routeMatcher internal requests

Values:

127.0.0.1/32

No login required for requests from the local host.

routeMatcher external requests

Login required for requests from the external host.
OptimaADI
Action Code

Description

OptimaADI-request

Optima ADI internal request

Values:

127.0.0.1/32

No login required for requests from the local host.

OptimaADI-request

Optima ADI internal request

Login required for requests from the external host.
OptimaKPI
Action Code

Description

OptimaKPI-Create

OptimaKPI-Create

Web service for the KPI create operation.

OptimaKPI-Read

OptimaKPI-Read

Web service for the KPI read operation.

OptimaKPI-Update

OptimaKPI-Update

Web service for the KPI update or for a logical delete operation.
OptimaMicro
Action Code

Description

OptimaMicro-request

OptimaMicro-simulation-request

Web service for Optima Micro request operations.
OptimaControl2
Action Code

Description

OptimaControl2-Admin

OptimaControl-2-request

Web service for Optima Control request operations.
TRE
Action Code

Description

TRE-Status

N.A.

N.A.

TRE-StopService

N.A.

N.A.

TRE-Set

N.A.

N.A.

TRE-EqFunc

N.A.

N.A.

TRE_Simulation-Start/Stop

N.A.

N.A.

The following table lists the installed conditions for the default configuration of Optima. The code is the one shown on the OptimaWSI administration dashboard.

Code Description Input Multiple values
hasRole Checks whether the request has been made ​​by a user who belongs to at least one of the selected roles. Default = system roles yes
booleanCondition If set to TRUE, this condition is always evaluated as TRUE.

If set to FALSE, this condition is always evaluated as FALSE.

 TRUE or FALSE no
ogcLayerName Checks whether the request has been made on a layer that belongs to the parameter list of the condition. Default = list of WMS or WFS layers exposed by GeoServer yes
ogcLayerAction See the object action of LayerTS (→ List of objects and actions).

 

 no
ipCondition Checks whether the request comes from a client with an IP address that falls within the specified range. Subnet IP mask in the form X.X.X.X/X yes
Datex2EventAction See the object action of Datex2(→ List of objects and actions). CRUD action yes
GeoserverAction Accesses the administration panel of GeoServer.   no
TREAction See the object action of TRE (→ List of objects and actions).   yes
  1. OptimaWSI intercepts a request.
  2. OptimaWSI extracts the configuration and user information.
  3. OptimaWSI searches for the requested resource. If it cannot identify the resource, it rejects the request with the HTTP code 401.
  4. OptimaWSI checks the request for all the actions that are associated with the identified object. If OptimaWSI cannot identify any action, it rejects the request with the HTTP code 401.

  5. For each set of permissions associated with the object-action pair:

    1. OptimaWSI evaluates all conditions of the same type in a Boolean OR operation
    2. OptimaWSI evaluates all conditions of a permit in a Boolean AND operation
  6. OptimaWSI allows for the request if there is no set of permissions associated with the object-action pair, that is, if all the conditions of a group of permissions are evaluated as TRUE.

The authentication system intercepts the HTTP requests sent to the various modules of Optima before they reach the target system. This makes it possible to integrate different modules with the same authentication system without the need to make changes to each module. You can also integrate modules that do not belong to Optima in the same way.

OptimaWSI provides two mechanisms for intercepting requests:

  • Servlet filters, in order to automatically intercept the requests routed to the modules installed on the same application server of OptimaWSI
  • HTTP proxy, in order to intercept the requests routed to external software modules

HTTP requests can contain two parameters to be evaluated by the authentication module:

  • configuration (required)
  • sessionId (optional)

These parameters can be sent to the server either by two HTTP headers, by a cookie, or by the query string of the request.

Topics in this section