Restricting ECLI Command Options for Users in WCC via EEM Policies

Products

• Autosys Workload Automation

Issue/Introduction

Users require granular control over ECLI (Embedded Command Line Interface) options within WCC, specifically to prevent access to general commands while still enabling functionality like exporting jobs and machines. The challenge lies in configuring EEM policies to achieve this fine-grained access without completely disabling the ECLI, and understanding the limitations of such configurations.

 

 

Environment

• Product: WCC (Workload Control Center)
• Component: ECLI (Embedded Command Line Interface)
• Authentication/Authorization: EEM (Embedded Entitlements Manager)
• Integrated Products: AutoSys (as defined to WCC)

Resolution

To limit the ECLI options available to users in WCC, configure the CommandExecute EEM policy for the WCC00004 application. Instead of using a broad resource definition like server/*, make the resource more specific to allow only desired commands.

1. Understand the CommandExecute Policy:

   • The CommandExecute policy in EEM controls which ECLI commands users are permitted to execute on specific AutoSys instances.

2. Configure Specific Resource Paths:

   • To allow only autorep commands (e.g., for exporting jobs):
     Set the CommandExecute resource to:
     server/DEV_INS/autorep*
     Note: DEV_INS should be replaced with the actual name of your AutoSys server instance as defined in WCC (visible in the ECLI "Servers" section).
     This configuration restricts users to only being able to issue autorep commands via the ECLI, which is the command used for job export functionality.

   • To allow export/import of jobs, machines, connection profiles, resources, and calendars:
     You will need to define multiple specific resources within the CommandExecute policy. For example:
     server/DEV_INS/jil*
server/DEV_INS/autorep*
server/DEV_INS/autocal_asc*
     Note: Again, replace DEV_INS with your specific AutoSys server instance name.

3. Important Considerations and Limitations:

   • Even with these specific resource configurations, users will still see and be able to type commands into the "Input -> command" section of the ECLI tab.
   • Currently, there is no direct method within WCC to hide or disable the "Input" command line area while still allowing access to the Import/Export functionalities that rely on these underlying commands. The policies control execution rights, not UI visibility.

4. Verifying Policy Effectiveness:

   • All command attempts made by users through the ECLI are logged in the EEM audit log, typically located at $EIAM_HOME/logs/audit.log.
   • You can review this log to confirm if commands are being allowed or rejected according to your policy configurations.

 

Rejected Command 

<Event>
<Taxonomy>IAM.Runtime.authorizeWithSession.F.I</Taxonomy>
<Src>WCC0004</Src>
<Identity>ejmoperator</Identity>
<Method>authorizeWithSession</Method>
<Resource>Execute/CommandExecute/server/DEV_INS/autofakecommand -x</Resource>
<Error>18</Error>
<ErrorCode>EE_NOTALLOWED</ErrorCode>
<Attr>component</Attr>
<AttrVal>CommandLine</AttrVal>
<Attr>serverName</Attr>
<AttrVal>DEV_INS</AttrVal>
<Attr>command</Attr>
<AttrVal>autofakecommand -x</AttrVal>

The ejmoperator user attempted to run autofakecommand -x, which was rejected (Error 18, EE_NOTALLOWED).

 

Allowed Command:

<Event>
<Taxonomy>IAM.Runtime.authorizeWithSession.S.I</Taxonomy>
<Src>WCC0004</Src>
<Identity>ejmcommander</Identity>
<Method>authorizeWithSession</Method>
<Resource>Execute/CommandExecute/server/DEV_INS/autorep -M myhost</Resource>
<Error>0</Error>
<ErrorCode>EE_SUCCESS</ErrorCode>
<PolicyName>CommandExecuteDefault</PolicyName>
<Attr>component</Attr>
<AttrVal>CommandLine</AttrVal>
<Attr>serverName</Attr>
<AttrVal>DEV_INS</AttrVal>
<Attr>command</Attr>
<AttrVal>autorep -M myhost</AttrVal>

The ejmcommander user successfully ran autorep -M myhost (Error 0, EE_SUCCESS).