CA Identity Portal
Resources – shared logos, background, user pictures, and language files
Plugins – custom java-based server-side plugins
dxrepo - Deployment Xpress repository
To get the latest repository, see Download the Deployment Xpress Templates Repository.
CA Identity Manager

Create a custom .jar file for role definitions using
RoleDefinitionGenerator
.
cd /opt/CA/IdentityManager/IAM_Suite/IdentityManager/tools/RoleDefinitionGenerator/bin/
./RoleDefGenerator.sh -h localhost -u etaadmin "<Custom Jar File>"
Provide permission to the <Custom Jar File> created in step 1.
chmod 777 <Custom Jar File>
Copy <Custom Jar File> to /opt/CA/VirtualAppliance/custom/IdentityManager/iam_im.ear_user_console.war_WEB-INF_lib/.
Restart CA Identity Manager server.

/opt/CA/VirtualAppliance/custom/IdentityManager
/opt/CA/VirtualAppliance/custom/IdentityPortal
/opt/CA/VirtualAppliance/custom/IdentityGovernance
/opt/CA/VirtualAppliance/custom/apache-ssl-certificates

Upload or create the custom file on

one node

.

Open a CLI or SSH terminal on the same node.

Change to the directory where the files were created or uploaded.

Run the following script to synchronize the custom files with other nodes. This performs a “push” replication from the current node to other nodes.

vapp_sync

/opt/CA/VirtualAppliance/custom/apache-ssl-certificates 

localhost.crt (public key)
localhost.key (private key)

Ensure that you back up the certificates before replacing them.
After replacing the certificates, run the following command to reload the web server on every server on which the certificates were replaced. The server starts with the replaced certificates:
sudo /etc/init.d/httpd reload
If the certificate pair is missing/invalid, an error message is displayed on the console.

mount -t cifs -ocreds=/home/config/creds.txt,noserverino,dir_mode=0777,file_mode=0777 //132.70.100.10/temp /home/config/temp

/opt/CA/VirtualAppliance/custom/mounts

Edit the following file:
/opt/CA/VirtualAppliance/custom/mounts
Define any mount points, for example:
[Device]                [Mount Point]                           [File System Type]      [Options]
10.20.3.2:/public       /home/config/my-nfs-mount-point         nfs
//10.20.3.1/some-share  /home/config/my-cifs-mount-point        cifs                    username=my-user,password=my-pass
Note:
Run
MountNetworkShares -h
to view the syntax that is used in the configuration file.
Save the file and exit.
Run the
MountNetworkShares
command
again to perform immediate mounting.
The command writes a detailed output to the console regarding each mount operation performed.

-Xms512m -Xmx2048m -XX:+UseG1GC -XX:+UseStringDeduplication -XX:+UseCompressedOops -Djava.net.preferIPv4Stack=true -Djava.awt.headless=true -XX:+UseLargePages -Djava.security.egd=file:/dev/./urandom

Log in to the target server via SSH/CLI as the default Virtual Appliance
(config/ec2-user) user.
Edit the
jvm-args.conf
file for the relevant product:
/opt/CA/VirtualAppliance/custom/IdentityManager/jvm-args.conf
/opt/CA/VirtualAppliance/custom/IdentityGovernance/jvm-args.conf
/opt/CA/VirtualAppliance/custom/IdentityPortal/jvm-args.conf
Uncomment the following line, or duplicate it and uncomment the copied line:
From:
#JAVA_OPTS=...
To:
JAVA_OPTS=...
Make the necessary changes to the JVM arguments specified after the "=" character.
Save the file.
Restart the application server by running the corresponding alias for the product:
restart_im
restart_ig
restart_ip

Log in the Virtual Appliance server using SSH/CLI

Create or edit the following file:

/opt/CA/VirtualAppliance/custom/hosts

Add the custom host records in a format equivalent to the /etc/hosts format, for example:

192.168.1.54 myhost01
192.168.1.58 myhost02
192.168.1.160 myhost03

Run the following command:

configureCustomHostRecords

View the /etc/hosts file and notice that the following block was added/modified to reflect the custom hosts block:

# CA VAPP CUSTOM HOSTS - START
192.168.1.54 myhost01
192.168.1.58 myhost02
192.168.1.160 myhost03
# CA VAPP CUSTOM HOSTS - END

Navigate to the following location:
cd /opt/CA/VirtualAppliance/custom/IdentityManager/branding/
Create your own skin. This is typically done by copying an existing template skin directory from
iam_im.ear/user_console.war/app/<SKIN_NAME>
and modifying the contents.
For example, the steps to copy the "
ui7
" skin to a custom skin named "
my-custom-skin
" are as follows:
mkdir my-custom-skin
cp -rp /opt/CA/wildfly-idm/standalone/deployments/iam_im.ear/user_console.war/app/ui7 /opt/CA/VirtualAppliance/custom/IdentityManager/branding/my-custom-skin
Modify the skin as required.
Navigate to the following location.
/opt/CA/VirtualAppliance/custom/IdentityManager/branding
Edit the
index.jsp
file and reference the new skin, for example:
<skin:update>
<skin:skin name ="my-custom-skin" filename="/app/imcss/my-custom-skin/ui7/ca/ca.properties"/>
<skin:skin name="idm" filename="/app/imcss/idm/idm.properties" />
<skin:skin name="neteauto" filename="/app/imcss/neteauto/neteauto.properties" />
<skin:skin name="horizontal" filename="/app/imcss/horizontal/horizontal.properties" />
<skin:skin name="horizontal2" filename="/app/imcss/horizontal2/horizontal2.properties" />
</skin:update>
Save the file.
Edit the
<SKIN_NAME>/ui7/ca/ca.properties
file and change the
resourceBaseName
property to direct to the resources file of the new skin.
For example:
resourceBaseName=/app/imcss/my-custom-skin/ui7/resources
Save the file.
Edit
<SKIN_NAME>/ui7/index.jsp
file and change the
skin:update
property to direct to the ca.properties file of the new skin.
For example:
<skin:update>
    <skin:skin name="my-custom-skin" filename="/app/imcss/my-custom-skin/ui7/ca/ca.properties"/>
</skin:update>
Save the file.
In order to have branding in place for
login.jsp
file, make the following changes in the custom styles folder that you created. These folders are preserved during an upgrade.
As the config user, execute the following commands:
cd /opt/CA/VirtualAppliance/custom/IdentityManager/branding/imcss/my-custom-skin/
cp /opt/CA/wildfly-idm/standalone/deployments/iam_im.ear/user_console.war/login.jsp ui7
Customize /opt/CA/VirtualAppliance/custom/IdentityManager/branding/imcss/my-custom-skin/ui7/login.jsp to your needs.
vi /opt/CA/VirtualAppliance/custom/IdentityManager/branding/imcss/my-custom-skin/ui7/login.jsp
In the
Identity Suite
Management Console, navigate to
Environments
and select an environment.
Navigate to
Advanced Settings
,
User Console
Configure the
Login page to use
under
Authentication Properties
as
/app/imcss/my-custom-skin/ui7/login.jsp
.
Configure
Theme Properties
as required.
Restart CA Identity Manager.
Access the environment with the following URL:
https://<domain>/iam/im/identityEnv/imcss/my-custom-skin/ui7/index.jsp
Note:
Since WildFly application server loads the static files, the logo.png file must have at least the Read permission. Else, the company logo fails to load or looks broken.
Example Path:
imcss/my-custom-skin/ui7/ca/images.

Navigate to
/opt/CA/VirtualAppliance/custom/IdentityGovernance/branding
.
Edit
the
login_page
file with new changes.
After restarting CA Identity Governance, the changes will reflect in
eurekify.war/WEB-INF/classes/com/eurekify/web/Login_castyles-r7.html
.

User Store
Provisioning Server
Oracle Database Express 11g – the embedded Virtual Appliance database

Node 1: CA Identity Manager, CA Identity Portal, User Store
Node 2: CA Identity Manager, CA Identity Portal
Node 3: New node (added to the cluster)

From the Virtual Appliance Admin UI, navigate to the Setup page.
Add the new node (Node 3) to the cluster.
From the Services pane on the left, drag a new User Store service to the new node (Node 3).
Deploy the configuration.
After the deployment completes (all services start on all nodes), the data service on the new node (Node 3) automatically replicates the data from the existing User Store service on Node 1. During this replication, the service on the new node (Node 3) is in offline mode and does not serve the cluster.
Connect directly to the data service on the new node (Node 3) to verify if the replication is completed.
Example:
Using JExplorer, see the Virtual Appliance UI online help page for connectivity details to the various data services. If the connection succeeds and you can see your data, replication has completed.
Note:
Replication of large data sets can take a longer time, depending on the size of the data set and the performance of your network. Replication time can be from few minutes to few hours.
On successful completion of replication and when the new data service can service a request, you can remove the old service from the original node (Node 1).
To remove the old service, navigate to the Virtual Appliance Admin UI Setup page again. Drag the data service from Node1 toward the Services pane. This removes the data service from the configuration. You are now left with only the new data service on the new node (Node 3).
Press
Deploy
.
After a successful deployment, the data service exists only on the new node (Node 3).

Node 1: User Store
Node 2: CA Identity Manager, CA Identity Governance, User Store
Node 3: CA Identity Manager
Node 4: CA Identity Governance

From the Virtual Appliance Admin UI, navigate to the Setup page.
In the Machines pane on the right, identify the node from which you want to remove the service (Node 2 in this example).
From the Machines pane, drag the existing User Store service that you want to move to the Services pane on the left.
This marks the instance of that service for removal from the node (Node2).
From the Services pane on the left, drag a new User Store service to the node to which you want to move the service to (Node4 in this example).
Deploy the configuration.
After the deployment completes (all services start on all nodes), the data service on the new node (Node 4) automatically replicates the data from the other User Store service (which you did not touch) on Node 1.
During this replication, the service on the new node (Node 4) is in offline mode and does not serve the cluster.
Connect directly to the data service on the new node (Node 4) to verify that replication has completed.
Example:
Using JExplorer, see the Virtual Appliance UI online help page for connectivity details to the various data services. If the connection succeeds and you can see your data, replication has completed.
Note:
Replication of large data sets can take a long time, depending on the size of the data set and the performance of your network. Replication time can be from few minutes to few hours.
On successful completion of replication if the new data service can service a request, then the data service move is complete. No further action is required.

su – oracle”

From the Virtual Appliance Admin UI, navigate to the Setup page.
In the Machines pane on the right, identify the node from which you want to remove the service.
From the Machines pane, drag the existing Database service that you want to relocate, to the Services pane on the left.
This marks the instance of that service for removal from the node.
From the Services pane on the left, drag a new Database service to the new node to which you want to move the service.
Deploy the configuration.
After the deployment completes (all services start on all nodes), the database service on the new node is initialized with factory default data. The old data in the database is lost.
If necessary, see Oracle documentation for information about restoring a backup of the original data.

Start the WildFly application server for CA Identity Manager in
debug mode.
Connect to the application server from the development environment (Eclipse). This allows you to execute one line of code at a time, thus making the debugging process easier.

stop_im
start_im --debug

[INFO] enabling debug mode for /opt/CA/wildfly-idm

Edit the route interface configuration files for the corresponding network interfaces: /etc/sysconfig/network-scripts/ifcfg-eth

X

Example:

vim /etc/sysconfig/network-scripts/route-eth
1

Add static routes using the following syntax:

10.10.10.0/24 via 10.20.30.254 dev eth0

Run the following command to apply the network configuration:

Running this command may disconnect active sessions to the server.

We recommend that you run this command only when CLI/console access to the node is available so that if the network service fails to restart, you can use the CLI/console to revert the configuration.

service network reload

If syntax or logical subnet errors are present, you see the following errors:

For example

1. Error in IP address syntax:

Bringing up interface eth0:  Error: an inet address is expected rather than "10.20.30.2544".

2. Defined gateway is not local to the interface:

    Bringing up interface eth0:  RTNETLINK answers: No such process

Run the following command to inspect the routing table:

route -n

Expected Output

:

(The line that is highlighted in

green

represents the static route entry)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.20.30.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0                → The system has a single NIC on the 
10.20.30.0/24 subnet.
10.10.10.0      10.20.30.254    255.255.255.0   UG    0      0        0 eth0                → Traffic destined for
10.10.10.0/24will route via
10.20.30.254
0.0.0.0         10.20.30.1      0.0.0.0         UG    0      0        0 eth0                → All other traffic will route via 
10.20.30.1

Shut down the server.

Ask the ESX administrator to add any additional network interfaces.

Power on the server.

Run the following command to verify that the additional network interfaces were registered:

ifconfig -a | grep addr

Expected Output:

eth0      Link encap:Ethernet  HWaddr 00:0C:29:B0:FB:C5
          inet addr:10.0.0.240  Bcast:10.0.0.255  Mask:255.255.255.0
eth1      Link encap:Ethernet  HWaddr 00:0C:29:B0:FB:D9
eth2      Link encap:Ethernet  HWaddr 00:0C:29:B0:FB:E3
eth3      Link encap:Ethernet  HWaddr 00:0C:29:B0:FB:CF

The first network interface (eth0) is the primary Virtual Appliance network interface, and you must only change the IP address of additional NICs (Example: eth2, eth3, eth4...).

Edit the network interface configuration files for the corresponding network interfaces: /etc/sysconfig/network-scripts/ifcfg-eth

X

For example:

vim /etc/sysconfig/network-scripts/ifcfg-eth
1

Define the IP configuration and save the file.

For example, – the following sets an IP address of 10.0.0.242 and a network mask of /24 ( = 255.255.255.0):

DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=STATIC
IPADDR=10.0.0.242
NETMASK=255.255.255.0
#GATEWAY=
#DHCP_HOSTNAME=

Run the following command to apply the network configuration:

Running this command may disconnect active sessions to the server.

We recommend that you run this command only when CLI/console access to the node is available so that if the network service fails to restart, you can use the CLI/console to revert the configuration.

service network reload

Run the following command to verify that the IP address was registered to the network interface:

ifconfig -a | grep addr

Expected Output:

eth0      Link encap:Ethernet  HWaddr 00:0C:29:B0:FB:C5
          inet addr:10.0.0.240  Bcast:10.0.0.255  Mask:255.255.255.0
eth1      Link encap:Ethernet  HWaddr 00:0C:29:B0:FB:D9
          inet addr:
10.0.0.242  Bcast:10.0.0.255  Mask:
255.255.255.0
eth2      Link encap:Ethernet  HWaddr 00:0C:29:B0:FB:E3
eth3      Link encap:Ethernet  HWaddr 00:0C:29:B0:FB:CF
          inet addr:127.0.0.1  Mask:255.0.0.0

Navigate to
/opt/CA/VirtualAppliance/custom/IdentityManager
and
open
PS-bind.properties
for editing
.
In the properties file, include the local IP addresses (each address in a separate line) on which the Provisioning Server must listen, or "0.0.0.0" to listen on all interfaces.

Run the below commands to edit the relevant pre/post login banner files:

vim /opt/CA/VirtualAppliance/custom/login-prompt.pre
vim /opt/CA/VirtualAppliance/custom/login-prompt.post

Make the desired changes and save the files.

Run the following command to apply the banner:

configureLoginPrompt
The following output is displayed:
[INFO] Configuring pre-login banner
[INFO] Configuring post-login banner

Upon the next SSH or CLI login, the relevant pre/post banner is displayed:

login as: config
PRE-LOGIN BANNER TEXT
[email protected]<IP Address>'s password:
Last login: <DATE> from <IP Address>
POST-LOGIN BANNER TEXT

Generate an SSH key pair that is owned by WildFly.
Remove an existing SSH key pair that is owned by Wildfly.
List all SSH keypairs that are owned by Wildfly.
Export an SSH key pair that is owned by Wildfly.

ssh -o StrictHostKeyChecking=no -i /opt/CA/VirtualAppliance/conf/wildfly-ssh-keys/my_custom_key1 <username>@<remote host> "<remote command>"

Self-signed certificates for each Wildfly application instance (CA Identity Manager, CA Identity Governance, and CA Identity Portal) are automatically generated in
/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates/ Note:
If a certificate already exists in the directory, a new certificate will not be created and the existing certificate will be retained.
The certificate is automatically imported into the java keystore of the server.
The java keystore is unique per server and there is no synchronization of keystore data between hosts.
The certificates can be replaced with custom certificates. A restart of the service is required.

<https-listener name="https" socket-binding="https" security-realm="WebSslRealm"/>
<security-realm name="WebSslRealm">
<server-identities>
<ssl>
<keystore path="/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates/caim-srv" .../>
</ssl>
</server-identities>
</security-realm>

# This file controls the list of enabled protocols and cipher suites for the HTTPS listener of wildfly
# If this file includes value "true" on a single uncommented line - TLSv1.2 is used and cipher suites are limited.
# Otherwise - the wildfly defaults are used (TLSv1.0, TLSv1.1 and TLSv1.2 and all cipher suites).
# Uncomment the following line to enable TLSv1.2 and limited cipher suites
# true

Navigate to

/opt/CA/VirtualAppliance/custom

.

Open

vapp_proxy.conf

for editing.

Configure the following proxy parameters:

loglevel:
Controls the verbosity of the proxy logs.
Allowed Values:
error, warn, info, debug
Default:
warn
Example:
loglevel=error
connectiontimeout:
Represents connection timeout in seconds for the Apache httpd to wait for the creation of a connection to the backend to complete.
Default:
5 seconds
Example:
connectiontimeout=15 seconds
retry:
Represents connection pool worker retry timeout in seconds. If the connection pool worker to the backend server is in the error state, Apache httpd will not forward any requests to that server until the timeout expires. A value of 0 means always retry workers in an error state with no timeout.
Default:
120 seconds
Example:
retry=130 seconds

Restart the HTTPD server for the changes to take effect.

$> service httpd restart

In the Virtual Appliance, navigate to /opt/CA/VirtualAppliance/custom/IdentityManager.

Open

jboss-ejb3.properties

for editing.

Change the value of the

maxSession

property to a desired value.

maxSession=80

Restart Identity Manager.

restart_im