Autonomous Identity 2021.8.6

Deployment Tasks

Autonomous Identity administrators and deployers must set up additional tasks during installment.

The following are some deployments tasks that may occur:

Customize the Domain and Namespace

By default, the Autonomous Identity URL and domain for the UI console is set to autoid-ui.forgerock.com, and the URL and domain for the self-service feature is autoid-selfservice.forgerock.com.

Customize domain and namespace:
  1. Customize the domain name and target environment by editing the /autoid-config/vars.xml file. By default, the domain name is set to forgerock.com and the target environment is set to autoid. The default Autonomous Identity URL will be: https://autoid-ui.forgerock.com. For example, we set the domain name to abc.com and the target environment to myid:

    domain_name: forgerock.com
    target_environment: autoid
  2. If you set up your domain name and target environment in the previous step, you need to change the certificates to reflect the changes. Autonomous Identity generates self-signed certificates for its default configuration. You must generate new certificates as follows:

    1. Generate the private key (that is, privatekey.pem).

      $ openssl genrsa 2048 > privatekey.pem
    2. Generate the certificate signing request.

      $ openssl req -new -key privatekey.pem -out csr.pem
    3. Generate the Diffie-Hellman (DH) parameters file (dhparam4096.pem).

      $ openssl dhparam -out dhparam4096.pem 4096
    4. Create a self-signing certificate.

      $ openssl x509 -req -days 365 -in csr.pem -signkey privatekey.pem -out server.crt
    5. Use your Certificate Authority (CA) to sign the certificate. The certificate must be server.crt.

    6. Copy the files to the /autoid-config/certs directory.

    7. Make the domain changes on your DNS server or update your /etc/hosts (Linux/Unix) file or C:\Windows\System32\drivers\etc\hosts (Windows) locally on your machine.

Configuring Your Filters

The filters on the Applications pages let you focus your searches based on entitlement and user attributes. In most cases, the default filters should suffice for most environments. However, if you need to customize the filters, you can do so by accessing the configuration service API endpoint as show below.

The default filters for an entitlement are the following:

  • Risk Level

  • Criticality

The default filters for an user attributes are the following:

  • User Department Name

  • Line of Business Subgroup

  • City

  • Jobcode Name

  • User Employee Type

  • Chief Yes No

  • Manager Name

  • Line of Business

  • Cost Center

Configure the Filters:
  1. From the deployer node, SSH to the target node.

  2. Run the curl command to retrieve the current filters configuration.

    $ curl -i -k -u configadmin:<configadmin-password> --header "Content-Type: application/json" --request GET
      https://autoid-configuration-service.forgerock.com/api/configuration/AllowedAttributesForFiltering
    
    {
      "entitlement": [
        "risk_level",
        "criticality",
        "owner"
      ],
      "user": [
        "usr_department_name",
        "line_of_business_subgroup",
        "city",
        "jobcode_name",
        "usr_emp_type",
        "chief_yes_no",
        "manager_name",
        "line_of_business",
        "cost_center"
      ]
    }
  3. Update the filters configuration. The syntax is as follows:

    $ curl -i -k -u configadmin:<configadmin-password> \
          --request PUT \
          --header "Content-Type: application/json" \
          --data '{<UPDATED_FILTERING_JSON_DATA>}' \
        https://autoid-configuration-service.forgerock.com/api/configuration/AllowedAttributesForFiltering

    For example, update the filters list with fewer attributes:

    $ curl -i -k -u configadmin:<configadmin-password> \
          --request PUT \
          --header "Content-Type: application/json"
          --data '{ "entitlement":["risk_level","criticality","owner"], \
            "user":["usr_department_name","line_of_business_subgroup","city","jobcode_name"]}' \
        https://autoid-configuration-service.forgerock.com/api/configuration/AllowedAttributesForFiltering
    
    configuration item updated

Change the Vault Passwords

Autonomous Identity uses the ansible vault to store passwords in encrypted files, rather than in plaintext. Autonomous Identity stores the vault file at /autoid-config/vault.yml saves the encrypted passwords to /config/.autoid_vault_password . The /config/ mount is internal to the deployer container. The default encryption algorithm used is AES256.

By default, the /autoid-config/vault.yml file uses the following parameters:

configuration_service_vault:
  basic_auth_password: Welcome123

openldap_vault:
  openldap_password: Welcome123

cassandra_vault:
  cassandra_password: Welcome123
  cassandra_admin_password: Welcome123

mongo_vault:
  mongo_admin_password: Welcome123
  mongo_root_password: Welcome123

elastic_vault:
  elastic_admin_password: Welcome123
  elasticsearch_password: Welcome123

Assume that the vault file is encrypted during the installation. To edit the file:

Edit the Vault file:
  1. Change to the /autoid-config/ directory.

    $ cd ~/autoid-config/
  2. First, decrypt the vault file.

    $ ./deployer.sh decrypt-vault
  3. Open a text editor and edit the vault.yml file.

  4. Encrypt the file again.

    $ ./deployer.sh encrypt-vault

Set Up Single Sign-On

Autonomous Identity supports single sign-on (SSO) using OpenID Connect (OIDC) JWT tokens. SSO lets you log in once and access multiple applications without the need to re-authenticate yourself. You can use any third-party identity provider (IdP) to connect to Autonomous Identity. In this example, we use ForgeRock Access Management (AM) as an OpenID Connect (OIDC) IdP for Autonomous Identity.

If you set up SSO-only, be aware that the following services are not deployed with this setting:

  • Self Service

  • Manage Identities

If you want to use these services and SSO, set up the authentication as "LocalAndSSO". Otherwise, for SSO-only, you must use the user services provided by your SSO provider.

The following procedure requires a running instance of ForgeRock AM. For more information, see ForgeRock Access Management Authentication and Single Sign-On Guide.

Set up SSO:
  1. First, set up your hostnames locally in /etc/hosts (Linux/Unix) file or C:\Windows\System32\drivers\etc\hosts (Windows).

    35.189.75.99  autoid-ui.forgerock.com autoid-selfservice.forgerock.com
    35.246.65.234 openam.example.com
  2. Open a browser and point to http://openam.example.com:8080/openam. Log in with username: amadmin, password: cangetinam.

  3. In AM, select Realm > Identities > Groups tab, and add the following groups:

    • AutoIdAdmin

    • AutoIdEntitlementOwner

    • AutoIdExecutive

    • AutoIdSupervisor

    • AutoIdUser

    • AudtIdAppOwner

    • AutoIdRoleOwner

    • AutoIdRoleEngineer

      The group names above are arbitrary and are defined in the /autoid-config/vars.yml file. Ensure that the groups you create in AM match the values in the vars.yml file.

  4. Add the demo user to each group.

  5. Go back to the main AM Admin UI page. Click Configure OAuth Provider.

  6. Click Configure OpenID Connect, and then Create.

  7. Select desired Realm > Go to Applications > OAuth 2.0, and then click Add Client. Enter the following properties, specific to your deployment:

    Client ID:         <autoid>
    Client secret:     <password>
    Redirection URIs:  https://<autoi-ui>.<domain>/api/sso/finish
    Scope(s):          openid profile

    For example:

    Client ID:         autoid
    Client secret:     Welcome123
    Redirection URIs:  https://autoid-ui.forgerock.com/api/sso/finish
    Scope(s):          openid profile
  8. On the New Client page, go to to the Advanced tab, and enable Implied Consent. Next, change the Token Endpoint Authentication Method to client_secret_post.

  9. Edit the OIDC claims script to return roles (groups), so that AM can match the Autonomous Identity groups. Additionally, add the groups as a claim in the script.

    "groups": { claim, identity -> [ "groups" : identity.getMemberships(IdType.GROUP).collect { group -> group.name }]}

    In the utils.setScopeClaimsMap block add:

    groups: ['groups']

    For more information about the OIDC claims script, see the ForgeRock Knowledge Base.

  10. The id_token returns the content that includes the group names.

    {
      "at_hash": "QJRGiQgr1c1sOE4Q8BNyyg",
      "sub": "demo",
      "auditTrackingId": "59b6524d-8971-46da-9102-704694cae9bc-48738",
      "iss": "http://openam.example.com:8080/openam/oauth2",
      "tokenName": "id_token",
      "groups": [
        "AutoIdAdmin",
        "AutoIdSupervisor",
        "AutoIdUser",
        "AutoIdExecutive",
        "AutoIdEntitlementOwner",
        "AutoIdAppOwner",
        "AutoIdRoleOwner",
        "AutoIdRoleEngineer"
    
      ],
      "given_name": "demo",
      "aud": "autoid",
      "c_hash": "SoLsfc3zjGq9xF5mJG_C9w",
      "acr": "0",
      "org.forgerock.openidconnect.ops": "B15A_wXm581fO8INtYHHcwSQtJI",
      "s_hash": "bOhtX8F73IMjSPeVAqxyTQ",
      "azp": "autoid",
      "auth_time": 1592390726,
      "name": "demo",
      "realm": "/",
      "exp": 1592394729,
      "tokenType": "JWTToken",
      "family_name": "demo",
      "iat": 1592391129,
      "email": "demo@example.com"
    }

    For more information on how to retrieve the id_token for observation, see OpenID Connect 1.0 Endpoints.

  11. You have successfully configured AM as an OIDC provider. Next, we set up Autonomous Identity.

  12. Change to the Autonomous Identity install directory on the deployer machine.

    $ cd ~/autoid-config/
  13. Open a text editor, and set the SSO parameters in the /autoid-config/vars.yml file. Make sure to change LDAP to SSO.

    authentication_option: "SSO"
    
    oidc_issuer: "http://openam.example.com:8080/openam/oauth2"
    oidc_auth_url: "http://openam.example.com:8080/openam/oauth2/authorize"
    oidc_token_url: "http://openam.example.com:8080/openam/oauth2/access_token"
    oidc_user_info_url: "http://openam.example.com:8080/openam/oauth2/userinfo"
    oidc_jwks_url: "http://openam.example.com:8080/openam/oauth2/connect/jwk_uri"
    oidc_callback_url: "https://autoid-ui.forgerock.com/api/sso/finish"
    oidc_client_scope: 'openid profile'
    oidc_groups_attribute: groups
    oidc_uid_attribute: sub
    oidc_client_id: autoid
    oidc_client_secret: Welcome1
    admin_object_id: AutoIdAdmin
    entitlement_owner_object_id: AutoIdEntitlementOwner
    executive_object_id: AutoIdExecutive
    supervisor_object_id: AutoIdSupervisor
    user_object_id: AutoIdUser
    application_owner_object_id: AutoIdAppOwner
    role_owner_object_id: AutoIdRoleOwner
    role_engineer_object_id: AutoIdRoleEngineer
    oidc_end_session_endpoint: "http://openam.example.com:8080/openam/oauth2/logout"
    oidc_logout_redirect_url: "http://openam.example.com:8088/openam/logout"
  14. On the Target machine, edit the /etc/hosts file, and add an entry for openam.example.com.

    35.134.60.234  openam.example.com
  15. On the Deployer machine, run deployer.sh to push the new configuration.

    $ deployer.sh run
  16. Test the connection now. Access https://autoid-ui/forgerock.com. The redirect should occur with the following:

    http://openam.example.com:8080/openam/XUI/?realm=%2F&goto=http%3A%2F%2Fopenam.example.com%3A8080%2Fopenam%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Dautoid

Setting the Session Duration

By default, the session duration is set to 30 minutes. You can change this value at installation by setting the JWT_EXPIRY property in the /autoid-config/vars.yml file.

If you did not set the value at installation, you can make the change after installation by setting the JWT_EXPIRY property using the API service.

Set the session duration:
  1. Log in to the Docker manager node.

  2. Verify the JWT_EXPIRY property.

    $ docker inspect api_zoran-api
  3. Go to the API folder.

    $ cd /opt/autoid/res/api
  4. Edit the docker-compose.yml file and update the JWT_EXPIRY property. The JWT_EXPIRY property is set to minutes.

  5. Redeploy the Docker stack API.

    $ docker stack deploy --with-registry-auth --compose-file docker-compose.yml api

    If the command returns any errors, such as "image could not be accessed by the registry," then try the following command:

    $ docker stack deploy --with-registry-auth --resolve-image changed \
        --compose-file /opt/autoid/res/api/docker-compose.yml api
  6. Verify the new JWT_EXPIRY property.

    $ docker inspect api_zoran-api
  7. Log in to the Docker worker node.

  8. Stop the worker node.

    $ docker stop [container ID]

    The Docker manager node re-initiates the worker node. Repeat this step on any other worker node.

Custom certificates

By default, Autonomous Identity uses self-signed certificates in its services. You can replace these self-signed certificates with a certificate issued by a Certificate Authority (CA). This section provides instructions on how to replace your self-signed certificates and also update your existing certificates when expired.

Pre-requisites

The following items were used to test the custom certificate procedures:

  • Private key file. The procedure uses a private key file privkey.pem.

  • Full trust chain. The procedure also uses a full trust certificate chain, fullchain.pem.

  • Keystore password. The procedure was tested using the keystore password is Acc#1234.

  • NGINX certificate. The NGINX certificate must support subject alternative name (SAN) for the following domains:

    • autoid-ui.<domain-name>

    • autoid-jas.<domain-name>

    • autoid-configuration-service.<domain-name>

    • autoid-kibana.<domain-name>

    • autoid-api.<domain-name>

  • Domain name. The domain name used in the procedure below is certupdate.autoid.me. Change the value in various places to the domain name applicable to your deployment.

  • Autonomous Identity version. The procedures were tested on Autonomous Identity versions 2021.8.5 and 2021.8.6.

Update certificates on Cassandra

The following section shows how to replace the certificates in Cassandra.

  1. Create the Java keystore and truststore files for the server using keytool. The commands generate two JKS files: cassandra-keystore.jks and cassandra-truststore.jks. You need these files for configuring Cassandra and the Java API Service (JAS).

    openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out server.p12 -name cassandranode
    
    keytool -importkeystore -deststorepass Acc#1234 -destkeypass Acc#1234 -destkeystore cassandra-keystore.jks -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass Acc#1234 -alias cassandranode
    
    keytool -importcert -keystore cassandra-truststore.jks -alias rootCa -file fullchain.pem -noprompt -keypass Acc#1234 -storepass Acc#1234
  2. Create the client certificate. The client certificate is used by external clients, such as JAS and cqlsh to authenticate to Cassandra. In the following example, use the same client certificate for the Cassandra nodes to authenticate with each other.

    You can create a different certificate, if desired, using similar steps.
    # Create client.conf with following contents
    [ req ]
    distinguished_name = CA_DN
    prompt             = no
    default_bits       = 2048
    
    [ CA_DN ]
    C  = cc
    O  = eng
    OU = cass
    CN = CA_CN
    
    # Create client key and CSR
    openssl req -newkey rsa:2048 -nodes -keyout client.key -out signing_request.csr -config client.conf
    
    # Create client certificate
    openssl x509 -req -CA fullchain.pem -CAkey privkey.pem -in signing_request.csr -out client.crt -days 3650 -CAcreateserial
    
    # Import client cert into a Java keystore for JAS
    openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12 -name jas
    
    keytool -importkeystore -deststorepass Acc#1234 -destkeypass Acc#1234 -destkeystore client-keystore.jks -srckeystore client.p12 -srcstoretype PKCS12 -srcstorepass Acc#1234 -alias jas
  3. View the files that are needed in later steps:

    $ ls -1 .
    
    cassandra-keystore.jks
    cassandra-truststore.jks
    client.conf
    client.crt
    client.key
    client-keystore.jks
    client.p12
    fullchain.pem
    fullchain.srl
    privkey.pem
    server.p12
    signing_request.csr
  4. Copy the following files to the /opt/autoid/apache-cassandra-3.11.2/conf/certs directory on each Cassandra node:

    • cassandra-keystore.jks

    • cassandra-truststore.jks

    • client-keystore.jks

  5. Copy the following files to the <autoid-user-home-dir>/.cassandra directory on each Cassandra node:

    • client.key

    • client.crt

    • fullchain.pem

  6. Make the following edits in the /opt/autoid/apache-cassandra-3.11.2/conf/cassandra.yaml file on each Cassandra node:

    1. Change the keystore and truststore paths in the server_encryption_options and client_encryption_options sections:

      keystore: /opt/autoid/apache-cassandra-3.11.2/conf/certs/client-keystore.jks
      truststore: /opt/autoid/apache-cassandra-3.11.2/conf/certs/cassandra-truststore.jks
  7. Update the <autoid-user-home-dir>/.cassandra/cqlshrc file with the following edits:

    [authentication]
    username = zoranuser
    password = <password>
    [connection]
    hostname = <ip address>
    factory = cqlshlib.ssl.ssl_transport_factory
    
    [ssl]
    certfile = <autoid-user-home-dir>/.cassandra/fullchain.pem
    validate = false
    version = SSLv23
    # Next 2 lines must be provided when require_client_auth = true in the cassandra.yaml file
    userkey = <autoid-user-home-dir>/.cassandra/client_key.key
    usercert = <autoid-user-home-dir>/.cassandra/client.crt
  8. Restart Cassandra.

    ps auxf | grep cassandra
    kill <pid>
    cd /opt/autoid/apache-cassandra-3.11.2/bin
    nohup ./cassandra >/opt/autoid/apache-cassandra-3.11.2/cassandra.out 2>&1 &
  9. Make sure that Cassandra is running normally using cqlsh. Use your server’s IP. :

    $ cqlsh --ssl
    Connected to Zoran Cluster at <server-ip>:9042.
    [cqlsh 5.0.1 | Cassandra 3.11.2 | CQL spec 3.4.4 | Native protocol v4]
    Use HELP for help.
    zoranuser@cqlsh> describe keyspaces;
    
    autonomous_iam  system_auth  system_distributed  autoid_analytics
    autoid          system       system_traces       autoid_base
    system_schema   autoid_meta  autoid_staging
    
    zoranuser@cqlsh>

Update certificates on MongoDB

  1. Create the keystore and truststore using keytool.

    openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out server.p12 -name mongonode
    
    keytool -importkeystore -deststorepass Acc#1234 -destkeypass Acc#1234 -destkeystore mongo-client-keystore.jks -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass Acc#1234 -alias mongonode
    
    keytool -importcert -keystore mongo-server-truststore.jks -alias rootCa -file fullchain.pem -noprompt -keypass Acc#1234 -storepass Acc#1234
  2. Create a new mongodb.pem file.

    cat fullchain.pem privkey.pem > mongodb.pem
  3. Download the isg root x1 root certificate from Lets Encrypt at https://letsencrypt.org/certs/isgrootx1.pem, and save it as rootCA.pem.

  4. Back up the MongoDB certificates.

    cd /opt/autoid/mongo/certs/
    mkdir backup
    mv mongodb.pem backup/
    mv rootCA.pem backup/
    mv mongo-*.jks backup
  5. Copy the new certificates to the mongodb installation.

    cp mongodb.pem /opt/autoid/mongo/certs/
    cp rootCA.pem /opt/autoid/mongo/certs/
  6. Restart Mongo DB.

    sudo systemctl stop mongo-autoid
    sudo systemctl start mongo-autoid
  7. Check for logs for errors in /opt/autoid/mongo/mongo-autoid.log. The log may show connection errors until JAS has been updated and restarted.

  8. Add the hostname to the hosts file. For example, we are using: autoid-mongo.certupdate.autoid.me.

  9. Check the MongoDB connection from the command line.

    mongo --tls --host autoid-mongo.certupdate.autoid.me --tlsCAFile /opt/autoid/mongo/certs/rootCA.pem --tlsCertificateKeyFile /opt/autoid/mongo/certs/mongodb.pem --username mongoadmin
  10. Back up and copy the new keystore and truststore to JAS.

    cd /opt/autoid/mounts/jas
    mkdir backup
    mv mongo-*.jks backup
    
    cp mongo-server-truststore.jks /opt/autoid/mounts/jas
    cp mongo-client-keystore.jks /opt/autoid/mounts/jas
  11. Update the JAS configuration. On each Docker manager and worker node, copy the following files to the /opt/autoid/mount/jas directory.

    • mongo-client-keystore.jks

    • mongo-server-truststore.jks

      The certificates must exist on all Docker nodes (all managers and worker nodes).
  12. On each Docker manager node, update /opt/autoid/res/jas/docker-compose.yml file and set the Mongo keystore, truststore, and host, and add the extra_hosts line as follows:

    MONGO_KEYSTORE_PATH=/db-certs/mongo-client-keystore.jks
    MONGO_TRUSTSTORE_PATH=/db-certs/mongo-server-truststore.jks
    MONGO_HOST=autoid-mongo.certupdate.autoid.me
    
    extra_hosts:
      - "autoid-mongo.certupdate.autoid.me:<ip of mongodb host>"
  13. Restart JAS.

    docker stack rm jas nginx
    docker stack deploy -c /opt/autoid/res/jas/docker-compose.yml jas
    docker stack deploy -c /opt/autoid/res/nginx/docker-compose.yml nginx
  14. Check JAS logs for errors.

    docker service logs -f jas_jasnode

Update certificates on JAS

  1. On each Docker manager and worker node, copy the following keystore and truststore files to /opt/autoid/mounts/jas directory:

    • client-keystore.jks

    • cassandra-truststore.jks

  2. On each Docker manager node, update /opt/autoid/res/jas/docker-compose.yml with the correct keystore and truststore paths:

    CASSANDRA_KEYSTORE_PATH=/db-certs/client-keystore.jks
    CASSANDRA_TRUSTSTORE_PATH=/db-certs/cassandra-truststore.jks
  3. Redeploy the JAS server.

    docker stack rm jas
    docker stack deploy jas -c /opt/autoid/res/jas/docker-compose.yml
  4. Make sure JAS has no errors.

    docker service logs -f jas_jasnode

Update the certificates on NGINX

  1. Copy the following files to /opt/autoid/mounts/nginx/cert/:

    • privkey.pem

    • fullchain.pem

  2. In the /opt/autoid/mounts/nginx/nginx.conf file, update the ssl_certificate and ssl_certificate_key properties as follows:

    #SSL Settings
    ssl_certificate         /etc/nginx/cert/fullchain.pem;
    ssl_certificate_key     /etc/nginx/cert/privkey.pem;
  3. Make sure that the domain names in the configuration files (/opt/autoid/mounts/nginx/conf.d) matches the domain names used for certificate generation.

  4. Restart the Docker container.

    docker stack rm nginx
    docker stack deploy -c /opt/autoid/res/nginx/docker-compose.yml nginx

Update certificates on Elasticsearch

  1. Create a keystore and truststore using keystore.

    openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out server.p12 -name esnodekey
    
    keytool -importkeystore -deststorepass Acc#1234 -destkeypass Acc#1234 -destkeystore elastic-client-keystore.jks -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass Acc#1234 -alias esnodekey
    
    keytool -importcert -keystore elastic-server-truststore.jks -alias rootCa -file fullchain.pem -noprompt -keypass Acc#1234 -storepass Acc#1234
  2. Create backups.

    cd /opt/autoid/certs/elastic
    mkdir backup
    mv *.jks backup
  3. Copy the new jks files, fullchain.pem, privkey.pem, and chain.pem to /opt/autoid/certs/elastic.

  4. Also, copy the fullchain.pem, privkey.pem, and chain.pem certificates to /opt/autoid/elastic/opendistroforelasticsearch-1.9.0/config/.

  5. Update the following attributes in the /opt/autoid/elastic/opendistroforelasticsearch-1.9.0/config/elasticsearch.yml file:

    opendistro_security.ssl.transport.pemcert_filepath: fullchain.pem
    opendistro_security.ssl.transport.pemkey_filepath: privkey.pem
    opendistro_security.ssl.transport.pemtrustedcas_filepath: chain.pem
    
    opendistro_security.ssl.http.pemcert_filepath: fullchain.pem
    opendistro_security.ssl.http.pemkey_filepath: privkey.pem
    opendistro_security.ssl.http.pemtrustedcas_filepath: chain.pem
    
    
    opendistro_security.nodes_dn:
    
      - CN=elastic.certupdate.autoid.me
  6. Restart Elasticsearch on all Elasticsearch nodes:

    sudo systemctl restart elastic
  7. Check /opt/autoid/elastic/logs/elasticcluster.log for errors. The file shows any certificate error until all nodes have been restarted.

  8. In the /opt/autoid/res/jas/docker-compose.yml file, add the following:

    extra_hosts:
    - "elastic.certupdate.autoid.me:<ip of ES host>"
    
    update ES_HOST env var:
    ES_HOST=elastic.certupdate.autoid.me
  9. Restart the JAS container:

    docker stack rm jas
    docker stack rm nginx
    docker stack deploy -c /opt/autoid/res/jas/docker-compose.yml jas
    docker stack deploy -c /opt/autoid/res/nginx/docker-compose.yml nginx
  10. Test the connection from the JAS container to Elasticsearch:

    docker container exec -it <jas container id> sh
    apk add curl
    curl -v --cacert /elastic-certs/fullchain.pem -u elasticadmin https://elastic.certupdate.autoid.me:9200
  11. Update the configuration in the JAS service using curl:

    1. First log in using curl.

      curl -X POST https://autoid-ui.certupdate.autoid.me:443/api/authentication/login -k -H 'Content-Type: application/json' -H 'X-TENANT_ID: <tenant_id >' -d '{
      "username": "bob.rodgers@forgerock.com",
      "password": "Welcome123"
      }'
    2. Pull in the current configuration using curl.

      curl -k -H "Content-Type: application/json" -H 'X-TENANT-ID: <tenant_id>' -H 'Authorization: Bearer <bearer_token>' --request GET https://jasnode:10081/config/analytics_env_config
    3. Modify value for elasticsearch" to "host":elastic.certupdate.autoid.me``.

    4. Push the updated configuration:

      curl -k  -H "Content-Type: application/json" -H 'X-TENANT-ID: <tenant_id>'  -H 'Authorization: Bearer <bearer_token>' --request PUT https://jasnode:10081/config/analytics_env_config -d '<updated json config>'
  12. Update the environment variable in your .bashrc on all Elasticsearch nodes and Spark nodes:

    ES_HOST=elastic.certupdate.autoid.me
Copyright © 2010-2022 ForgeRock, all rights reserved.