/sicsdocs/technical/server/api_server/server_security/ Recent content in Server Security on Hugo -- gohugo.io /sicsdocs/technical/server/api_server/server_security/introduction/ Mon, 01 Jan 0001 00:00:00 +0000 /sicsdocs/technical/server/api_server/server_security/introduction/ SICS API Server is a software component in the SICS product suite. SICS API Server implements the Web Services that allows external applications to call/invoke SICS functions. This document describes the Security features that SICS API Server supports. What this document covers # Security feature Description Authentication How to get SICS API Server to authenticate the sender of Web Services calls. Authorization How to get SICS API Server to check whether a user has the authority (Access Rights) to invoke a web service, and to perform the business logic that is re-used from the SICS on-line system. /sicsdocs/technical/server/api_server/server_security/security_parameters/ Mon, 01 Jan 0001 00:00:00 +0000 /sicsdocs/technical/server/api_server/server_security/security_parameters/ Three parameters determine ‘Secure’ and ‘Non-Secure’ Modes of SICS API Server Start-up. The parameters act as overall switches for the authentication and authorization security functions. The parameters are found in the web.xml file. If SICS API Server is installed as described in SICS API Server - Installation Guide, this file can be found (for Tomcat 10.x) in: %CATALINA_HOME%/webapps/SicsServer/WEB-INF/web.xml. The parameters are: Parameter name Valid values Default Purpose web.xml ApplyServerSecurity true/false false Indicates whether SICS API Server is running in secure mode or not. /sicsdocs/technical/server/api_server/server_security/authentication/ Mon, 01 Jan 0001 00:00:00 +0000 /sicsdocs/technical/server/api_server/server_security/authentication/ If SICS API Server is started in secure mode, all normal Web Services calls must include an authentication token. The caller must obtain this token by sending an initial “login” message to SICS API Server. The Login service # Sample SOAP Request and Response # The SOAP request (input message) for the login service must follow one of these formats (see discussion on OS AUTHENTICATION and <sicsUserId> further down): <SOAP-ENV:Envelope . /sicsdocs/technical/server/api_server/server_security/authorization/ Mon, 01 Jan 0001 00:00:00 +0000 /sicsdocs/technical/server/api_server/server_security/authorization/ Authorization is the process of ensuring that the caller invokes services that the caller is allowed to execute, according to the caller’s SICS user profile. When receiving a service call request, SICS API Server verifies whether the SICS user identified by the “User ID” (present in the Authentication Token) has Access Rights to execute the service, according to the (existing) security set-up defined via the SICS System Administration utility. See also SICS API Server - Installation Guide, on how to set up your own authorization policy. /sicsdocs/technical/server/api_server/server_security/enable_api_server_module/ Mon, 01 Jan 0001 00:00:00 +0000 /sicsdocs/technical/server/api_server/server_security/enable_api_server_module/ To enable the API Server module, check the API Server module in use checkbox in System Parameter Maintenance -> Module Key. Figure 1 - Module Keys System Parameter /sicsdocs/technical/server/api_server/server_security/web_services_use_cases/ Mon, 01 Jan 0001 00:00:00 +0000 /sicsdocs/technical/server/api_server/server_security/web_services_use_cases/ Use Case security # Each Web Service is defined as a “Use Case” in the SICS Security module. This means that it is possible to “switch off” each of the Web Services that your company do not use, by simply removing the unused Use Cases from the security profiles. Naming convention # All Web Services Use Cases are named with the “API” (Application Programming Interface) prefix, to easily separate them from the normal SICS Workstation Use Cases.