ssf_streams

Creates, updates, deletes, gets or lists a ssf_streams resource.

Overview

Name	`ssf_streams`
Type	Resource
Id	`okta.ssf.ssf_streams`

Fields

The following fields are returned by SELECT queries:

get_ssf_streams

Name	Datatype	Description

Methods

The following methods are available for this resource:

Name	Accessible by	Required Params	Optional Params	Description
`get_ssf_streams`	`select`	`subdomain`	`stream_id`	Retrieves either a list of all known SSF Stream configurations or the individual configuration if specified by ID. As Stream configurations are tied to a Client ID, only the Stream associated with the Client ID of the request OAuth 2.0 access token can be viewed.
`create_ssf_stream`	`insert`	`subdomain`, `data__events_requested`, `data__delivery`		Creates an SSF Stream for an event receiver to start receiving security events in the form of Security Event Tokens (SETs) from Okta. An SSF Stream is associated with the Client ID of the OAuth 2.0 access token used to create the stream. The Client ID is provided by Okta for an OAuth 2.0 app integration. One SSF Stream is allowed for each Client ID, hence, one SSF Stream is allowed for each app integration in Okta. A maximum of 10 SSF Stream configurations can be created for one org.
`update_ssf_stream`	`update`	`subdomain`, `data__events_requested`, `data__delivery`		Updates properties for an existing SSF Stream configuration. If the `stream_id` isn't provided in the request body, the associated stream with the Client ID (through the request OAuth 2.0 access token) is updated.
`replace_ssf_stream`	`replace`	`subdomain`, `data__events_requested`, `data__delivery`		Replaces all properties for an existing SSF Stream configuration. If the `stream_id` isn't provided in the request body, the associated stream with the Client ID (through the request OAuth 2.0 access token) is replaced.
`delete_ssf_stream`	`delete`	`subdomain`	`stream_id`	Deletes the specified SSF Stream. If the `stream_id` is not provided in the query string, the associated stream with the Client ID (through the request OAuth 2.0 access token) is deleted. Otherwise, the SSF Stream with the `stream_id` is deleted, if found.
`verify_ssf_stream`	`exec`	`subdomain`, `stream_id`		Verifies an SSF Stream by publishing a Verification Event requested by a Security Events Provider. > Note: A successful response doesn't indicate that the Verification Event was transmitted successfully, only that Okta has transmitted the event or will at some point in the future. The SSF Receiver is responsible for validating and acknowledging successful transmission of the request by responding with HTTP Response Status Code 202.

Parameters

Parameters can be passed in the WHERE clause of a query. Check the Methods section to see which parameters are required or optional for each operation.

Name	Datatype	Description
`subdomain`	`string`	The domain of your organization. This can be a provided subdomain of an official okta domain (okta.com, oktapreview.com, etc) or one of your configured custom domains. (default: my-org)
`stream_id`	`string`	The ID of the specified SSF Stream configuration (example: esc1k235GIIztAuGK0g5)

`SELECT` examples

get_ssf_streams

Retrieves either a list of all known SSF Stream configurations or the individual configuration if specified by ID.

As Stream configurations are tied to a Client ID, only the Stream associated with the Client ID of the request OAuth 2.0 access token can be viewed.

SELECT
*
FROM okta.ssf.ssf_streams
WHERE subdomain = '{{ subdomain }}' -- required
AND stream_id = '{{ stream_id }}';

`INSERT` examples

create_ssf_stream
Manifest

Creates an SSF Stream for an event receiver to start receiving security events in the form of Security Event Tokens (SETs) from Okta.

An SSF Stream is associated with the Client ID of the OAuth 2.0 access token used to create the stream. The Client ID is provided by Okta for an OAuth 2.0 app integration. One SSF Stream is allowed for each Client ID, hence, one SSF Stream is allowed for each app integration in Okta.

A maximum of 10 SSF Stream configurations can be created for one org.

INSERT INTO okta.ssf.ssf_streams (
data__delivery,
data__events_requested,
data__format,
subdomain
)
SELECT 
'{{ delivery }}' --required,
'{{ events_requested }}' --required,
'{{ format }}',
'{{ subdomain }}'
RETURNING
stream_id,
aud,
delivery,
events_delivered,
events_requested,
events_supported,
format,
iss,
min_verification_interval
;

# Description fields are for documentation purposes
- name: ssf_streams
  props:
    - name: subdomain
      value: string
      description: Required parameter for the ssf_streams resource.
    - name: delivery
      value: object
      description: >
        Contains information about the intended SET delivery method by the receiver
        
    - name: events_requested
      value: array
      description: >
        The events (mapped by the array of event type URIs) that the receiver wants to receive
        
    - name: format
      value: string
      description: >
        The Subject Identifier format expected for any SET transmitted.
        
      valid_values: ['iss_sub']

`UPDATE` examples

update_ssf_stream

Updates properties for an existing SSF Stream configuration.

If the stream_id isn't provided in the request body, the associated stream with the Client ID (through the request OAuth 2.0 access token) is updated.

UPDATE okta.ssf.ssf_streams
SET 
data__aud = '{{ aud }}',
data__delivery = '{{ delivery }}',
data__events_delivered = '{{ events_delivered }}',
data__events_requested = '{{ events_requested }}',
data__events_supported = '{{ events_supported }}',
data__format = '{{ format }}',
data__iss = '{{ iss }}',
data__min_verification_interval = {{ min_verification_interval }},
data__stream_id = '{{ stream_id }}'
WHERE 
subdomain = '{{ subdomain }}' --required
AND data__events_requested = '{{ events_requested }}' --required
AND data__delivery = '{{ delivery }}' --required
RETURNING
stream_id,
aud,
delivery,
events_delivered,
events_requested,
events_supported,
format,
iss,
min_verification_interval;

`REPLACE` examples

replace_ssf_stream

Replaces all properties for an existing SSF Stream configuration.

If the stream_id isn't provided in the request body, the associated stream with the Client ID (through the request OAuth 2.0 access token) is replaced.

REPLACE okta.ssf.ssf_streams
SET 
data__aud = '{{ aud }}',
data__delivery = '{{ delivery }}',
data__events_delivered = '{{ events_delivered }}',
data__events_requested = '{{ events_requested }}',
data__events_supported = '{{ events_supported }}',
data__format = '{{ format }}',
data__iss = '{{ iss }}',
data__min_verification_interval = {{ min_verification_interval }},
data__stream_id = '{{ stream_id }}'
WHERE 
subdomain = '{{ subdomain }}' --required
AND data__events_requested = '{{ events_requested }}' --required
AND data__delivery = '{{ delivery }}' --required
RETURNING
stream_id,
aud,
delivery,
events_delivered,
events_requested,
events_supported,
format,
iss,
min_verification_interval;

`DELETE` examples

delete_ssf_stream

Deletes the specified SSF Stream.

If the stream_id is not provided in the query string, the associated stream with the Client ID (through the request OAuth 2.0 access token) is deleted. Otherwise, the SSF Stream with the stream_id is deleted, if found.

DELETE FROM okta.ssf.ssf_streams
WHERE subdomain = '{{ subdomain }}' --required
AND stream_id = '{{ stream_id }}';

Lifecycle Methods

verify_ssf_stream

Verifies an SSF Stream by publishing a Verification Event requested by a Security Events Provider.

> Note: A successful response doesn't indicate that the Verification Event
was transmitted successfully, only that Okta has transmitted the event or will
at some point in the future. The SSF Receiver is responsible for validating and acknowledging
successful transmission of the request by responding with HTTP Response Status Code 202.

EXEC okta.ssf.ssf_streams.verify_ssf_stream 
@subdomain='{{ subdomain }}' --required 
@@json=
'{
"state": "{{ state }}", 
"stream_id": "{{ stream_id }}"
}';

Overview​

Fields​

Methods​

Parameters​

SELECT examples​

INSERT examples​

UPDATE examples​

REPLACE examples​

DELETE examples​

Lifecycle Methods​