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.

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.

Integrating Okta Logs with LM on AWS

The integration uses an AWS CloudFormation stack that includes a Lambda function written in Python. For more information, see Managing AWS resources as a single unit with AWS CloudFormation stacks in the AWS documentation. The integration components are available in the LogicMonitor GitHub repository. For more information, see LogicMonitor GitHub repository.

Deploying the AWS CloudFormation Stack

The integration uses an AWS CloudFormation stack including a Lambda function written in Python. The integration components are available in this LogicMonitor GitHub repository.

Do the following to create and deploy the integration components.

1. Navigate to the Okta Log Collector for LM Logs GitHub repository.
2. In the repository, select Launch Stack to initiate the stack creation.
3. Log into AWS and select the create stack option in CloudFormation.
4. Enter a name for the stack, for example “lm-okta-log-collector”.
5. Enter parameter values as applicable, for parameter descriptions see Configuration Options.
   
   
6. Select Create Stack to deploy the Lambda function.

When you have created the stack, Okta system logs will be collected and forwarded periodically based on the configured time range.

Configuration Options

Parameter	Description
FunctionName	(Required) The name of the log forwarding Lambda function.  Default value: LM-Okta-Log-Collector
LMCompanyName	(Required) Your LogicMonitor account (portal) name.
LMDomainName	(Required) The LogicMonitor domain name. Note: By default, the domain is set to “logicmonitor.com“. The supported domains for this variable are as follows: lmgov.us qa-lmgov.us logicmonitor.com
LMAccessId	(Required) The LogicMonitor API tokens access ID.
LMAccessKey	(Required) The LogicMonitor API tokens access key.
OktaDomain	(Required) Your Okta domain, for example “company.okta.com”.
OktaAPIKey	(Required) Your Okta API key used to fetch logs from Okta, see Requirements.
LMLogsServiceName	Used for anomaly detection if no resource mapping exists. Default value: okta-system-logs
LMResourceId	Resource mapping in JSON format, ignored when LMLogsServiceName is specified. For example, if specified as {"system.hostname" : "prod-node-us-west-1"} all logs are mapped against the device with property “system.hostname = prod-node-us-west-1”.
IncludeMetadataKeys	Comma-separated keys to add as event metadata fields in an lm-log event. For nested JSON specify ‘.’ Example: actor.displayname,actor.type. Default values: severity,actor.displayName,actor.type,actor.alternateId,client.geographicalContext.city,displayMessage,eventType,target
ScheduleExpression	Cron expression for triggering the Lambda function. For example when set to “rate(2 minutes)”, the function runs every 2 minutes. See the AWS documentation. Default value: rate(2 minutes)
FunctionMemorySize	Memory size in MBs for the Okta Log Collector Lambda function. Default value: 2048
FunctionTimeoutInSeconds	Timeout in seconds for the Okta Log Collector Lambda function. Default value: 110

Troubleshooting

See the following if you are experiencing issues after setting up the collection and forwarding of Okta logs to LM Logs.

No Logs Appear in LM Logs Page

If you don’t see any logs in the LM Logs page, check the following:

• Ensure that the credentials used and parameter configurations are valid.
• Investigate the CloudWatch logs to get more information.

Lambda Function Timeouts

In case of frequent Lambda function timeouts, try the following: 

• Increase the memory size (FunctionMemorySize), this results in faster CPU assignment.
• Increase the trigger time rate (ScheduleExpression) to for example 5 minutes.

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 name. By default, the domain is set to “logicmonitor.com”. The supported domains for this variable are as follows:lmgov.usqa-lmgov.uslogicmonitor.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