Sending Okta Logs

Okta is a commonly used identity management service for adding authentication and authorization functionality to applications. The following describes how to set up the collection and forwarding of Okta system logs to LM Logs for further ingestion and processing.

Integrating Okta Logs with LM on AWS

You can leverage an AWS CloudFormation Stack to automate your log collection, processing, and forwarding from Okta. For more information, see Okta Log Ingestion with AWS Overview.

Integrating OKTA Logs with LM on Azure

This integration provides an Azure ARM Template which includes a Function App periodically collecting Okta system logs and forwarding it to LogicMonitor.

Requirements

• LogicMonitor API tokens to authenticate all requests to the log ingestion API. For more information, see API Tokens.
• Okta API access key. To know how to generate Okta API access key, see Create the Token in the Okta documentation.

Configuration Parameters

Use the following parameters while deploying integration on Azure.

Parameter	Description
AZURE_REGION	Region in which the resources should be created
LM_COMPANY	The LogicMonitor account name
LM_DOMAIN_NAME	The LogicMonitor domain nameBy default, it is set to “logicmonitor.com”. The supported domains for this variable are as follows: lmgov.us qa-lmgov.us logicmonitor.com
LM_ACCESS_ID	The LM API tokens access ID
LM_ACCESS_KEY	The LM API tokens access key
LM_BEARER_TOKEN	The LM API Bearer token. You must specify LMBearerToken if not providing LMAccessId, LMAccessKey. If you provide all, LMAccessId and LMAccessKey are used to authenticate with LogicMonitor.
OKTA_DOMAIN	Okta domain, for example, “company.okta.com”
OKTA_API_KEY	Okta API key to fetch logs from okta
LM_SERVICE_NAME_KEY	This is used for anomaly detection. By default, it is set to okta-system-logs.
LM_RESOURCE_ID	This parameter is ignored if LM_SERVICE_NAME is set. It specifies resource mapping in JSON format. If specified as {“system.hostname” : “prod-node-us-west-1”}, all logs are will mapped to the device with property system.hostname = prod-node-us-west-1.
INCLUDE_METADATA_KEYS	Comma separated keys to add as event metadata in a lm-log event. For nested json specify ‘.’ For example – actor.displayname,actor.type. By default, it is set to ‘severity,actor.displayname,actor.type,actor.alternateId,client.geographicalContext.city,displayMessage,eventType’
S3_FOLDER	The S3 bucket name where the code is stored. By default it is set to stable. The staging option refers to develop branch and the stable option refers to master branch.

Deploying OKTA Log Integration with LM on Azure

1. Select the following link to open the custom deployment template in the Microsoft Azure portal: Deploy from a custom template.
2. Sign in with your Azure credentials if prompted.
3. On the Custom deployment page, enter the required parameter values.
4. Select Review + create.

If the deployment is successful, logs appear in the LogicMonitor portal.

Troubleshooting

Enabling Debug Logging

You can enable Application Insights in the Function App to check whether it is receiving logs. For more information, see Enable streaming execution logs.

You can configure the application logging type and level using the Azure CLI webapp log config command. Example:

az webapp log config --resource-group <Azure Function's Resource Group name> --name <Azure Function name> --application-logging true --level verbose --detailed-error-messages true

After configuring application logging, you can see the logs using Azure CLI webapp log tail. Example:

az webapp log tail --resource-group <Azure Function's Resource Group name> --name <Azure Function name>

Integrating Okta Log with LM on GCP

This integration provides a GCP stack which includes a cloud function that periodically collects Okta system logs and forwards them to LogicMonitor.

Requirements

• LogicMonitor API tokens to authenticate all requests to the log ingestion API. For more information, see API Tokens.
• Okta API access key. To know how to generate Okta API access key, see Create the Token in the Okta documentation.

Configuration Parameters

Parameter	Description
LM_RESOURCE_ID	This parameter is ignored if LM_SERVICE_NAME is set. It specifies resource mapping in JSON format. If specified as {“system.hostname” : “prod-node-us-west-1”}, all logs are will mapped to the device with property system.hostname = prod-node-us-west-1.
LM_SERVICE_NAME	This is used for anomaly detection. By default, it is set to okta-system-logs.
OKTA_DOMAIN	The Okta domain. For example, “company.okta.com”.
LM_DOMAIN_NAME	The LogicMonitor domain nameBy default, it is set to “logicmonitor.com”. The supported domains for this variable are as follows: lmgov.us qa-lmgov.us logicmonitor.com
COMPANY_NAME	The LogicMonitor account name.
LM_ACCESS_KEY	The LM API token access key.
LM_ACCESS_ID	The LM API token access ID.
LM_BEARER_TOKEN	The LM API Bearer token. You must specify the LM_BEARER_TOKEN if you are not providing the LM_ACCESS_ID and LM_ACCESS_KEY. If you provide all three (the bearer token, access ID, and access key), the LM_ACCESS_ID and LM_ACCESS_KEY is used to authenticate with LogicMonitor.
INCLUDE_METADATA_KEYS	Comma separated keys to add as event metadata in a lm-log event. For nested JSON, specify ‘.’ For example, – actor.displayname,actor.type. By default, it is set to ‘severity,actor.displayname,actor.type,actor.alternateId,client.geographicalContext.city,displayMessage,eventType’
OKTA_API_KEY	API key used to fetch logs from Okta.

Deploying LM Integration on GCP

1. In Google Cloud Console, select Activate Cloud Shell on the top right. A Cloud Shell Terminal below the workspace is displayed.
2. Run the following commands to install the integration:
   export OKTA_DOMAIN=<okta domain> \
export OKTA_API_KEY=<okta api key> \
export COMPANY_NAME=<lm company name> \
export LM_DOMAIN_NAME=<lm domain name> \
export LM_ACCESS_ID=<lm access id> \
export LM_ACCESS_KEY=<lm access key> \
export INCLUDE_METADATA_KEYS=actor.displayName \
export REGION=<region> \ source <(curl -s https://lm-logs-okta-collector-gcp.s3.amazonaws.com/stable/gcp.sh) && deploy_lm_logs_okta

If the deployment is successful, logs appear in the LogicMonitor portal.


Removing the integration

Run the following commands to delete the Okta log integration with LM on GCP and all its resources from the GCP console:

export REGION=<region> \
source <(curl -s https://lm-logs-okta-collector-gcp.s3.amazonaws.com/stable/gcp.sh) && delete_lm_logs_okta