Role-Based Security with eEM

You can use CA Embedded Entitlements Manager (eEM) to control AAI authentication and data access. To do this, you need to prepare eEM and then add an eEM user domain in AAI that you can use for user authentication and data access control. This topic guides you through all the steps for preparing and configuring eEM for AAI, and describes all the options available for the communication from eEM to AAI.

This topic includes the following:

Securing the eEM to AAI Communication with TLS

eem with tls, securing eem, encrypted communication from eem

You can secure the communication between eEM and AAI over a TLS protocol. This is optional, although generally recommended and is often needed to fulfill your company security policies. If you do not want to use encrypted communication, you can continue with defining AAI in the eEM application. For information, see Adding AAI and Its Access Policy Classes to eEM.

Securing the eEM communication to AAI with TLS requires steps in eEM and in AAI, as described in the following sections.

Note:

TLS communication from eEM to AAI is handled by the eEM SDK and the configuration in the igateway.conf file on the eEM server and is defined as part of enabling TLS on the eEM server.

1. Preparing and Configuring eEM for TLS Communication

Use the following steps to enable a secure communication between eEM and AAI as well as between eEM and LDAP with TLS..

  1. On the eEM server, provide a TLS certificate on the server.

    For information, go to the documentation for Embedded Entitlements Manager on https://techdocs.broadcom.com/us/en/ca-enterprise-software/other.html. Then search for "SSL TLS" to find the topic on configuring SSL communication between eEM and LDAP. Follow the guidelines and instructions for providing and configuring certificates.

    Make sure, when you specify the Protocol, to select either LDAP + TLS or LDAPS.

  2. On the eEM server, enable TLS v1.2 on port 5250. This is the port that communication with AAI requires.

    For more information and steps, see the Broadcom Knowledge Base article "How do I enable TLSv1.2 on ports 509, 5250 and 8443 and specify a cipherlist?" with the Article ID 74517.

  3. Enable TLS on the eEM server. Use the following steps:

    1. Log in to the CA EEM Server.

    2. In a text editor, open the igateway.conf file that is in C:\Program Files\CA\SC\iTechnology .

    3. In the <secureProtocol> section, add the following tag:

      <secureProtocol>TLSV1_2</secureProtocol>

    4. Restart the CA EEM services.

After you finish these steps, ensure that AAI can trust the eEM certificate. For information, see 2. Preparing AAI for Secure Communication with eEM with TLS.

2. Preparing AAI for Secure Communication with eEM with TLS

Generally, if eEM is correctly configured for TLS communication with AAI, as described in the step 1 in 1. Preparing and Configuring eEM for TLS Communication, you do not need to take any additional steps on the AAI server or in AAI for communication between the two products to be securely encrypted. However, if the certificate used on the eEM server is not signed by a public/trusted CA (certificate authority), you might need to import that certificate into the keystore on the AAI server.

To add the appropriate certificate for the eEM server to the AAI server, use the following steps:

  1. Export the certificate to a certificate file, for example domain1.cer. The certificate admin should know how to do this.

    For a Windows 2003 server with Certification services installed, do the following:

    1. From Administrative Tools select Certification Authority.

      In the Certification Authority (CA) interface, expand the Certificate menu on left side.

      Go to Issued Certificates. Right click the LDAP server certificate and go to All Tasks > Export Binary Data...

    2. Select Save Binary Data to file and give it a file name like domain1.cer.

  2. Copy this binary data file to the AAI server.

  3. From the command line on the AAI server, run the following command:

    keytool -import -v -file domain1.cer -keystore <PATH TO STORE>/jawsKeys -storepass <PASS- WORD> -noprompt

    This will create a file called jawsKeys under the specified path.

  4. Modify the .vmoptions file and add the following two lines:

    -Djavax.net.ssl.trustStore=<PATH TO STORE>/jawsKeys
-Djavax.net.ssl.trustStorePassword=<PASSWORD>

  5. Restart JBoss.

Adding AAI and Its Access Policy Classes to eEM

To be able to use eEM to control AAI user access to data in your schedulers, you must do the following in your eEM installation:

  1. Add the AAI application to the eEM installation.

  2. Add the AAI access policy classes to eEM, as described in the steps that follow.

Please note that if you want to have the communication from eEM to AAI securely encrypted with TLS—which is optional—complete the steps to prepare and configure that before continuing to set up AAI in the eEM application. For information, see Securing the eEM to AAI Communication with TLS.

To add AAI access policy classes to eEM

  1. Go to your AAI installation, and locate the file <Automation Analytics & Intelligence Installation>\scripts\eEM\JAWSCreate.xml

  2. Copy the file to any place on your eEM server.  

    Note:

    eEM can be installed on the same server as AAI or a different one.

  3. Add the AAI access policy classes and default policy settings to eEM

    To do this, from your eEM installation folder, run the following command either from your command line interface or from within a script:

    safex –u <username> –p <password> –f JAWSCreate.xml.

    Where the username and password are those of the eEM admin user.

Now you can use eEM to grant specific users access to AAI objects in the policy classes as you want. For a list of the access policies with links to details about them, see The AAI Access Policy Classes for eEM.

The AAI Access Policy Classes for eEM

After you have added AAI and its access policies to eEM as described in Adding AAI and Its Access Policy Classes to eEM, use the details in the following topics to learn about each access policy and its options:

AutoSys Versions Supported for eEM

All AutoSys versions will be supported using eEM; however, versions earlier than R11 will require additional setup. AutoSys R11 comes bundled with eEM and an eEM application is already created. This is the application that will be used for policy checking within AAI. If there is a mixture of R11 and pre-R11 instances in a particular environment, the AutoSys policies within the eEM application can be extended to include the pre-R11 instances. These policies will be honored within AAI, but will not be honored by the pre-R11 instances of AutoSys. Similarly, if all the instances in an environment are pre-R11, it is possible to create an AutoSys application and define an as-job resource class similar to the AutoSys resource class.

Tips for eEM When Upgrading to AAI 6.4.4 or Higher

When you upgrade an AAI installation to release 6.4.4 or higher from any prior release, consider using these steps to update the application name for AAI in eEM from its previous name "JAWS" to "AAI" so that it is easily identifiable in eEM.

Once you have done this for a release version 6.4.4 or higher, the changes are kept for future upgrades so you do not need to do it again for subsequent releases.

Important!

Please note, that if you do these steps, you will end up deleting all your custom access policies in eEM for AutoSys to AAI. At the end, only the default access policies will be applied.
The advantage of doing these steps is purely cosmetic, that is, you will see "AAI" rather than "JAWS" as the Application Name in eEM and in AAI domain definitions. For information, see Configuring the eEM Domain.

If you have a lot of custom access policies defined for AutoSys in eEM, you might prefer to continue to see JAWS as an application name rather than redefine custom access policies.

Important!

You must start this procedure before upgrading to AAI 6.4.4 or higher!

If you are upgrading to a higher release and have done this in a previous release, you do not need to repeat the procedure. The changes from before will be kept in future upgrades.

  1. In eEM, unregister the JAWS application.  
  2. Either from the command line interface or from within a script on the eEM server, go to the eEM installation folder and run the following command to delete the JAWS objects from eEM:

    safex -f JAWSDestroy.xml.

  3. On the AAI server, upgrade to AAI to release 6.4.4 or higher.  
  4. Register AAI in eEM and add the AAI access policy classes and default policy settings to eEM.
    1. Go to your upgraded AAI installation, and locate the file <Automation Analytics & Intelligence Installation>\scripts\eEM\JAWSCreate.xml
    2. Copy the file to your eEM installation.  
    3. Add the AAI access policy classes and default policy settings to eEM.  

      To do this, from your eEM installation folder, run the following command either from your command line interface or from within a script:

      safex – u <username> –p <password> –f JAWSCreate.xml.

      Where the username and password are those of the eEM admin user.

  5. Use eEM to grant specific users access to AAI objects in the policy classes as you want.

See Also