Mashup security

API Security is turned off for Sterling Store Engagement. Instead, a similar feature is implemented in the mashup layer.

Controlling the access of API-calls from the client is essential for a web application. In Sterling Store Engagement, API security is not implemented directly. Instead, API access is restricted from mashup layer. In the current framework, the following process is exposed for API calls from clients:

Every mashup (API) call is done through a controller (init or behavior) URL.
All controller URLs go through a common struts action.
As part of input for Controller URLs, all mashup inputs are sent.
Backend controller implementation takes all the inputs and calls the corresponding mashups that are in the input.

As API security is turned off for the application, API calls are made secure in the following ways:

Each mashup call is verified to ensure that the current user has the required permission to call the mashup.
Each mashup input is verified against the input template that is defined in the mashup definition, so that unwanted inputs that can cause security vulnerability are not passed by the client.
The output of an API call is controlled by the output template in the mashup definition, which cannot be manipulated from the client.

To make Sterling Store Engagement secure, the mashup security feature is implemented:

All mashup definitions have multiple AternateResourceId(s) associated with them, which defines the resources that have permissions to call the current mashup.
- A single mashup can be called from multiple screens or modules. Hence, such mashups have multiple AlternateResourceId(s) associated with them.
- Common mashups or data-provider mashups are associated with the application ResourceId - WSCSYS00001, for which the permission is given to all users.
The input template for any API call in the mashup definition is restrictive and controlled to allow only the attributes that can be passed as input to the current mashup call.
- A scenario in which the same mashup is called from different screens or modules that are permission-dependent, must be handled carefully by using custom mashup, to allow only certain inputs for a particular scenario, if the user does not have permission to view certain data. For example, the mashup that is called in the Add Products screen to add products is also called to override price. However, the override price feature is permission-controlled. So, there should be a custom mashup in the backend for this scenario and that backend class should verify if the user has permission for override price or not and then only allow override price attributes in changeOrder API call.

The platform class SCUIXAPIActionUtils (method validateMashupInput) is responsible for doing the input template validation for mashup calls:

The input template in the mashup definition should be same as the template that is passed by the mashup layer to the API call, including any common attributes added in the mashup layer.
The mashup security feature for validating inputs has the following modes.
- ERROR (default): Any violation is displayed as error.
- DEBUG: Any violation is logged as error in the logs but the mashup call goes through.
- NONE: No input validation happens for API calls from mashup layer.

The Context-Parameter, scui-xapi-mashup-security-mode can be set to one of the modes. Default mode is ERROR.

The platform mashup helper classes are responsible for doing authorization of mashup calls against the AlternateResourceId(s) defined in the mashup definition. : If any one of the resourceIds defined in the mashup definition has permissions to call this mashup, the mashup call goes through.