2.1. Securing the access to the web services

Given that these services communicate via the http protocol and can be called upon from different locations, the SocrateCloud administrators must implement strict access rules to prevent any leaks of confidential information.

These rules can be defined in the Web Services window found in the System Admin -> General Rules -> Security menu.

Note: The web services are responsible for verifying the access rules defined in this window.

All the web services provided by BitSoftware implement the validation of these access rules.

The security for web services is done for each separate service and method, indicating the class and method as such:

1. for the Data Exchange Interface component:

   • for HTTP GET: org.bitsoftware.sdei.rws.service.rfDataResource.get

   • for HTTP PUT: org.bitsoftware.sdei.rws.service.rfDataResource.put

   • for HTTP POST: org.bitsoftware.sdei.rws.service.rfDataResource.post

2. for the Hours Management component:

   • method getAcctAmt: ws.bitsoftware.shrm.shrmWs.getAcctAmt

     • method getAcctCombinationList: ws.bitsoftware.shrm.shrmWs.getAcctCombinationList

     • method getEmployeeList: ws.bitsoftware.shrm.shrmWs.getEmployeeList

     • method getMonthlyTimeAttendance: ws.bitsoftware.shrm.shrmWs.getMonthlyTimeAttendance

     • method getTimeTypeList: ws.bitsoftware.shrm.shrmWs.getTimeTypeList

     • method getWorkedTime: ws.bitsoftware.shrm.shrmWs.getWorkedTime

     • method setEmployeeCost: ws.bitsoftware.shrm.shrmWs.setEmployeeCost

3. for the HH integration component:

   • • method getActivities: ws.bitsoftware.sohh.sohhWs.getActivities

     • method getLocators: ws.bitsoftware.sohh.sohhWs.getLocators

     • method getMoveConfirmationHeaders: ws.bitsoftware.sohh.sohhWs.getMoveConfirmationHeaders

     • method getMoveConfirmationLines: ws.bitsoftware.sohh.sohhWs.getMoveConfirmationLines

     • method getProducts: ws.bitsoftware.sohh.sohhWs.getProducts

     • method getQtyAvailable: ws.bitsoftware.sohh.sohhWs.getQtyAvailable

     • method getReceiptConfirmationHeaders: ws.bitsoftware.sohh.sohhWs.getReceiptConfirmationHeaders

   • method getReceiptConfirmationLines: ws.bitsoftware.sohh.sohhWs.getReceiptConfirmationLines

   • method getShipConfirmationHeaders: ws.bitsoftware.sohh.sohhWs.getShipConfirmationHeaders

   • method getShipConfirmationLines: ws.bitsoftware.sohh.sohhWs.getShipConfirmationLines

   • method getWarehouseLocators: ws.bitsoftware.sohh.sohhWs.getWarehouseLocators

   • method getWarehouses: ws.bitsoftware.sohh.sohhWs.getWarehouses

   • method createMaterialMovement: ws.bitsoftware.sohh.sohhWs.createMaterialMovement

   • method processInOutConfirmation: ws.bitsoftware.sohh.sohhWs.processInOutConfirmation

   • method processMoveConfirmation: ws.bitsoftware.sohh.sohhWs.processMoveConfirmation

   • method saveProductLocator: ws.bitsoftware.sohh.sohhWs.saveProductLocator

   • method sendDocument: ws.bitsoftware.sohh.sohhWs.sendDocument

The security must be mandatory based on the role and user!

The encryption of the transmitted information, both the identification data (role, user, password, etc.) and the received data, is done via the HTTPS protocol when calling upon the services. It is not possible to encrypt the data at the application level!

Definition

This is done in the Web Services window:

• Name: the name of the service.

• Classname: the java class, including the method, that implements the service;

• Require user with role: the user with whose credentials you call the web service must have been assigned a role;

• Anonymous access: you may call the web service without specifying the credentials of a user;

• Enforce Role based access: this checkbox specifies if you use role-based security when accessing the web service;

• Enforce IP based access: this checkbox specifies if you use IP address-based security when accessing the web service;

• Comments: the description of the service

• Active: this checkbox indicates whether the web service is active or not. The inactive services cannot be accessed irrespective of whether the classname that implements these is loaded in the SocrateCloud server.

Security based on the role

This is done in the Role Access tab. Through this mechanism you can specify the roles with which you can call the web service.

The Web Users window, located in the System Admin -> General Rules -> Security menu, is used to maintain / register the users that will have access to web services, regardless of role.

For further information on roles and users please see Roles and Users.

Security based on the IP

This is done in the IP Access tab. Through this mechanism you can specify the IP addresses from which you can call the web service.

You can enter multiple addresses divided by semicolons. Furthermore, you can also use IP address classes. For example 192.168.0.0 signifies that you grant the access to any IP address starting with 192.168.

• Role: optionally, you can define distinct IP addresses depending on the role. Take into account that the IP-based access rules are cumulative. For example, if you grant the access to the address class 192.168.0.0 without specifying a role and if, furthermore, for the GardeAdmin role, you select the 80.96.43.1 IP address from which he can access the web service, then the GardenAdmin role will be able to access the service from this IP address and any other address starting with 192.168.

• IP: the addresses and address classes from which you grant the access to the service.

Log

In this tab you can track the log of the service calls.

The Clean WS Log process, located in the System Admin -> General Rules -> Security menu, can be used to delete service call records. The following parameters are available:

• Web Service - web service for which the process is run. If left empty, the process will be run for all web services;

• Days to Keep Log - only records older than the number of days entered will be deleted;