FAQ

 This topic lists frequently asked questions.

What are the main components of the EC for Okta product?
  • BMC RACF postprocessing exit ICHRIX02
    You must place this exit in the modifiable link pack area (MLPA). When RACF starts, it obtains the ICHRIX02 entry point in the MLPA and calls it after validating the user ID and password. The BMC ICHRIX02 exit then invokes the ICHRIX02 dynamic exit routines.
  • BMC RACF postprocessing dynamic exit RSORIXEX
    This exit passes any authentication requests to the appropriate EC for Okta server.
  • EC for Okta server
    This is the address space that sends an HTTP requests to the Okta gateway and processes the responses. The Okta gateway pushes the authentication request to the target mobile device and returns a user response to the EC for Okta server.
How can I specify different configuration control settings?

This table displays two different levels of settings for the multifactor authentication identifier (MFAID), the password fallback (PWFB), and the SMF number:

Universal settings

These are hard-coded settings that are not modifiable:

  • BMCMFAID(*NONE*)—Specify to disable multifactor authentication.
  • BMCPWFB(YES)—Specify to allow access using only RACF user ID and password validation.
  • BMCMFASS(*)—Specify to allow any active subsystem to process the authentication request.
  • SMFNBR(0)—Specify to disable generating SMF data.

These settings allow the user full access to the system when the BMC RACF postprocessing dynamic exit (RSORIXEX) is not present. A valid RACF user ID and password are sufficient for granting access.

Individual settings

These are settings for individual RACF user IDs or groups.

You can define the following custom fields:

  • BMCMFAID
  • BMCPWFB
  • BMCMFASS

The RACF group is checked for custom data values and the RACF user ID. Individual RACF user ID custom data field values override any RACF group custom data field values.

Each level of settings overrides the next level. For example:

  • RACF user ID custom data values override RACF group custom data values and the universal settings.
  • RACF group custom data values override universal settings.
When does password fallback authorization checking occur?

Password fallback authorization checking is used only when EC for Okta cannot connect to the Okta gateway. For example:

  • The connection request fails (TCP/IP error). This does not include HTTP request errors. An HTTP request failure indicates that we were able to connect to the Okta gateway, but the request was rejected because of some HTTP request header or body processing error.
  • The BMC RACF postprocessing dynamic exit (RSORIXEX) cannot find a suitable EC for Okta server running on the LPAR.
  • A processing failure occurs to the BMC RSORIXEX (for example, an abend).
How can I disable the authentication validation?

To stop the authentication validation, stop the EC for Okta server, disable the BMC RACF post processing dynamic exit (RSORIXEX), and issue the following console commands:

P ssid

SETPROG EXIT,DELETE,EX=BMCICHRIX02DYNEX,MOD=RSORIXEX,FORCE=YES

The first line stops the EC for Okta server, and the second line prevents the RSORIXEX from passing any requests to the EC for Okta server and disables it from future runs when the EC for Okta server is inadvertently restarted.

To re-enable the authentication processing, restart the EC for Okta server and reactivate the RSORIXEX:

S server_jobname

SETPROG EXIT,ADD,EX=BMCICHRIX02DYNEX,MOD=RSORIXEX,STATE=ACTIVE,
DELETEFORCE=YES,DSN=ecoktahlq.RSOLINK

 

What happens if the EC for Okta server doesn't start?

The BMC RACF postprocessing dynamic exit RSORIXEX makes the authorization decision. It uses the hard-coded universal settings and overlays them with any group or user ID custom field data (BMCMFAID and BMCPWFB) to set the authentication values.

An MFAID value that resolves to “*NONE*” results in access being granted. Any MFAID value that resolves to anything other than “*NONE*” relies on the password fallback setting. A PWFB value that resolves to YES results in access being granted. A PWFB value that resolves to NO results in access being denied.

Warning

An MFAID value that resolves to “*NONE*” always results in access being granted, regardless of whether the EC for Okta server is started.

What is the easiest way to track the authentication request processing?

All the authentication requests and their responses are logged in the JES RSOLOG output data set. Use the following messages to track the authentication requests:

  • Message RSO0990I—Authentication request received. 
    This documents authentication requests that have been received from the
    BMC RACF post ​​​​​processing dynamic exit (RSORIXEX).
  • Message RSO0998I—Access has been denied. This message contains the reason for the denial.
  • Message RSO0999I—Access has been granted. This message contains the reason for the approval.
Can I dynamically enable the RACF postprocessing exit ICHRIX02?

No. This routine must be in the link-pack area (LPA) before you start RACF. RACF obtains the ICHRIX02 address in the LPA and saves it for processing after the user ID and password have been validated.

We recommend that you implement the SYS1.PARMLIB changes (IEFSSNxx, IEALPAxx and PROGxx), followed by an IPL. After JES starts, immediately start the EC for Okta server. This ensures that even early access to the LPAR can be authenticated if necessary.

Can I connect to multiple Okta gateways?

Yes, by starting multiple EC for Okta servers. Each EC for Okta server must have its own unique subsystem ID (ssid) with any unique RSOPARM command parameters. Configuring those parameters, you can target alternative Okta gateways or alternative Okta workflows within the same Okta gateway.

You can assign different RACF user IDs and groups to different EC for Okta servers by specifying a BMCMFASS custom field value. By default, the value of this custom field is an asterisk (*). You can use any active EC for Okta server for authentication request processing.

If you have multiple EC for Okta servers running on a single LPAR, you can control the targeting of individual RACF user IDs or groups by specifying a BMCMFASS (ssid) custom field.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*