CA IDMS Centralized Security Overview

This section describes the purposes of centralized security and defines the CA IDMS security domain.
idms19
This section describes the purposes of centralized security and defines the CA IDMS security domain,.
 
 
2
 
2
 
 
The purposes of CA IDMS centralized security are to provide the following:
  • A system for protecting CA IDMS resources when an external security system is not available or not used to protect CA IDMS resources.
  • A system for protecting CA IDMS resources that is not administered or enforced with user exits.
  • A system that can interface with an external security system, such as CA Top Secret for z/OS or RACF®, for the protection of some CA IDMS resources.
Protection of resources external to CA IDMS is not a purpose of CA IDMS centralized security.
Security Domain
The CA IDMS security domain is the set of CA IDMS DC and UCF systems and local mode jobs that share a set of user definitions.
If you specify that CA IDMS user validation is to be performed by an external security system, the CA IDMS security is the corporate security domain. If user validation is performed by CA IDMS internal security, the CA IDMS security domain is the set of DC systems that share a user catalog, the repository of CA IDMS user definitions.
 For more information about CA IDMS user validation, see Signon Processing (CA IDMS).
Architecture
This section describes the features and architecture of CA IDMS centralized security.
 
Architectural Features
 
CA IDMS centralized security architecture includes the following features:
  • Full integration with CA IDMS software
  • Availability to system-supplied and user-written applications executing under the CA IDMS central version, in local mode, and through supported front-end software, such as CICS and TSO in the CA IDMS environment
  • Support for a distributed, client/server environment
  • Compatibility with the Command Facility tool that is used for CA IDMS data definition
  • ANSI-compliant security syntax where possible
 
Multi-layered Security Scheme
 
With application security for dictionary resources, this architecture offers multi-layered security for CA IDMS systems, as shown in the following illustration:
┌─────────────────────────────────────────────┐ │ │ │
Host access security
│ │ (CA ACF2 for z/OS, CA Top Secret │ │ for z/OS, ...) │ │ │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ │ │ │ │
CA IDMS centralized security
│ │ │ │ │ │ │ │ ┌─────────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │
Application security
│ │ │ │ │ │ (CAS, IDD, ADS, OLQ, ...) │ │ │ │ │ │ │ │ │ │ │ └─────────────────────────────┘ │ │ │ │ │ │ │ └─────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────┘
The SRTT
This section describes the Security Resource Type Table (SRTT).
 
Purpose of the SRTT
 
The Security Resource Type Table (SRTT) is a load module in which you store the following information that CA IDMS centralized security needs at runtime:
  • Each resource type to be secured.
  • The system that enforces security on the resource (internal or external).
  • For resources to be secured externally, information that the external security system needs to service a security check request on the resource.
 
Using the SRTT
 
At installation, CA IDMS provides the default RHDCSRTT module. By default, the security option for each resource that is defined by CA IDMS is set to 
OFF
 (no security), and SVCNUM is set to the SVC number specified in the installation parameters.
You modify the RHDCSRTT module with an assembly of the #SECRTT macro. The SRTT is loaded at system startup, and can be reloaded dynamically using the 
DCMT VARY NUCLEUS
 command for the RHDCSRTT module.
The scope of the SRTT is one or more CA IDMS systems, depending on your security scheme.
 
Security Options by Resource Type
 
For each resource type you can specify one of these security options in the SRTT:
  • EXTERNAL -- Security enforcement for the resource follows rules that are defined in the external security system.
  • INTERNAL -- Security enforcement for the resource follows rules that are defined to the CA IDMS internal security system.
  • OFF -- No security enforcement for the resource (the default at installation).
 
Generating the SRTT
 
The SRTT is created by issuing a sequence of #SECRTT macros.
The #SECRTT macro can specify one of four types of action:
  •  
    Initial
     -- Denotes the beginning of the SRTT assembly.
  •  
    Entry
     -- Specifies a security option for 
    all
     occurrences of a given resource type.
  •  
    Occurrence override
     -- Specifies a security option for one or more occurrences of a given resource type that overrides the entry specification for the resource type (not applicable to all resource types).
  •  
    Final
     -- Denotes the end of the SRTT assembly.
For detailed information about generating the SRTT, see How to Generate the SRTT.
 
Displaying the SRTT
 
The DCMT DISPLAY SRTT command displays the Security Resource Type Table (#SECRTT macro/RHDCSRTT load module). Use #CTABGEN code N116 to secure the command. For detailed information, see DCMT DISPLAY SRTT.
 
Recreating the SRTT via Batch
 
To display or recreate the SRTT table, use the batch program—IDMSSRTD. This program recreates the SRTT definition syntax from the existing load module. The z/OS JCL is used to execute the RHDCSRTT IDMSSRTD batch processor. The RHDCSRTT source syntax is decompiled from the load module and written to the SYSPCH Ddname.
 For detailed information about recreating the SRTT, see Recreate the Security Resource Type Table (SRTT).
 
Occurrence Overrides
 
For an individual occurrence of a database, task, or program, you can override the security option that you specify for the corresponding resource type, in the SRTT.
For example, you can omit an SRTT entry for the database resource type and create an occurrence override for database PROD specifying internal security. The result is that any checks on resources associated with database PROD are routed to internal security, while checks on resources associated with all other databases are not checked.
 The resource name that you give on an occurrence override is treated as a wildcard. In the previous example, all databases in the domain of the SRTT with names beginning 
PROD
 are secured internally.
 
Performance Consideration
 
You may gain a performance advantage by using an override to turn off security for occurrences of a secured resource type. Runtime security processing checks for an occurrence override in the SRTT before checking resource authorizations in the security database.
External Security Enforcement
 
External Security Specifications
 
In each SRTT entry that specifies external security, you define the format of the resource name that is routed to the external security system in a security check. At runtime, the central security interface uses this information to map the IDMS internal resource name to the external resource name before routing the request for a security check to the external system.
 
Standard Security Interface
 
CA IDMS centralized security uses the 
z/OS System Authorization Facility (SAF)
 as the interface to external security systems. On a security check, CA IDMS centralized security issues RACROUTE calls providing the names of resource type and resource occurrence being checked and the keyword that equates to the authority needed.
 
Security Definitions
 
If you plan to protect 
all
 CA IDMS resources with an external system, you do not need a user catalog. All required definitions would reside in the external security system. The one requirement within CA IDMS is to build the SRTT with external security specifications for all secured resources.
However, user definitions and user profile definitions are accessed during signon processing if they exist, regardless of how signon is secured. If all security checks are routed to the external system, you may want to use the user catalog. For more information about profiles in signon processing, see Securing User Profiles.
Internal Security Enforcement
 
CA IDMS Internal Security
 
When an entry for a resource type in the SRTT specifies internal security, only users and groups who are defined in the user catalog can be granted the permission to access the resource. You grant privileges with the appropriate GRANT statements.
 
CA IDMS Internal Security Administration
 
You can delegate internal security administration by granting to selected users:
  • Administration privileges
  • The permission to grant their privileges to other users
You perform CA IDMS internal security administration functions by issuing security authorization statements through the CA IDMS Command Facility. When you do this, CA IDMS does the following:
  • Accepts syntax that specifies the security administration request (for example, a CREATE USER statement).
  • Verifies that you, the issuer of the request, have the authority to issue the request.
  • Updates the data in the appropriate internal security repository.
Security Definitions
 
Required for Security Checks
 
When CA IDMS centralized security receives a request for a security check, it first determines from the SRTT whether the resource is secured. If it is, centralized security routes the request to CA IDMS internal security or the external security system, depending on the security option specified for the resource in the SRTT.
The resulting security check accesses security definitions of resources and resource authorizations to determine whether the executing user has the authority to access the resource in the way that is indicated on the security request.
 
Resource Definitions
 
Securable resources are the entities in the CA IDMS environment defined by CA IDMS or the user to which you control access.
Securable resources defined by CA IDMS are as follows:
  • User
  • Group
  • User profile
  • System
  • Signon
  • System profile
  • Application activity
  • Queue (1)
  • Access module (runtime) (1)
  • Load module (loadable entity) (1)
  • Program (load module) (1)
  • Task (1)
  • Database
  • Area (2)
  • Run unit (1) (2)
  • Access module (definition) (2)
  • Non-SQL schema (2)
  • SQL schema (2)
  • Table (2)
  • Database name table
  • DMCL
(1) Occurrences of this resource can be grouped in a category using the 
CREATE RESOURCE
 statement.
(2) This resource type is secured automatically when the database resource type is secured.
 
Authorization IDs
 
An authorization ID identifies a user or group who is authorized to access resources. You define authorization IDs to CA IDMS with the 
CREATE USER
 and 
CREATE GROUP
 statements.
If the security option for the resource is external, the authorization ID (and the authorities given to it) are defined in the external security system.
If the security option for the resource is internal, the authorization ID (and the privileges granted to it) are defined in the internal security system. 
 
Resource Authorization
 
An authority is the ability to access a resource in a particular way. A resource authorization is an authority that is associated with a resource definition and an authorization ID.
If the security option for a resource is external, resource authorizations are specified in the external security system.
If the security option for a resource is internal, resource authorizations are specified in the internal security system by 
granting privileges
. You give users the permission to access a resource with a GRANT statement, and you take away the permission with a REVOKE statement.
Runtime Security Processing
 
Security Checking
 
The CA IDMS centralized security facility handles all security checks issued during CA IDMS processing. Security requests are routed to the central security interface to provide uniform validation of requests.
 
Security Enforcement
 
The security option that is specified in the SRTT for the resource type or resource type occurrence determines how security is enforced.
 
Example:
 You can control the execution of tasks with the external security system, but, control access to a particular database with CA IDMS internal security.
If the security option for the resource being checked is external, the request is routed to the external security system. The external security system returns a value to the centralized security interface representing the result of the check.
If the security option for the resource being checked is internal, CA IDMS centralized security verifies that the user holds the required permission.
 
Centralized Security Diagram
 
This illustration shows the flow of processing in the CA IDMS centralized security system:
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ │ │ │ │ │ │ Security │ │ Command │ │ CA IDMS │ │ syntax ├─────────► facility ├──────────► security │ │ │ │ │ │ definition │ │ │ │ │ │ │ └──────────────────┘ └────────┬─────────┘ └────────┬─────────┘ │ │ │ │ │ ┌────────▼─────────┐ │ │ │ │ │ CA IDMS │ ┌────────▼─────────┐ │ internal │ ┌──────────────────┐ │ ├──────────► security │ │ │ │ │ │ │ │ CA IDMS │ │
Central
│ └──────────────────┘ │ component ├─────────►
security
│ │ │ │
interface
│ │ (IDD, DB, DC ...)│ │ │ ┌──────────────────┐ │ │ │ │ │ │ └──────────────────┘ │ ├──────────► External │ └──────────────────┘ │ security │ │ interface │ │ │ └──────────────────┘