EntireX Security is the standard security solution provided with EntireX. It provides centralized security for EntireX Broker under z/OS, Linux and Windows. EntireX Security operates with your organization's security repository. This document covers the following topics:
Note:
Trace files can contain sensitive personal data (user ID, IP address, SSL certificates and payload data).
This is particularly relevant if you have activated EntireX Security. EntireX uses trace files for accounting, diagnostics
and error analysis.
We recommend you check the different trace opportunities provided by EntireX and delete trace files if they are no longer
needed.
The various EntireX components will not delete these trace files automatically; this is your responsibility as user.
Use the appropriate tools of the respective operating system.
This diagram shows the locations where the broker kernel and broker stubs can be installed; it also shows the locations of the security components of the kernel and stubs.
The Platform Coverage shows where broker kernel and stubs are supported.
EntireX Security provides comprehensive security for EntireX Broker:
user authentication
user authorization
supplied in object code only
The major advantages of EntireX Security:
Comprehensive Security
EntireX Security provides comprehensive security for EntireX Broker, that is user authentication and user authorization
Protection of Application Systems
EntireX Security protects client and server application systems.
No User Exits to Write/Debug
EntireX Security is fully supported (that is, object code only). There are no user exits to write and debug. In most installations
EntireX Security operates without altering runtime applications.
One User=One Definition
EntireX Security allows your organization to control the use of all applications, including distributed components, from a
central point, enabling flexible control with a "one user = one definition" approach.
Standard Security Definitions
EntireX Security enables security definitions, based on class/name/service (client and server), to be validated. All definitions
are managed using existing security procedures and software.
Protected Investment in SAF-based Security Repositories
On z/OS security definitions are accessed using industry standard SAF interface. Your investment in SAF-based security repositories
is therefore protected. This includes not only the security systems RACF, CA ACF2 and CA Top Secret, but also the infrastructure
to administer security profiles.
This section covers the following topics:
Authentication verifies whether the identity specified by the user application is the actual identity. Authentication is performed for application components executing on different platforms against the security repository where the broker kernel resides. It is the responsibility of the application to supply the user ID and password.
Authorization determines whether client and server application
components are allowed to execute with EntireX Broker. The
class, server and service associated with the user's command form the basis for
the check. Separate authorization checks are performed, depending on the role
of the application as either client or server. The checks differentiate between
the client's SEND command and a server's REGISTER command. Therefore your
security administrator should allow only the level of access required for the
user to operate in the intended role. The authorization checks are performed on
the same platform as the broker kernel resides (see Location of Security Components)
regardless of location of
the individual application components.
This authorization functionality is available only with EntireX Broker running under z/OS. Under Linux and Windows, limited functionality is available through authorization rules. See also Authorization Rules.
Authorization determines whether a user is permitted to issue commands
to the EntireX Broker Command and
Information Services. See Broker Command and Information Services.
The following resource definitions, derived
from the user's intended activities, form the basis for the check. The level of
authorization needed for accessing these services is identical to that of a
"client". These services are automatically started by broker kernel without
performing a check for REGISTER:
| Resource Definition | Using |
|---|---|
SAG.ETBCIS.CMD |
ETBCMD |
SAG.ETBCIS.INFO |
ETBINFO to retrieve general information. Specify INFO
for the full information service: all clients, servers and conversations are listed.
|
SAG.ETBCIS.SAGCCV5 |
For RPC CIS command services. |
SAG.ETBCIS.SAGCIV5 |
For RPC CIS information services. |
SAG.ETBCIS.SECURITY-CMD |
For security related requests: (1) reset user [ACEE]; (2) change security trace level. |
SAG.ETBCIS.USER-INFO |
ETBINFO to retrieve information specific to the
user issuing the command. USER-INFO is an information service limited to
user-specific information: only the user's own resources are listed.
|
In addition, a separate authorization check is made when a user attempts to perform third party actions affecting other users:
To shut down a service, users must have the required authorization to register this class, server and service themselves.
To shut down a server, users must have the required authorization to register all the services registered by that server.
This authorization is required in addition to the requesting user's ability to use SAG.ETBCIS.CMD in general.
This authorization functionality is available only with EntireX Broker running under z/OS. Under Linux and Windows, limited functionality is available through authorization rules. See also Authorization Rules.
The diagram shows the location of the security components of the kernel and stubs of EntireX Broker. Each step in the table below represents a specific step in the data flow sequence.This table describes the functionality of the security components of the kernel / stubs of broker: authorization and authentication.
Note:
This diagram depicts the operation of the broker stub for Natural and
other third-generation programming languages. It is not intended to show the mechanism used by the
Java ACI and EntireX Adapter with regard to EntireX Security. See Using EntireX Security with Java-based EntireX Applications under Writing Advanced Applications - EntireX Java ACI.
Broker stub calls security module SECUEXIT, if present.
Security module SECUEXIT encrypts the password.
Broker stub communicates the call to the broker kernel.
Broker kernel calls security module USRSEC, which provides the functionality, based on the Configuration Options for Broker:
re-authentication if a user acquires a new physical user ID
re-authentication if the value of a user's ACI security token changes.
All functionality is available on z/OS only.
Security module USRSEC references local security system where the broker is located:
z/OS
Security module USRSEC calls SAF (RACF, CA ACF2 or CA Top Secret).
Linux
Security module USRSEC calls the Linux security system or LDAP.
Windows
Security module USRSEC calls the Windows security system or
LDAP.
The result of the security check is communicated back to
security module USRSEC.
Security module USRSEC passes call to Broker kernel.
Broker kernel communicates the call to Broker stub of the partner application.
The Broker stub calls
SECUEXIT.
Security module SECUEXIT returns call to Broker stub.
For installation see Installing/Setting up EntireX Security under z/OS | Linux | Windows | BS2000 in the platform-specific Installation documentation.
See also EntireX Glossary.
Authentication verifies whether the identity specified by the user ID in the ACI control block is the actual identity. Authentication is performed by checking the user's ID and password against a security system, except where Trusted user ID automatically acquires the identity of the logged-on user or batch job, obviating the requirement for a password in the ACI control block. See Trusted User ID. Trusted user ID is applicable only where the application component and the broker kernel reside under z/OS.
Authentication is not performed with every call. It is performed when a user is first presented to the kernel of EntireX Broker. The broker kernel recognizes the identity of the user on subsequent occasions by combination of user ID and physical user ID (or user ID and token where supplied). Broker kernel also verifies the correctness of the ACI security token on all subsequent commands and, if this is not as expected, the application must provide the correct user ID and password again (unless configured otherwise).
An application identifying itself by combination of user ID and token can change its physical user ID without needing to provide the user ID and password again provided it maintains the value of ACI security token in the broker control block. This functionality is recommended for multithreading applications or applications executing within a Web server. Caution should be exercised to ensure the user ID and token combination is unique.
Authorization is performed when:
a client issues a
request to a service in the case of the first SEND command in a conversation,
or of each SEND command if CONV-ID=NONE
a server registers a service to the broker
an application connects to broker through TCP/IP, an optional authorization check is performed based on the address
Full authorization functionality is available only under z/OS.
It is the location of the broker kernel that determines the point at which the authentication and authorization checks are performed. Authentication and Authorization are performed in the kernel.
See Platform Coverage for where EntireX Broker kernel is supported.
In EntireX Broker, a module that implements the ACI (Advanced Communication Interface) is commonly referred to as "broker stub" or simply "stub". Stubs are installed on the client side or server side.
See Platform Coverage for where broker stubs are supported.