Configure A2A Authorization Mappings

To ensure target credential security,
must authorize requestors to retrieve the target credentials. Authorization mappings associate requestors and request servers with a target alias or a target group.
To ensure target credential security,
must authorize requestors to retrieve the target credentials. Authorization mappings associate requestors and request servers with a target alias or a target group.
This following information is described in this topic:
Mapping A2A Requestors to Targets
Before a requestor can obtain credentials for a target, you must define an A2A mapping. A mapping links requestors to targets. 
You can configure authorization mappings for the following registered components:
  • A requestor (script) and a target alias
  • A request server and a target alias
  • A request group and a target alias
  • A requestor (script) and a target group
  • A request server and a target group
  • A request group and a target group
A mapping to a target group includes all aliases for all accounts in the group. A mapping from a request server can include all applications (scripts) on the server or you can restrict the mapping to a specific script. A mapping from a request group includes all applications (scripts) in the group.
A requestor is defined by several attributes, not all of which are necessarily used by a mapping. A mapping can use the following attributes to identify a requestor:
  • Request server (required)
    : The host name or IP address and associated descriptors. A mapping must specify a single request server or a request group
  • Application or script name
    : The name of the program or script (for example, myProgram.exe)
  • Application or script execution path
    : The path to the program on the request server
  • Application or script file path
    : The path that invokes the program (for example, ./)
  • Execution user id
    : The user ID that executes the program
  • Application or script hash
    : A hash of the requesting program or script. This value can ensure that the program or script is not modified
A mapping must specify a request server. The other attributes are optional. If a mapping uses only a request server (or a request server group; not programs), any program on the request server can access account passwords. The program can be executed by any user. To restrict access to specific programs or users, you can configure a mapping and a script for each request server.
Specifying Requestors in a Mapping
Mappings can specify requestors as follows:
  • Request group. A request group is a collection of requestors. The group identifies a collection of request servers and request scripts.
  • All requesting programs on a request server
  • A specific registered Request Script
Also, you can restrict each mapping to apply only when the requesting program is run as a user ID in a specific list of Execution User IDs. The mapping can specify that the execution, file path, and hash be verified. This condition implies that the requesting program has an associated registered Request Script.
Request Group
If a requestor group includes a Request Server but not any Request Scripts, it implicitly includes all request programs on those request servers. If a request group specifies only request scripts, it implicitly allows them from any request server. Static request groups can only reference request servers or registered request scripts. Dynamic request groups can also reference unregistered request scripts (based on their name, file path, or execution path).
Large organizations find that dynamic request groups can scale easily.
All Requesting Programs on a Request Server
A mapping can also be made to allow any requesting program on a given request server. This method does not permit any checking of the requesting program. However, as with all mappings the user ID the program is running under can be checked.
This method is useful when A2A is first deployed because it eliminates authorization as a failure reason. This feature can make it easier to develop of A2A programs.
Registered Request Script
Registered Request Scripts are always associated with a specific request server. A Request Script specifies the Request Server that it runs on, its name, and an execution path.
This method gives great control but requires the creation of many mappings. This method is not as scalable as using a Request Group.
Request Validations
For each mapping, request validations are done. The following table shows the scope of the validations:
Request server
Validated for every application
Application name
Validated for every application
Application location
Validated only if file path is checked.
Application hash (script integrity)
Validated only if script integrity validation is checked.
Execution user ID
Validated only if execution user ID is checked.
Execution path
Validated only if execution path is checked.
Add an Authorization Mapping
Before you add an authorization mapping, add the target alias or group, request server or request server group. If necessary, also add any request script for a request group mapping. If there is no verification of the script, such as integrity verification or execution path, a request script is not required.
Guidelines for Mapping Script Groups
When you create a dynamic requestor script group, the group contains all scripts in the path that satisfy the filter criteria. The group includes scripts that are defined in the
database and scripts that are not.
When you map a script group that is created with filters, be aware how you set the
Check Execution Path
Check File Path
  • If you select one or both checkboxes, the authorization mapping is restricted to only those scripts that are in the database. Any scripts that are not in the database are excluded from the authorization mapping. 
  • If you clear the checkboxes, all scripts in the group are included in the authorization mapping.
Add a Mapping Using the UI
Follow these steps:
  1. Select
    Manage A2A
    The Authorization Mappings page displays with a list of existing authorizations.
  2. Select
  3. For the 
    setting, select
  4. Enter the target group or alias name or search for a target group or alias using the magnifying glass.
  5. For the 
    setting, select
  6. Enter the requestor group or client name or search for an A2A requestor group or client using the magnifying glass.
  7. For the 
    setting, select whether the mapping applies to
    applications (scripts) on the request server or an
    application (script). For an individual script, enter the script name or search for the script. For A2A requestor groups, the mapping applies to all scripts.
  8. Set the
    Check Execution User
  9. Enter one or more
    Execution User
    IDs. Separate multiple user IDs with commas.
  10. To restrict the authorization to provisioned scripts only, set one of both of the following settings:
    • Check Execution
    • Check File Path
  11. Set the
    Perform Script Integrity Validation
    option. If you cannot select this validation option, no valid script hash is available. Complete the following steps:
    1. Add the authorization mapping without selecting the validation option.
    2. Run a query from the requestor.
    3. Update the mapping and select this validation option.
  12. Select
    to save the mapping.
Add a Mapping Using the CLI
Using the CLI, follow these steps
  1. Add an authorization mapping by entering the following command:
    capam_command adminUserID=admin cmdName=addAuthorization RequestScript.executionPath=/opt/cloakware/cspmclient_v.3.3.0/examples Authorization.checkExecutionID=true Authorization.executionUser=root Authorization.checkPath=true Authorization.checkScriptHash=true
  2. Enter your password at the prompt. Credential Manager returns the following XML command string.
    <CommandResult> <cr.itemNumber>0</cr.itemNumber> <cr.statusCode>400</cr.statusCode> <cr.statusDescription>Success</cr.statusDescription> <cr.result> <Authorization> <ID>1</ID> <createDate>Mon Nov 12 15:51:06 EST 2007</createDate> <updateDate>Mon Nov 12 15:51:06 EST 2007</updateDate> <createUser>admin</createUser> <updateUser>admin</updateUser> <hash>XOPh+2zvQDphQ0M4LPzLfyTPoiw=</hash> <executionUser>root</executionUser> <targetAliasID>1</targetAliasID> <scriptID>1</scriptID> <requestServerID>1</requestServerID> <checkPath>false</checkPath> <checkExecutionUser>true</checkExecutionUser> <checkScriptHash>false</checkScriptHash> <checkFilePath>false</checkFilePath> </Authorization> </cr.result> </CommandResult>