ESF Passtokens

Passtokens are an optional ESF feature for communicating a user's identity between security domains. Passtokens let one ES component (an ES region or MFDS) sign on to another ES component on behalf of a user, without requiring that user's normal credentials (typically a password).

In effect, a passtoken is a one-time or limited-time substitute for a user's password. A passtoken is associated with a user (and signon group) when it is created, and can only be used to sign on as that user.

If passtokens are enabled, they may be used for these purposes:

• Administrator convenience. When an administrator is signed on to either the MFDS administrative user interface or ESMAC, and switches to the other, the component that the administrator is coming from will send a passtoken to the component the administrator is going to. If the destination accepts the passtoken and the administrator has authority there, no manual signon will be necessary and the administrator can switch seamlessly between the two interfaces.

• Inter-system communication. Some MTO facilities allow users with the appropriate rights to invoke functions or programs in other regions. In some cases these facilities can use passtokens rather than actual passwords, to avoid insecure storage and transmission of passwords.

Not all ESM Modules support passtokens. If you are using a module that does not to verify users, then user identities will not be automatically transferred across security domains, and users will have to explicitly sign on with their normal credentials in each domain.

Access to Passtokens

Because passtokens bypass the normal security mechanism that establishes a user's identity, they can pose a security risk if an unprivileged user is allowed to create passtokens for other users.

Consequently, ESF Manager can be configured to disallow the generation or use of passtokens, or both; this affects any security domain (ES server / region, or MFDS) using that security configuration. Also, ESM Modules that implement passtokens will often provide additional controls. For example, the MLDAP ESM Module lets you specify for each user whether that user can generate passtokens for itself, for any user, or not at all; and whether that user can be signed on using a passtoken.

Passtoken Options for ESF Manager

Passtoken options for ESF Manager are currently set by editing the text in the Configuration Information area in the "Security Manager" definition in MFDS. Text in this area is organized into sections which begin with a "tag" in square brackets, followed by lines in the form of name=value.

You can restrict the use of passtokens in any ES component that uses a particular Security Manager configuration by setting the following in that area:

   [Passtoken]
   allow=option

where option is one of none (disable passtokens), generate (allow passtoken generation but not use), signon (allow passtoken use for signon but not generation), both (allow both generation and signon), or yes (synonym for both).

Allowing only generation may be useful for a region that makes ISC requests to another region but does not receive them, and conversely allowing only signon may be useful for a region that receives remote requests but never makes them.

Passtoken Options for the MLDAP ESM Module

The MLDAP ESM Module lets you specify passtoken-related rights for each user, by setting attributes in the user objects in the LDAP repository. It also provides some configuration options for its passtoken implementation.

ESM Module Configuration

The ESM Module can be configured in MFDS; see MLDAP ESM Module configuration for more information. You can set values in the optional [Passtoken] section of the "Custom Configuration" area to set some options for passtoken processing.

In that section, there are two settings you can use to change the secret key for the MAC verifier used in the passtokens the MLDAP ESM Module generates. You can set the key directly in the MFDS configuration with the Secret keyword, or point the ESM Module to a file containing the secret key with the SecretFile keyword.

Note that passtokens generated by the MLDAP ESM Module in one security domain will only be verifiable by another instance of the module in another domain if both are configured with the same secret key.

You can also use the Duration keyword in that section to control how long passtokens remain valid after they are generated. (The default is one minute.) This should be long enough for the sending component to get the token to the receiving component, taking network delays into account, and for the receiving component to perform its Verify request; but making it too long gives an attacker more time to capture and replay a token, especially if it is being sent over an unsecured channel.

See MLDAP ESM Module Custom Configuration Information for more information.

LDAP Attributes

There are two attributes of the LDAP microfocus-MFDS-User class which control access to passtokens:

microfocus-MFDS-User-CreateToken

This controls the user's ability to create passtokens. It can have the following values:

• self: The user can create normal passtokens (good only for that user).
• any: The user can create surrogate passtokens for other users.
• Any other value (and the default): The user cannot create passtokens.

microfocus-MFDS-User-UseToken

This allows a user to be signed on using a passtoken. It can have the following values:

• self: The user can be signed in with a normal passtoken, but not a surrogate passtoken.
• any: The user can be signed in with a normal or surrogate passtoken.
• Any other value (and the default): The user cannot be signed in using a passtoken.

Typical Passtoken Configurations

The appropriate passtoken configuration depends on the needs of your installation, its security requirements, and administrator convenience. Here are some example passtoken configurations for typical installations.

No Passtokens

The most secure option is to disable passtokens entirely. That means users will always have to sign on explicitly when entering security domains. Administrators will have to log on to MFDS and ESMAC separately, and user identity will not be automatically transferred over Inter-System Communication (ISC) links between ES regions, for purposes such as CICS Transaction Routing.

However, there is no danger of passtokens being abused in this configuration.

Disable passtokens in the ESF Manager configuration in each "Security Manager" object in the MFDS repository, using the MFDS administration GUI. See Passtoken Options for ESF Manager.

Passtokens for MFDS and ESMAC

Many administrators will find it convenient to enable passtokens for the MFDS and ESMAC administrative interfaces, especially since those two facilities provide links to each other, which makes it easy to switch between them. Because ESMAC runs as part of CAS within an ES region, but MFDS is separate from any ES region, they are in different security domains, despite those links; so without passtokens, the administrator has to log into each separately. With passtokens, an administrator can connect to MFDS or ESMAC, log in once, and then go between the two without losing access or having to log in again.

MFDS and ESMAC always use normal passtokens, so this feature can be enabled without enabling the more powerful (and riskier) surrogate tokens.

To enable passtokens for MFDS and ESMAC, do not disable passtoken support in your ESF Manager configuration (the "Custom Configuration" section of the "Security Manager") for MFDS or any ES region where you want this facility. Passtoken support is enabled in ESF Manager by default.

Also, you may have to perform ESM-specific actions to enable normal passtoken generation and signon for your administrative users. With the MLDAP ESM Module, for each administrative user who should be able to switch between ESMAC and MFDS transparently, set the following attributes in the LDAP repository:

• microfocus-MFDS-User-CreateToken to self
• microfocus-MFDS-User-UseToken to self

Note that you do not need to do this for system users (such as SYSAD) unless you use them as administrator IDs. You only need to do it for user accounts that your administrators actually sign into MFDS or ESMAC with.

Note also that in its default configuration, MFDS does not require you to sign in. If you are not signed in, no passtoken will be generated when you switch to ESMAC. To use passtokens between MFDS and ESMAC, make sure you configure MFDS to require an administrative signon.

Passtokens for ISC

Customers who use the MTO Inter-System Communication (ISC) facility for CICS features such as Transaction Routing and Function Shipping between two ES regions may want to enable passtokens for that purpose. That lets the two CICS regions apply the same security context to all the operations performed by an application, even when they cross security domains.

Note that passtokens are not supported for ISC conversations with non-ES regions, such as MFE or mainframe CICS.

ISC passtokens are surrogate passtokens generated automatically by the system as necessary. They are always generated by the region's system user, which is the user account used to start the region.

To enable ISC passtokens, do not disable passtoken support in your ESF Manager configuration (the "Custom Configuration" section of the "Security Manager") for MFDS or any ES region where you want this facility. Passtoken support is enabled in ESF Manager by default.

Also, you may have to perform ESM-specific actions to enable:

• Surrogate passtoken generation by any user account used to start a region that will be making ISC requests to another ES region
• Surrogate passtoken signon for any user account that will run a transaction that will cause an ISC request (eg by starting a transaction in another region)

For the MLDAP ESM Module, that entails:

• For all user accounts used to start the region, set the LDAP user attribute microfocus-MFDS-User-CreateToken to any
• For all user accounts that will run CICS transactions that may cause an ISC request, set the LDAP user attribute microfocus-MFDS-User-UseToken to any

If the regions use different LDAP repositories, note that the system user account (the one generating the token) belongs to the region that initiates the request, and the regular user account (which is signed on using the token) belongs to the region that processes the request.

Passtoken Design Considerations

Functional Requirements

• Allow a verified user in one security domain to perform an automatic signon in another domain. That signon can fail if the target domain refuses to verify the user.
• Avoid creating a security hole that would allow users to bypass the normal signon mechanism.

Design Considerations

• The passtoken contents and passtoken processing (generation and verification) is left to the ESM Module (and its associated ESM) that generates and consumes a given passtoken.
• Passtoken operations fail gracefully if they are disabled, or an ESM Module used by one of the security domains does not support passtokens.
• Passtokens should be hard to forge or replay.
• It should be difficult or impossible to derive sensitive information (such as passwords) from passtokens. This requirement is flexible, if passtokens themselves are mostly exposed only on the wire, because it's likely that users will either be using SSL or exposing passwords on the wire, which is a greater security risk.
• A given passtoken is specific to a user and signon group.
• Passtokens should be single-use or short-lived. The mechanism for achieving that is left to the ESM Module.

Using Passtokens

In this version of ESF, there are no facilities for manually using or administering passtokens, aside from the access controls described above. Passtokens are used automatically by certain ES facilities where appropriate.

Customers interested in using passtokens in their own applications should contact Micro Focus to discuss possible product enhancements and early-adopter programs.

Passtoken API

The passtoken API is not documented for customer use in this release. Customers interested in using passtokens in their own applications should contact Micro Focus to discuss possible product enhancements and early-adopter programs.